寫在最前：

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