要討論分散式，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的問題。

        以上均是個人理解，不