分散式系統設計權衡之CAP(一致性,可用性,分割槽容錯性)
寫在最前：
1.為什麼學習並記錄分散式設計理念一系列相關的東西
在日常工作中系統設計評審的時候，經常會有一些同事丟擲一些概念,高可用性，一致性等等字眼，他們用這些最基本的概念去反駁系統最初的設計，但是很多人理解的可用性,一致性等等問題，都是自己拍腦袋想的，或者根本和最原始表達的意思就不是一個東西，在這種情況下PK，就像不再一個頻段的人在交流，除了爭論，沒有任何實質性的進展，所以有必要熟悉其理論基礎，以免貽笑大方。（其實類似的例子還有很多，國內的技術人員都喜歡把一些此詞模糊化，混淆而談。例如XX雲，實際賣的就是vps 和一小部分saas,這就叫cloud computing?）
2.準備說哪些東西
分散式系統設計在評審時，爭論得最多的地方，其實也就是著名的cap理論，本文也主要對CAP理論加以自己的理解和應用
CAP理論
什麼是分散式系統
部分在不同的節點上，通過網路協同工作的系統叫做分散式系統
CAP分別代表什麼
• Consistency
• (all nodes see the same data at the same time)
• Availability
• Reads and writes always succeed.
• Partition tolerance
• (the system continues to operate despite arbitrary message loss or failure of part of the system)
一致性： 更新操作成功並返回客戶端完成後,分散式的所有節點在同一時間的資料完全一致
可用性: 讀和寫操作都能成功
分割槽容錯性：再出現網路故障導致分散式節點間不能通訊時，系統能否繼續服務
CAP的是什麼關係
It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.
在分散式系統的設計中，沒有一種設計可以同時滿足一致性，可用性，分割槽容錯性 3個特性
注意：不要將弱一致性，最終一致性放到CAP理論裡混為一談（混淆概念的坑真多）
弱一致性，最終一致性 你可以認為和CAP的C一點關係也沒有，因為CAP的C是更新操作完成後，任何節點看到的資料完全一致, 弱一致性。最終一致性本身和CAP的C一致性是違背的，所以你可以看到那些謊稱自己系統同時具備CAP 3個特性是多麼的可笑，可能國內更多的場景是：一個開放人員一旦走上講臺演講，就立馬轉變為了營銷人員，連最基本的理念也不要了。
這裡有一篇標題很大的文章 cap-twelve-years-later-how-the-rules-have-changed ，實際上本文的changed更多的是在思考方式上，而本身CAP理論是沒有changed的
為什麼會是這樣
我們來看一個簡單的問題, 一個DB服務 搭建在兩個機房（北京,廣州)，兩個DB例項同時提供寫入和讀取
1. 假設DB的更新操作是同時寫北京和廣州的DB都成功才返回成功
在沒有出現網路故障的時候，滿足CA原則，C 即我的任何一個寫入，更新操作成功並返回客戶端完成後,分散式的所有節點在同一時間的資料完全一致， A 即我的讀寫操作都能夠成功，但是當出現網路故障時，我不能同時保證CA，即P條件無法滿足
2. 假設DB的更新操作是隻寫本地機房成功就返回，通過binlog/oplog回放方式同步至側邊機房
這種操作保證了在出現網路故障時,雙邊機房都是可以提供服務的，且讀寫操作都能成功，意味著他滿足了AP ，但是它不滿足C，因為更新操作返回成功後，雙邊機房的DB看到的資料會存在短暫不一致，且在網路故障時，不一致的時間差會很大（僅能保證最終一致性）
3. 假設DB的更新操作是同時寫北京和廣州的DB都成功才返回成功且網路故障時提供降級服務
降級服務，如停止寫入，只提供讀取功能，這樣能保證資料是一致的，且網路故障時能提供服務，滿足CP原則，但是他無法滿足可用性原則
選擇權衡
通過上面的例子，我們得知，我們永遠無法同時得到CAP這3個特性，那麼我們怎麼來權衡選擇呢？
選擇的關鍵點取決於業務場景
對於大多數網際網路應用來說（如網易門戶），因為機器數量龐大，部署節點分散，網路故障是常態，可用性是必須需要保證的，所以只有設定一致性來保證服務的AP，通常常見的高可用服務吹噓5個9 6個9服務SLA穩定性就本都是放棄C選擇AP
對於需要確保強一致性的場景，如銀行，通常會權衡CA和CP模型，CA模型網路故障時完全不可用，CP模型具備部分可用性，實際的選擇需要通過業務場景來權衡（並不是所有情況CP都好於CA，只能檢視資訊不能更新資訊有時候從產品層面還不如直接拒絕服務）
延伸
BASE(Basically Available, Soft State, Eventual Consistency 基本可用、軟狀態、最終一致性) 對CAP AP理論的延伸, Redis等眾多系統構建與這個理論之上
ACID 傳統資料庫常用的設計理念, ACID和BASE代表了兩種截然相反的設計哲學，分處一致性-可用性分佈圖譜的兩極。
擴充套件閱讀
Daniel Abadi認為 CAP 應該叫 PACELC http://dbmsmusings.blogspot.jp/2010/04/problems-with-cap-and-yahoos-little.html
Brewer's CAP Theorem http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
Foundationdb 的CAP權衡選擇 https://foundationdb.com/white-papers/the-cap-theorem