鏈接：https://juejin.im/post/5e89e3bb518825736512cd39
分佈式系統（distributed system）正變得越來越重要，大型網站幾乎都是分佈式的。
分佈式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分佈式系統的起點。
一、分佈式系統的三個指標
1998年，加州大學的計算機科學家 Eric Brewer 提出，分佈式系統有三個指標。Eric Brewer 說，這三個指標不可能同時做到。這個結論就叫做 CAP 定理，又被稱作布魯爾定理（Brewer's theorem）。
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，和更穩定的C。
二、CAP 理論的證明
CAP理論的證明有多種方式，通過反證的方式是最直觀的。反證法來證明CAP定理，最早是由Lynch提出的，通過一個實際場景，如果CAP三者可同時滿足，由於允許P的存在，則一定存在Server 之間的丟包，如此則不能保證C。
單機系統
首先構造一個單機系統，如上圖，ClientA可以發送指令到Server並且設置更新X的值，Client1從Server讀取該值，在單點情況下，即沒有網絡分區的情況下，通過簡單的事務機制，可以保證 Client 1 讀到的始終是最新值，不存在一致性的問題。
分佈式系統
我們在系統中增加一組節點，因為允許分區容錯，Write操作可能在Server1上成功，在Server2上失敗，這時候對於Client1和Client2，就會讀取到不一致的值，出一致的情況。如果要保持 X 值的一致性，Write 操作必須同時失敗， 也就是降低系統的可用性。
可以看到，在分佈式系統中，無法同時滿足 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 還在，就能保證註冊服務可用，只不過查到的信息可能不是最新的版本，不保證一致性，實現了最終一致性。
閱讀更多 Java之高級架構 的文章
