目錄

一、什么是CAP？

Consistency (一致性)：?

Availability (可用性):

Partition Tolerance (分區容錯性):

二、取舍策略

三、Base理論

1、基本可用

2、軟狀態

3、最終一致性

四、常見產品

Ereka

Zookeeper

五、總結

---

一、什么是CAP？

Consistency (一致性)：?

“All nodes see the same data at the same time”，即更新操作成功并返回客戶端后，所有節點在同一時間的數據完全一致，這就是分布式的一致性。一致性的問題在并發系統中不可避免，對于客戶端來說，一致性指的是并發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何復制分布到整個系統，以保證數據最終一致。

Availability (可用性):

可用性指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。

Partition Tolerance (分區容錯性):

即分布式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。分區容錯性要求能夠使應用雖然是一個分布式系統，而看上去卻好像是在一個可以運轉正常的整體。比如現在的分布式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求，對于用戶而言并沒有什么體驗上的影響。

二、取舍策略

CAP三個特性只能滿足其中兩個，那么取舍的策略就共有三種：

?
CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味著放棄了系統的擴展性，也就是分布式節點受限，沒辦法部署子節點，這是違背分布式系統設計的初衷的。

CP without A：如果不要求A（可用），相當于每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之后再讓用戶訪問系統。設計成CP的系統其實不少，最典型的就是分布式數據庫，如Redis、HBase等。對于這些分布式數據庫來說，數據的一致性是最基本的要求，因為如果連這個標準都達不到，那么直接采用關系型數據庫就好，沒必要再浪費資源來部署分布式數據庫。

AP wihtout C：要高可用并允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然后在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至于造成用戶購物流程的嚴重阻塞。

三、Base理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源于對大規模互聯網系統分布式實踐的總結， 是基于CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。接下來看一下BASE中的三要素：

1、基本可用

基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性—-注意，這絕不等價于系統不可用。比如：

（1）響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由于出現故障，查詢結果的響應時間增加了1~2秒

（2）系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峰的時候，由于消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面

2、軟狀態

軟狀態指允許系統中的數據存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時

3、最終一致性

最終一致性強調的是所有的數據副本，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。總的來說，BASE理論面向的是大型高可用可擴展的分布式系統，和傳統的事物ACID特性是相反的，它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分布式場景中，不同業務單元和組件對數據一致性的要求是不同的，因此在具體的分布式系統架構設計過程中，ACID特性和BASE理論往往又會結合在一起。

四、常見產品

Ereka

Ereka是SpringCloud系列用來做服務注冊和發現的組件，作為服務發現的一個實現，在設計的時候就更考慮了可用性，保證了AP。

Zookeeper

Zookeeper在實現上犧牲了可用性，保證了一致性（單調一致性）和分區容錯性，也即：CP。

所以這也是SpringCloud拋棄了zookeeper而選擇Ereka的原因。

五、總結

對于分布式系統的項目，使用中沒有強制要求一定是CAP中要達到某幾種，具體根據各自業務場景所需來制定相應的策略而選擇適合的產品服務等。例如：支付訂單場景中，由于分布式本身就在數據一致性上面很難保證，從A服務到B服務的訂單數據有可能由于服務宕機或其他原因而造成數據不一致性。因此此類場景會酌情考慮：AP，不強制保證數據一致性，但保證數據最終一致性。