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

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

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

Partition 字面意思是網(wǎng)絡(luò)分區(qū)，即因網(wǎng)絡(luò)因素將系統(tǒng)分隔為多個單獨的部 分，有人可能會說，網(wǎng)絡(luò)分區(qū)的情況發(fā)生概率非常小啊，是不是不用考慮 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。

網(wǎng)絡(luò)分區(qū)的情況符合該定義，網(wǎng)絡(luò)丟包的情況也符合以上定義，另外節(jié)點宕 機，其他節(jié)點發(fā)往宕機節(jié)點的包也將丟失，這種情況同樣符合定義。現(xiàn)實情況 下我們面對的是一個不可靠的網(wǎng)絡(luò)、有一定概率宕機的設(shè)備，這兩個因素都會 導(dǎo)致 Partition，因而分布式系統(tǒng)實現(xiàn)中 P 是一個必須項，而不是可選項。

高可用、數(shù)據(jù)一致性是很多系統(tǒng)設(shè)計的目標(biāo)，但是分區(qū)又是不可避免的事情。 我們來看一看分別擁有 CA、CP 和 AP 的情況。

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

但其實分區(qū)不是你想不想的問題，而是始終會存在，CA 系 統(tǒng)基本上是單機系統(tǒng)，比如單機數(shù)據(jù)庫。2PC 是實現(xiàn)強一致性的具體手段。

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

AP wihtout C:要高可用并允許分區(qū)，則需放棄一致性。一旦分區(qū)發(fā)生，節(jié)點 之間可能會失去聯(lián)系，為了高可用，每個節(jié)點只能用本地數(shù)據(jù)提供服務(wù)，而這樣會導(dǎo)致全局數(shù)據(jù)的不一致性。現(xiàn)在眾多的 NoSQL 都屬于此類。

CAP 理論的證明

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

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

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

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

對于 CAP 進一步的案例解釋

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

example1: 單點的 mysql;

example2: 兩個 mysql， 但不同的 mysql 存儲不同的數(shù)據(jù)子集,相當(dāng)于sharding;

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

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

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

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

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

CAP 理論澄清

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

“三選二”是一個偽命題

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

探知分區(qū)發(fā)生，

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

啟動恢復(fù)過程以恢復(fù)數(shù)據(jù)一致性并補償分區(qū)期間發(fā)生的錯誤。

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

比如在一個主分區(qū)內(nèi)可以保證完備的一致性和可用性，而在分區(qū)外服務(wù)是不可用的。

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

ACID、BASE、CAP

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

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

進一步看[分區(qū)]之后

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

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

riak_dt 就是這樣一種保障最終一致性實現(xiàn)的數(shù)據(jù)結(jié)構(gòu)，它分為Operation- based CRDTs、State-based CRDTs 2 種形態(tài)。
riak_dt link 參見 link [3]。

分區(qū)恢復(fù)策略:回放合并在分區(qū)恢復(fù)過程中，設(shè)計師必須解決兩個問題:

分區(qū)兩側(cè)的狀態(tài)最終必須保持一致
并且必須補償分區(qū)期間產(chǎn)生的錯誤。

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

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

原文發(fā)布時間為：2018-03-19

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

本文來自云棲社區(qū)合作伙伴“中生代技術(shù)”，了解相關(guān)信息可以關(guān)注“中生代技術(shù)”微信公眾號

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。