在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說碼

淺談分布式CAP定理