網際網路發展到現在，由於資料量大、操作併發高等問題，大部分網站專案都採用分散式的架構。而分散式系統最大的特點資料分散，在不同網路節點在某些時刻（資料未同步完，資料丟失），資料會不一致。

在2000年，Eric Brewer教授在PODC的研討會上提出了一個猜想：一致性、可用性和分割槽容錯性三者無法在分散式系統中被同時滿足，並且最多隻能滿足其中兩個！

在2002年，Lynch證明其猜想，上升為定理。被這就是大家所認知的CAP定理。

CAP是所有分散式資料庫的設計標準。例如Zookeeper、Redis、HBase等的設計都是基於CAP理論的。

CAP定義

所謂的CAP就是分散式系統的三個特性：

• Consistency，一致性。所有分散式節點的資料是否一致。
• Availability，可用性。在部分節點有問題的情況（資料不一致、節點故障）下，是否能繼續響應服務（可用）。
• Partition tolerance，分割槽容錯性。允許在節點（分割槽）資料不一致的情況。

深入理解

有A、B、C三個分散式資料庫。

當A、B、C的資料是完全相同，那麼就符合定理中的Consistency（一致性）。

假如A的資料與B的資料不相同，但是整體的服務（包含A、B、C的整體）沒有宕機，依然可以對外系統服務，那麼就符合定理中的Availability（可用性）。

分散式資料庫是沒有辦法百分百時刻保持各個節點資料一致的。假設一個使用者再A庫上更新了一條記錄，在更新完這一刻，A與B、C庫的資料是不一致的。這種情況在分散式資料庫上是必然存在的。這就是Partition tolerance（分割槽容錯性）

當資料不一致的時候，必定是滿足分割槽容錯性，如果不滿足，那麼這個就不是一個可靠的分散式系統。

然而在資料不一致的情況下，系統要麼選擇優先保持資料一致性，這樣的話。系統首先要做的是資料的同步操作，此時需要暫停系統的響應。這就是滿足CP。

若系統優先選擇可用性，那麼在資料不一致的情況下，會在第一時間放棄一致性，讓整體系統依然能運轉工作。這就是AP。

所以，分散式系統在通常情況下，要不就滿足CP，要不就滿足AP。

那麼有沒有滿足CA的呢？有，當分散式節點為1的時候，不存在P，自然就會滿足CA了。

例子

上面說到，分割槽容錯性是分散式系統中必定要滿足的，需要權衡的是系統的一致性與可用性。那麼常見的分散式系統是基於怎樣的權衡設計的。

• Zookeeper
  保證CP。當主節點故障的時候，Zookeeper會重新選主。此時Zookeeper是不可用的，需要等待選主結束才能重新提供註冊服務。顯然，Zookeeper在節點故障的時候，並沒有滿足可用性的特性。在網路情況複雜的生產環境下，這樣的的情況出現的概率也是有的。一旦出現，如果依賴Zookeeper的部分會卡頓，在大型系統上，很容易引起系統的雪崩。這也是大型專案不選Zookeeper當註冊中心的原因。
• Eureka
  保證AP。在Eureka中，各個節點是平等的，它們相互註冊。掛掉幾個節點依然可以提供註冊服務的（可以配置成掛掉的比例），如果連線的Eureka發現不可用，會自動切換到其他可用的幾點上。另外，當一個服務嘗試連線Eureka發現不可用的時候，切換到另外一個Eureka服務上，有可能由於故障節點未來得及同步最新配置，所以這個服務讀取的資料可能不是最新的。所以當不要求強一致性的情況下，Eureka作為註冊中心更為可靠。
• Git
  其實Git也是也是分散式資料庫。它保證的是CP。很容易猜想到，雲端的Git倉庫於本地倉庫必定是要保證資料的一致性的，如果不一致會先讓資料一致再工作。當你修改完原生代碼，想push程式碼到Git倉庫上時，假如雲端的HEAD與本地的HEAD不一致的時候，會先同步雲端的HEAD到本地HEAD，再把本地的HEAD同步到雲端。最終保證資料的一致性。

更多技術文章、精彩乾貨，請關注
個人部落格：zackku.com
微信公眾號：Zack說碼