分佈式系統設計權衡之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.htmlBrewer's CAP Theorem   http://www.julianbrowne.com/article/viewer/brewers-cap-theoremFoundationdb 的CAP權衡選擇  https://foundationdb.com/white-papers/the-cap-theorem