上篇我們說了什麼是註冊中心和常見的註冊中心，本文將講述CAP 原則與 BASE 理論。作者是公衆號：哈嘍沃德先生，請多關注。

一、CAP 原則

CAP 原則又稱 CAP 定理，指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割區容錯性），三者不可得兼。

CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出。該猜想在提出兩年後被證明成立，成爲我們熟知的 CAP 定理。CAP 三者不可兼得。

1、取捨策略

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

• 「CA without P」：如果不要求P（不允許分割區），則C（強一致性）和A（可用性）是可以保證的。但放棄 P 的同時也就意味着放棄了系統的擴充套件性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。
• 「CP without A」：如果不要求A（可用），相當於每個請求都需要在伺服器之間保持強一致，而P（分割區）會導致同步時間無限延長（也就是等待數據同步完才能 纔能正常存取服務），一旦發生網路故障或者訊息丟失等情況，就要犧牲使用者的體驗，等待所有數據全部一致了之後再讓使用者存取系統。設計成 CP 的系統其實不少，最典型的就是分佈式數據庫，如 Redis、HBase等。對於這些分佈式數據庫來說，數據的一致性是最基本的要求，因爲如果連這個標準都達不到，那麼直接採用關係型數據庫就好，沒必要再浪費資源來部署分佈式數據庫。
• 「AP without C」：要高可用並允許分割區，則需放棄一致性。一旦分割區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全域性數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做了些犧牲，雖然多少會影響一些使用者體驗，但也不至於造成使用者購物流程的嚴重阻塞。

2、總結

現如今，對於多數大型網際網路應用的場景，主機衆多、部署分散，而且現在的叢集規模越來越大，節點只會越來越多，所以節點故障、網路故障是常態，因此分割區容錯性也就成爲了一個分佈式系統必然要面對的問題。那麼就只能在 C 和 A 之間進行取捨。但對於傳統的專案就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對於數據一致性不能做出一絲的讓步，C 必須保證，出現網路故障的話，寧可停止服務，可以在 A 和 P 之間做取捨。

總而言之，沒有最好的策略，好的系統應該是根據業務場景來進行架構設計的，只有適合的纔是最好的。

二、BASE 理論

CAP 理論已經提出好多年了，難道真的沒有辦法解決這個問題嗎？也許可以做些改變。比如 C 不必使用那麼強的一致性，可以先將數據存起來，稍後再更新，實現所謂的 「最終一致性」。

這個思路又是一個龐大的問題，同時也引出了第二個理論 BASE 理論。

BASE：全稱 Basically Available（基本可用），Soft state（軟狀態），和 Eventually
consistent（最終一致性）三個短語的縮寫，來自 ebay 的架構師提出。

BASE 理論是對 CAP 中一致性和可用性權衡的結果，其來源於對大型網際網路分佈式實踐的總結，是基於 CAP 定理逐步演化而來的。其核心思想是：

既然無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

1、Basically Available（基本可用）

基本可用是指分佈式系統在出現故障的時候，允許損失部分可用性（例如響應時間、功能上的可用性）。需要注意的是，基本可用絕不等價於系統不可用。

響應時間上的損失：正常情況下搜尋引擎需要在 0.5 秒之內返回給使用者相應的查詢結果，但由於出現故障（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了 1~2 秒。
功能上的損失：購物網站在購物高峯（如雙十一）時，爲了保護系統的穩定性，部分消費者可能會被引導到一個降級頁面。

2、Soft state（軟狀態）

什麼是軟狀態呢？相對於原子性而言，要求多個節點的數據副本都是一致的，這是一種 「硬狀態」。

軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分佈式儲存中一般一份數據會有多個副本，允許不同副本數據同步的延時就是軟狀態的體現。

3、Eventually consistent（最終一致性）

系統不可能一直是軟狀態，必須有個時間期限。在期限過後，應當保證所有副本保持數據一致性。從而達到數據的最終一致性。這個時間期限取決於網路延時，系統負載，數據複製方案設計等等因素。

實際上，不只是分佈式系統使用最終一致性，關係型數據庫在某個功能上，也是使用最終一致性的，比如備份，數據庫的複製都是需要時間的，這個複製過程中，業務讀取到的值就是舊值。當然，最終還是達成了數據一致性。這也算是一個最終一致性的經典案例。

4、總結

總的來說，BASE 理論面向的是大型高可用可延伸的分佈式系統，和傳統事務的 ACID 是相反的，它完全不同於 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許數據在一段時間是不一致的。更多Java微服務架構，spring全家桶教學 歡迎點選獲取。