【0】CAP定理

        要討論分佈式，CAP就是一個沒法避免的話題。瞭解些分佈式知識的都能輕鬆說出CAP定理的內容：一致性、可用性和分區容錯性只能三取其二，而不能同時知足三者，彷佛這一句話就把這個定理描述完了。這是我以前一個粗鄙的理解，隨着學習得不斷深刻發現這樣去解釋CAP定理是不正確的，那麼到底該怎麼理解呢？咱們再來看看CAP每一個字母的含義：

• Consistency（一致性）：在分佈式系統中，全部的數據備份，在同一時刻是否一樣的值，若是是，則咱們認爲知足了一致性。這裏的一致性是指的是強一致性。
• Availability（可用性）：在集羣的部分節點故障後，集羣總體是否能夠正常響應請求。
• Partition tolerance （分區容錯性）：這裏的分區是指網絡分區，網絡分區能夠這樣理解，一個服務集羣有A、B兩個節點，原本A、B之間是能夠網絡通訊的（來保證數據一致性），但是忽然發生了網絡故障，A、B不能再相互訪問，這時候咱們認爲集羣發生了網絡分區。

        其實CAP定理本意是想表達當發生網絡分區狀況時，一致性和可用性只能二選其一。咱們舉例說明，一個服務集羣由A、B兩個節點，A和B分別維護本身的數據副本，而後經過網絡達到數據的一致性。當發生網絡分區時，A、B之間不能互相訪問了，此時，數據的一致性和服務的可用性必須作出二選一的抉擇，也就是說當請求發送到A節點時，若是保證服務可用性，則A接收請求而後返回處理結果，此刻A和B的數據副本出現了不一致的狀況（B此刻也能夠獨立處理請求）；若是保證數據的一致性，則A接收到請求後，就要等A、B數據同步後在返回處理結果，這樣就沒法保證請求在特定時間內返回結果了，就喪失了服務的可用性了。

        CAP定理在分佈式數據庫中討論的比較多，如今流行的Nosql數據庫中常常被討論。分佈式服務中是否適用CAP定理，我以爲仍是要看具體的設計，若是服務維護多個數據副本（多個數據庫），則就會涉及CAP討論的內容，若是你的數據副本就一份，那就沒有討論CAP的必要了。因此具體要看本身系統的設計，不是說咱們用了spring cloud這種分佈式服務架構，就必定會有CAP的問題。

        以上均是我的理解，不妥之處往指正。