分布式系統的 CAP 理論:首先把分布式系統中的三個特性進行了如下歸納:
● 一致性(C): 在分布式系統中的所有數據備份，在同一時刻是否同樣的值。(等同于所有節點訪問同一份最新的數據副本)

● 可用性(A): 在集群中一部分節點故障后，集群整體是否還能響應客戶端 的讀寫請求。(對數據更新具備高可用性)

● 分區容忍性(P): 以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前 操作在 C 和 A 之間做出選擇。(分區狀態可以理解為部分機器不連通了，比如機器掛了，繁忙失去響應，單機房故障等)

Partition 字面意思是網絡分區，即因網絡因素將系統分隔為多個單獨的部 分，有人可能會說，網絡分區的情況發生概率非常小啊，是不是不用考慮 P， 保證 CA 就好。要理解 P，我們看回 CAP 證明中 P 的定義:

In order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another。

網絡分區的情況符合該定義，網絡丟包的情況也符合以上定義，另外節點宕 機，其他節點發往宕機節點的包也將丟失，這種情況同樣符合定義。現實情況 下我們面對的是一個不可靠的網絡、有一定概率宕機的設備，這兩個因素都會 導致 Partition，因而分布式系統實現中 P 是一個必須項，而不是可選項。

高可用、數據一致性是很多系統設計的目標，但是分區又是不可避免的事情。 我們來看一看分別擁有 CA、CP 和 AP 的情況。

CA without P:如果不要求 P(不允許分區)，則 C(強一致性)和 A(可用 性)是可以保證的。

但其實分區不是你想不想的問題，而是始終會存在，CA 系 統基本上是單機系統，比如單機數據庫。2PC 是實現強一致性的具體手段。

CP without A:如果不要求 A(可用)，相當于每個請求都需要在 Server 之間 強一致，而 P(分區)會導致同步時間無限延長，如此 CP 也是可以保證的。很 多傳統的數據庫分布式事務都屬于這種模式。

AP wihtout C:要高可用并允許分區，則需放棄一致性。一旦分區發生，節點 之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。現在眾多的 NoSQL 都屬于此類。

CAP 理論的證明

該理論由 Brewer 2000年提出，2002 年，Lynch 與其他人證明了 Brewer 猜想，從而把 CAP 上升為一個定理。但是，它只是證明了 CAP 三者不可能同時滿足，并沒有證明任意二者都可滿足的問題，所以，該證明被認為是一個收窄的結果。

Lynch 的證明相對比較簡單: 采用反證法，如果三者可同時滿足，則因為允許 P 的存在，一定存在 Server 之間的丟包，如此則不能保證 C，證明簡潔而嚴謹。

在該證明中，對 CAP 的定義進行了更明確的聲明:

C:一致性被稱為原子對象，任何的讀寫都應該看起來是 “原子“的，或串行的。寫后面的讀一定能讀到前面寫的內容。所有的讀寫請 求都好像被全局排序一樣。
A:對任何非失敗節點都應該在有限時間內給出請求的回 應。(請求的可終止性)
P:允許節點之間丟失任意多的消息，當網絡分區發生時， 節點之間的消息可能會完全丟失。

對于 CAP 進一步的案例解釋

2010 年的這篇文章 brewers-cap-theorem-on-distributed-systems/，用了三個例子來闡述 CAP，分別是

example1: 單點的 mysql;

example2: 兩個 mysql， 但不同的 mysql 存儲不同的數據子集,相當于sharding;

example3: 兩個 mysql，對 A 的一個 insert 操作，需要在 B 上執行成功才認為操作完成(類似復制集)。

作者認為在 example1 和 example2 上都能保證強一致性，但不能保證可用性;

在 example3 這個例子，由于分區(partition)的存在，就需要在一致性與可用性之間權衡。

對于復制而言，在很多場景下不追求強一致性。比如用戶支付之后，交易記錄落地了; 但可能消費記錄的消息同步存在延遲，比如消息阻塞了。

在金融業務中，采取類似兩地三中心架構，往往可能采取本地數據和異地機房數據同時寫成功再返回的方式。這樣付出了性能的損耗，響應時間變長。但發生機房故障后，能確保數據是完全可以讀寫的，保障了一致性。

CAP 理論澄清

[CAP 理論十二年回顧: "規則"變了]一文首發于 Computer 雜志，后由 InfoQ 和 IEEE 聯合呈現, 非常精彩[2]，文章表達了幾個觀點。

“三選二”是一個偽命題

不是為了 P(分區容忍性)，要在 A 和 C 之間選擇一個。分區很少出現，CAP 在大多數時候允許完美的 C 和 A。但當分區存在或可感知其影響的情況下，就要預備一種策略去探知分區并顯式處理其影響。這樣的策略應分為三個步驟:

探知分區發生，

進入顯式的分區模式以限制某些操作，

啟動恢復過程以恢復數據一致性并補償分區期間發生的錯誤。

“一致性的作用范圍”其實反映了這樣一種觀念，即在一定的邊界內狀態是一 致的，但超出了邊界就無從談起。

比如在一個主分區內可以保證完備的一致性和可用性，而在分區外服務是不可用的。

Paxos 算法和原子性多播(atomic multicast)系統一般符合這樣的場景。像 Google 的一般做法是將主分區歸屬 在單個數據中心里面，然后交給 Paxos 算法去解決跨區域的問題，一方面保證 全局協商一致(global consensus)如 Chubby，一方面實現高可用的持久性存 儲如 Megastore。

ACID、BASE、CAP

ACID 和 BASE 這兩個術語都好記有余而精確不足，出現較晚的 BASE 硬湊的感覺更明顯，它是“Basically Available, Soft state, Eventually consistent (基本可用、軟狀態、最終一致性)”的首字母縮寫。其中的軟狀態和最終一致性這兩種技巧擅于對付存在分區的場合，并因此高了可用性。

CAP 與 ACID 的關系更復雜一些，也因此引起更多誤解。其中一個原因是 ACID 的 C 和 A 字母所代表的概念不同于 CAP 的 C 和 A。還有一個原因是選擇可用性只部分地影響 ACID 約束。

進一步看[分區]之后

用一下這張圖[引用自 link 2]，在狀態 S 的時候是非分區狀態，而分區模式則 演化出來了 S1，S2，那么問題來了，分區恢復之后，狀態究竟是多少呢?有幾種解決方案。

分區恢復策略: 可交換多副本數據類型 (注意，能支持此類處理的場景是有限的。)

riak_dt 就是這樣一種保障最終一致性實現的數據結構，它分為Operation- based CRDTs、State-based CRDTs 2 種形態。
riak_dt link 參見 link [3]。

分區恢復策略:回放合并在分區恢復過程中，設計師必須解決兩個問題:

分區兩側的狀態最終必須保持一致
并且必須補償分區期間產生的錯誤。

如上圖所示，對于分區恢復的狀態 S*可以通過未分區時的狀態 S 為起點，然后按順序[回放]相應的變化事件[以特定方式推進分區兩側的一系列操作，并在過程中一直保持一致的狀態。Bayou[link 4]就是這個實現機制，它會回滾數據庫到正確的時刻并按無歧義的、確定性的順序重新執行所有的操作，最終使所有的節點達到相同的狀態。

對于有沖突的情況，比如版本管理軟件 cvs，存在人工介入、消除沖突的處理策略。

原文發布時間為：2018-03-19

本文作者：小程故事多@簡書

本文來自云棲社區合作伙伴“中生代技術”，了解相關信息可以關注“中生代技術”微信公眾號

總結

以上是生活随笔為你收集整理的分布式理论：CAP是三选二吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。