分佈式基礎，通俗易懂CAP？

分佈式系統很是關注三個指標：

• 數據一致性
• 系統可用性
• 節點連通性與擴展性

關於一致性

數據「強一致性」，是但願系統只讀到最新寫入的數據，例如：經過單點串行化的方式，就可以達到這個效果。

關於session一致性，DB主從一致性，DB雙主一致性，DB與Cache一致性，數據冗餘一致性，消息時序一致性，分佈式事務一致性，庫存扣減一致性，詳見文章《究竟啥纔是互聯網架構「一致性」》。

關於可用性

若是系統每運行100個時間單位，會有1個時間單位沒法提供服務，則說系統的可用性是99%。

可用性和可靠性是比較容易搞混的兩個指標，以一臺取款機爲例：

• 正確的輸入，可以取到正確的錢，表示系統可靠
• 取款機7*24小時提供服務，表示系統可用

保證系統高可用的方法是：

• 冗餘
• 故障自動轉移

反向代理層，站點層，服務層，緩存層，數據庫層各層保證系統高可用的方法，詳見文章《究竟啥纔是互聯網架構「高可用」》。

關於連通性與擴展性

分佈式系統，每每有多個節點，每一個節點之間，都不是徹底獨立的，須要相互通訊，當發生節點沒法聯通時，數據是否還能保持一致，系統要如何進行容錯處理，是須要考慮的。

同時，連通性和擴展性緊密相關，想要加機器擴展性能，必須有良好的連通性。當一個節點脫離系統，系統就出現問題，每每意味着系統是沒法擴展的。

反向代理層，站點層，服務層，緩存層，數據庫層各層保證系統擴展性的方法，詳見文章《究竟啥纔是互聯網架構「可擴展」》。

什麼是CAP定理？

CAP定理，是對上述分佈式系統的三個特性，進行了概括：

• 一致性(Consistency)
• 可用性(Availability)
• 分區容忍性(Partition Tolerance)
  而且，定理指出，在系統實現時，這三者最多兼顧兩點。

一致性，可用性，多節點擴展性三者只能取其二，既然加鎖已經加上，常見的最佳工程架構實踐是什麼呢？
互聯網，最多見的實踐是這樣的：

• 節點連通性，多節點擴展性，連通性異常的處理必須保證，知足P
• 一致性C與可用性A通常二選一
• 選擇一致性C，舉例：傳統單庫水平切分，就是這類選型的典型
• 選擇可用性A，舉例：雙主庫同步高可用，就是這類選型的典型

強一致很難怎麼辦？

單點串行化，雖然能保證「強一致」，但對系統的併發性能，以及高可用有較大影響，互聯網的玩法，更多的是「最終一致性」，短時間內未必讀到最新的數據，但在一個可接受的時間窗口以後，可以讀到最新的數據。

例如：數據庫主從同步，從庫上的數據，就是一個最終的一致。

總結

• CAP能夠理解爲一致性，可用性，聯通與擴展性
• CAP三者只能取其二
• 最多見的實踐是AP+最終一致性

思路比結論重要。

架構師之路-分享可落地的技術文章

推薦閱讀：《究竟啥纔是互聯網架構「一致性」》《究竟啥纔是互聯網架構「高可用」》《究竟啥纔是互聯網架構「可擴展」》《分佈式基礎，啥是兩階段提交？》《分佈式事務，原來能夠這麼玩？》