分散式系統（distributed system）正變得越來越重要，大型網站幾乎都是分散式的。
分散式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分散式系統的起點。
一、分散式系統的三個指標
1. Consistency（一致性）
在分散式的環境中，一致性是指資料在多個副本之間是否能夠保持一致的特性。 對於任何從客戶端傳送到分散式系統的資料讀取請求，要麼讀到最新的資料，要麼失敗。如果能夠做到針對一個資料項的更新操作執行成功後，所有的使用者都可以讀到其中最新的值，那這樣的系統就被認為具有強一致性(或者嚴格的一致性)。
特點：要麼讀到最新的資料，要麼失敗，其強調的是資料正確。
2. Availability（可用性）
可用性是指系統提供的服務必須一直處於可用的狀態，而且對於使用者的每一個操作請求，總是能夠在有限的時間內獲取到非錯的響應——但是不保證獲取的資料為最新資料。
比如系統穩定性已經做到3個9、4個9，即99.9%、99.99%，這裡的N個9就是對可用性的一個描述，叫做SLA，即服務水平協議。比如我們說月度99.95%的SLA，則意味每個月服務出現故障的時間只能佔總時間的 0.05%，如果這個月是 30 天，那麼就是 21.6 分鐘
特點：一定會返回資料，不會返回錯誤，但不保證資料最新，強調的是不出錯，任何時候讀寫都是成功的。
3. Partition tolerance（分割槽容忍性）
大多數分散式系統都分佈在多個子網路。每個子網路就叫做一個區（partition）。分割槽容忍性是指“當部分節點出現訊息丟失或者分割槽故障的時候，分散式系統仍然能夠繼續執行”，即系統容忍網路出現分割槽，並且在遇到某節點或網路分割槽之間網路不可達的情況下，仍然能夠對外提供滿足一致性和可用性的服務。
特點：我會一直執行，不管我的內部出現何種資料同步問題，強調的是不掛掉。
在分散式系統中，由於系統的各層拆分，P是確定的，CAP的應用模型就是CP架構和AP架構。分散式系統所關注的，就是在PartitionTolerance的前提下，如何實現更好的A，和...
二、CAP 理論的證明
CAP理論的證明有多種方式，通過反證的方式是最直觀的。反證法來證明CAP定理，最早是由Lynch提出的，通過一個實際場景，如果CAP三者可同時滿足，由於允許P的存在，則一定存在Server 之間的丟包，如此則不能保證C。
單機系統
分散式系統
可以看到，在分散式系統中，無法同時滿足 CAP 定律中的“一致性”、“可用性”和“分割槽容錯性”三者。
三、 CAP 理論的應用
CAP 理論提醒我們，在架構設計中，不要把精力浪費在如何設計能滿足三者的完美分散式系統上，而要合理進行取捨，CAP 理論類似數學上的不可能三角，只能三者選其二，不能全部獲得。
不同業務對於一致性的要求是不同的。舉個例來講，在微博上發表評論和點贊，使用者對不一致是不敏感的，可以容忍相對較長時間的不一致，只要做好本地的互動，並不會影響使用者體驗；而我們在電商購物時，產品價格資料則是要求強一致性的，如果商家更改價格不能實時生效，則會對交易成功率有非常大的影響。
需要注意的是，CAP理論中是忽略網路延遲的，也就是當事務提交時，節點間的資料複製一定是需要花費時間的。即使是同一個機房，從節點A複製到節點B，由於現實中網路不是實時的，所以總會有一定的時間不一致。
四、BASE理論
BASE理論的意義在於，我們不必在A或C中做出選擇，可以實現部分的A和C。
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫，是對 CAP 中 AP 的一個擴充套件。
1. 基本可用
基本可用是不追求 CAP 中的「任何時候，讀寫都是成功的」。基本可用強調了分散式系統在出現不可預知故障的時候，允許損失部分可用性，相比正常的系統，可能是響應時間延長，保證核心功能可用，或者是服務被降級。
舉個例子，在雙十一秒殺活動中，如果搶購人數太多超過了系統的 QPS 峰值，可能會排隊或者提示限流，這就是通過合理的手段保護系統的穩定性，保證主要的服務正常，保證基本可用。
2. 軟狀態
軟狀態可以對應ACID事務中的原子性，在ACID的事務中，實現的是強一致性，要麼全做要麼不做，所有使用者看到的資料一致。其中的原子性（Atomicity）要求多個節點的資料副本都是一致的，強調資料的一致性。
ACID 是一種強一致性模型，強調原子性、一致性、隔離性和永續性，主要用於在資料庫實現中。
原子性可以理解為一種“硬狀態”，軟狀態則是允許系統中的資料存在中間狀態，並認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的資料副本存在資料延時。
Base 理論面向的是高可用、可擴充套件的分散式系統，ACID 適合傳統金融等業務，在實際場景中，不同業務對資料的一致性要求不一樣。
3. 最終一致
資料不可能一直是軟狀態，必須在一個時間期限（這段時間為“不一致性視窗”）之後達到各個節點的一致性，在期限過後，應當保證所有副本保持資料一致性，也就是達到資料的最終一致性。
在系統設計中，最終一致性實現的時間取決於網路延時、系統負載、不同的儲存選型、不同資料複製方案設計等因素。
BASE 解決了 CAP 中理論沒有網路延遲，在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。 BASE 和 ACID 是相反的，它完全不同於 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許資料在一段時間內是不一致的，但最終達到一致狀態。
一致性模型
最終一致性模型根據其提供的不同保證可以劃分為更多的模型，包括因果一致性和會話一致性等。
因果一致性
因果一致性要求有因果關係的操作順序得到保證，非因果關係的操作順序則無所謂。
程式 A 在更新完某個資料項後通知了程式 B，那麼程式 B 之後對該資料項的訪問都應該能夠獲取到程式 A 更新後的最新值，並且如果程式 B 要對該資料項進行更新操作的話，務必基於程式 A 更新後的最新值。
因果一致性的應用場景可以舉個例子，在微博或者微信進行評論的時候，比如你在朋友圈發了一張照片，朋友給你評論了，而你對朋友的評論進行了回覆，這條朋友圈的顯示中，你的回覆必須在朋友之後，這是一個因果關係，而其他沒有因果關係的資料，可以允許不一致。
會話一致性
會話一致性將對系統資料的訪問過程框定在了一個會話當中，約定了系統能保證在同一個有效的會話中實現“讀己之所寫”的一致性，就是在你的一次訪問中，執行更新操作之後，客戶端能夠在同一個會話中始終讀取到該資料項的最新值。
實際開發中有分散式的 Session 一致性問題，可以認為是會話一致性的一個應用。
五、CP 和 AP 架構的取捨
業務上對一致性的要求會直接反映在系統設計中，典型的就是 CP 和 AP 結構。
CP 架構
CP 架構：對於 CP 來說，放棄可用性，追求一致性和分割槽容錯性。
ZooKeeper 就是採用了CP一致性，ZooKeeper是一個分散式的服務框架，主要用來解決分散式叢集中應用系統的協調和一致性問題。其核心演算法是Zab，所有設計都是為了一致性。在 CAP 模型中，ZooKeeper 是 CP，這意味著面對網路分割槽時，為了保持一致性，它是不可用的。在分割槽後，對於A，只有分割槽內節點大於quorum才對外服務
AP 架構
AP 架構：對於 AP 來說，放棄強一致性（這裡說的一致性是強一致性），追求分割槽容錯性和可用性，這是很多分散式系統設計時的選擇，Base 也是根據 AP 來擴充套件的。
和ZooKeeper相對的是Eureka，Eureka是SpringCloud微服務技術棧中的服務發現元件，Eureka的各個節點都是平等的，幾個節點掛掉不影響正常節點的工作，剩餘的節依然可以提供註冊和查詢服務，只要有一臺 Eureka 還在，就能保證註冊服務可用，只不過查到的資訊可能不是最新的版本，不保證一致性，實現了最終一致性。
參考來源
分散式CAP定理，為什麼不能同時滿足三個特性？
拉勾專欄： 分散式技術原理與實戰45講
分散式理論(一) —— CAP 定理
CAP定理以及證明
CAP 定理的含義
CAP定理