淺談分佈式CAP定理

互聯網發展到如今，因爲數據量大、操做併發高等問題，大部分網站項目都採用分佈式的架構。

而分佈式系統最大的特色數據分散，在不一樣網絡節點在某些時刻（數據未同步完，數據丟失），數據會不一致。

在2000年，Eric Brewer教授在PODC的研討會上提出了一個猜測：一致性、可用性和分區容錯性三者沒法在分佈式系統中被同時知足，而且最多隻能知足其中兩個！

在2002年，Lynch證實其猜測，上升爲定理。被這就是你們所認知的CAP定理。

CAP是全部分佈式數據庫的設計標準。例如Zookeeper、Redis、HBase等的設計都是基於CAP理論的。

CAP定義

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

<!-- more -->

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