cap定理是分布式領域當中非常著名的定理，也是大家津津樂道的乙個分布式定理。有些人這麼理解cap定理：
在分布式系統中，
- c代表一致性
- a代表可用性，
- p代表網路分割槽。
因為，分布式環境中，p不不可避免的，分布式系統要麼選擇一致性放棄可用性，要麼選擇可用性放棄一致性。
另外，很多人也這樣乙個認識：
paxos協議（包括與之類似的zab協議-zookeeper，raft協議-etcd）是強一致性的，並且能夠容忍小於少數節點的宕機（也就是少數節點的出現網路分割槽）獲得高可用。
那麼按照以上2種說法，是不是我們可以得出乙個結論：paxos、zookeeper、etcd違反了cap定理？
答案是否定的。要說明這個問題，我們就要仔細的說說什麼是cap定理。cap定理的描述如下：
在乙個shared-data的系統中，我們不可能同時獲得以下3個特性：
- c：一致性，其實這裡的一致性，是指線性一致性。
- a：可用性，是指系統中每乙個non-failing的節點都可以在乙個合理的時間裡成功的完成讀寫操作。
- p:容忍網路分割槽。
下面對cap定理做幾點說明。
- 1.因為cap定理在描述的是乙個shared-data的系統，網路分割槽是必然存在的，系統必須處理網路分割槽的情況。
- 2.定理中的一致性和可用性都是非常苛刻的條件。線性一致性是非常強的一致性模型，除了線性一致性模型，還有很多比線性一致性弱很多的一致性模型，如果你的系統採用了這樣的相對較弱一致性模型，其實已經不是cap定理的範疇了。你是可以實現出乙個具有更弱的一致性模型並且同時滿足a和p的系統出來。
（關於什麼是線性一致性及其作用可以參考《線性一致性(linearizability)是併發控制的基礎》）
- 3.同理，a也是非常苛刻的，他強調了每乙個節點都可以完成讀寫操作。所以paxos雖然是線性一致性的，但是沒滿足這麼苛刻的a的條件。所以也不適用cap定理。
其實，cap只是描述了你不可能實現出一種同時具有完美一致性和完美可用性的shared-data系統出來。這個定理基本上沒有太多實用性的。目前已經有很多系統，實現了很好的一致性並且具有很好可用性。我們不能說這些現實的系統違反了cap定理，而是cap定理不適用於這些現實的系統。paxos、zookeeper、etcd就是這樣的乙個例子。另外，作為對立面的乙個例子，cassandra具有很好的可用性，並且也具有比線性一致性弱一些的一致性。
（關於cassandra的一致性可參看< tunable consistency不能讓cassandra成為cp系統》，此外《雖然cassandra不是cp但cassandra是安全的》這篇文章會告述你雖然cassandra沒有線性一致性，卻擁有非常好用的系統）
從CAP到zookeeper和eureka對比
今天看了一篇eureka對比zookeeper的文章，對zookeeper滿足cap中的cp，eureka滿足ap產生了一點疑問，故寫此篇文章進行一些 首先我們來看看cap的定義 中文叫做 一致性 意思是，寫操作之後的讀操作，必須返回該值。舉例來說，某條記錄是 v0，使用者向 g1 發起乙個寫操作，...
從paxos到zookeeper讀書筆記（第四章）
netty集群簡單的集群方案 zk用來實現服務發現的功能，通過高效能的netty網路框架作為伺服器，註冊到zk中，client請求到zk中選取可用的netty伺服器，選取策略有 輪詢 雜湊 ip分組 加權分組 均衡負載和服務發現的功能 netty伺服器關閉時主動到zk登出。zab演算法 zookee...
從paxos到zookeeper讀書筆記（第六章）
zookeeper的典型應用場景 zookeeper應用場景主要包括 發布 訂閱 負載均衡 命名服務 分布式協調 通知 註冊功能 集群管理 master選舉 分布式鎖 分布式訊息佇列。zk實現資料發布 訂閱服務 發布 訂閱通常有兩種模式 push poll的方式為客戶端提供服務。主要應用於分布式中，...