21天學會C語言？3天學會彈鋼琴？

放棄一切錯誤方法，從今天開始“刻意練習”，

因為這才是最強大的，也是唯一正確的學習方法。

--《刻意練習》Anders Ericsson

引言

CAP問題已經成了計算機科學中一個研究領域，之前說到分布式系統有哪些優勢時講到三個提升：

1.系統可用性提升。

2.系統并發能力提升

3.系統容錯能力提升。

那么這三方面在實施起來可以同時滿足嗎？答案是不能，設計分布式系統的時候，設計者需要理解一個重要的理論概念，CAP定理。

BASE: Basically Available（基本可用）, Soft state（軟狀態）和 Eventually consistent（最終一致性）

2012年Brewer發表了一篇文章，重新解釋了他對CAP定理的理解：

首先，網絡分區的發生是小概率事件，當網絡沒有發生分區的時候沒有任何理由放棄C或者A

其次，在同一個系統中C和A的選擇可能發生多次，不同的子系統可以做不一樣的選擇，當條件不同時做出的選擇可以不一樣，例如：不同的操作、數據、用戶可能會導致不同的選擇

最后，這三個屬性不是0和1的選擇，而是線性的。可用性很明顯可以從0%到100%，其實一致性甚至分區容忍性也是有差別的

CAP分別代表什么嗎？

關于CAP，它是2000 年 7 月，加州大學伯克利分校的 Eric Brewer 教授在 ACM PODC 會議上提出 CAP 猜想。2 年后，麻省理工學院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP。之后，CAP 理論正式成為分布式計算領域的公認定理。

C的全拼是 Consistency，代表一致性的意思。

A的全拼是Availability，代表可用性的意思。

P的全拼是Partition tolerance，代表分區容錯性的意思。

三選二：CP、AP、CA

一個分布式系統最多同時滿足一致性 (Consistency)，可用性 (Availability) 和分區容忍性 (Partition Tolerance) 這三項中的兩項。

• 同時滿足一致性（C）和可用性（A）就要犧牲掉容錯性（P）

• 同時滿足可用性（A）和分區容錯性（P）就要犧牲掉一致性（C）

• 同時滿足一致性（C）和分區容錯性（P）就要犧牲掉可用性（A）

這三個象限，只能同時滿足其中兩個圓圈的交集。

舉個例子

用 Redis Cluster高可用架構舉例：redis就能會將數據分片到多個實例(按照slot存儲)中，即一個機房分擔一部分數據。Master 負責寫，Master會自動同步到 Slava。

Reids去中心集群架構優點：

無中心架構：三機房部署，其中一主一從構成一個分片，之間通過異步復制同步數據，異步復制存在數據不一致的時間窗口，保證高性能的同時犧牲了部分一致性一旦某個機房掉線，則分片上位于另一個機房的 slave 會被提升為 master 從而可以繼續提供服務，

可擴展性：可線性擴展到1000多個節點，節點可動態添加或刪除。

降低運維成本，提高系統的擴展性和可用性。

分析，這個分布式架構中滿足了CAP中哪個兩個定理？

優點1中講到，三機房部署，每個機房有一主一從，即一個 Master 對應一個 Slave ，但是你會發現，機房1中的 Master 1 ?連接的 Slave 在機房2，機房2中的 Master 2 ?連接的 Slave 在機房3，機房3中的 Master 3 ?連接的 Slave 在機房1，這樣構成一個環，為什么要這樣設計？

假設：機房斷電or火災or其他各種原因，反正就是機房1所有機器都不能用了。

這個時候那機房1的全部數據都不能訪問了嗎？這顯然是我們不希望的。前面已經說了Master 負責寫，Master會自動同步到 Slava，如果 Master寫服務宕機，Slave 讀服務會被提升為 master ，也就是說機房1的數據在機房2的Slava2上還有備份，數據還在，在宕機的master沒有恢復前 Slave 要同時承擔讀寫服務，雖然累一點，但是還能用，這樣設計是為了提高可用性（A），和容錯性（P）。系統準許你一臺機器或者整個機房都宕機。系統仍然能。

公眾號【轉行程序員】回復”加群“，我會拉你進技術群。

但是你會發現，單個機房如果距離很遠， Master 1 ?的數據同步到 Slave2 上是跨機房，跨機房同步肯定不如同機房塊，這樣一來 Slave2 負責的讀就會有延遲，Master1 要更新的數據還沒有同步到他在另一個機房的備份前，讀操作就是不一致的，這樣設計顯然是犧牲掉一致性（C）。相信這樣分析應該能理解CAP定理了。

進一步分析：

讓同一組 Master - Slave 放在一個機房，同機房復制數據不是更快？這樣能不能解決數據一致（C）問題，答案是能，還有更好的解決一致性的辦法就是不要Master - Slave 組合，就一臺機器，一臺機器同時擔任讀寫請求，沒有延遲不存在數據一致性問題。這是時候如果宕機了怎么辦？這樣的架構下，那就真的是不可用了，解決了一致性（C）卻犧牲了可用性（A）和容錯性（P），太不劃算了。

總之，分布式系統下，CAP確實無法同時滿足，在Reids去中心集群架構中，最優的解決方案還是滿足可用性（A）和分區容錯性（P）就要犧牲掉一致性（C），即使跨機房同步數據，延遲也不過1s，數據不一致的問題只出現在1s內，日常開發中，很少遇到要求強一致性的場景。例如訂單系統，用戶更新了訂單支付狀態，讀訂單狀態是在從庫，有什么讀場景等不來這一秒？

如果真的必須要求強一致性，那可能就必須調整分布式架構方案來。

總結

本文主要講解了CAP定理的概念，為什么要學習這個概念，設計高可用分布式系統時，你必須知道系統的短處，懂得CAP能讓你根據實際情況有舍有得。面試會被經常問到，比如，你說你使用了消息隊列，解決了系統耦合問題，提高了響應速度，那面試官問題：使用消息隊列有啥缺點？如果你知道CAP定理這個問題還難嗎？

顯然消息的延遲會帶來數據不一致問題。理想情況下消息不丟失那數據會最終一致，你能保證消息不丟失嗎？如何解決機問題，如果是我，我會選擇“最終一致性”，就是說不管消息延遲多久甚至丟失，設計一個離線定時任務，定期去掃描兩個系統的數據，有不一致的情況就主動刷新同步，這樣保證最終一致。

參考資料

• CAP theorem – Wikipedia

• CAP Twelve Years Later: How the “Rules” Have Changed

聯系我

VX搜索【轉行程序員】回復”加群“，我會拉你進技術群。講真的，在這個群，哪怕您不說話，光看聊天記錄也是一種成長。阿里/騰訊/百度資深工程師、Google技術大神、IBM工程師、還有我王炸、敖丙、各路大牛都在，有任何不明白的都進群提問。

最后，覺得王炸的文章不錯就來個三連吧：關注 轉發 點贊

總結

以上是生活随笔為你收集整理的分布式系统不得不说的CAP定理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。