孫玄

讀完需要

5

分鐘

速讀僅需 2 分鐘

1

? ?

CAP 的前世今生

1.1

? ?

起源

CAP 理論，被戲稱為“帽子理論”，CAP 是 Eric Brewer 在 2000 年 ACM 研討會上出了一個想法：“一致性、可用性和分區容錯性三者無法在分布式系統中被同時滿足，并且最多只能滿足其中兩個！”

2002 年，Seth Gilbert 和 Nancy Lynch 采用反正法證明了猜想：“如果三者可同時滿足，則因為允許 P 的存在，一定存在 Server 之間的丟包，如此則不能保證 C。” 在該證明中，對 CAP 的定義進行了更明確的聲明。

C：一致性被稱為原子對象，任何的讀寫都應該看起來是“原子”，或串行的。寫后面的讀一定能讀到前面寫的內容，所有的讀寫請求都好像被全局排序。

A：對任何非失敗節點都應該在有限時間內給出請求的回應。（請求的可終止性）

P：允許節點之間丟失任意多的消息，當網絡分區發生時，節點之間的消息可能會完全丟失。

但是只證明了 CAP 三者不可能同時滿足，并沒有證明任意二者都可滿足的問題；所以該證明被認為是一個收窄的結果，在之后 10 年里受到各種質疑。

1.2

? ?

重新詮釋

2012 年，Brewer 和 Lynch 針對所有的質疑進行了回應，重新詮釋 CAP。“3 個中的 2 個”表述是不準確的，在某些分區極少發生的情況下，三者也能順暢地配合。CAP 不僅僅是發生在整個系統中，可能是發生在某個子系統或系統的某個階段。把 CAP 理論的證明局限在原子讀寫的場景，并申明不支持數據庫事務之類的場景。一致性場景不會引入用戶 agent，只是發生在后臺集群之內。把分區容錯歸結為一個對網絡環境的陳述，而非之前一個獨立條件。引入了活(liveness)和安全屬性(safety)，在一個更抽象的概念下研究分布式系統，并認為 CAP 是活性與安全屬性之間權衡的一個特例。其中的一致性屬于 liveness，可用性屬 safety。

網絡存在同步、部分同步；一致性性的結果也從僅存在一個到存在 N 個（部分一致）；引入了通信周期 round，保證 N 個一致性結果。

總結：縮小 CAP 適用的定義，消除質疑的場景；展示了 CAP 在非單一一致性結果下的廣闊的研究結果。

2

? ?

CAP 的分析

2.1

? ?

組成

Consistency：一致性

Availability：可用性

Partition tolerance：分區容忍性

2.2

? ?

Consistency

從論文上看：操作之后的讀操作，必須返回該值。

從百科上看：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。

總結：在分布式系統中，C 代表任何人在任何地點、任何時間，訪問任何數據 結果都是一致的。

2.3

? ?

Availability

從論文上看：只要收到用戶的請求，服務器就必須給出回應。

從百科上看：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。

總結：在分布式系統中，A 代表服務在任何時候都要是可用的、可訪問。

2.4

? ?

Partition tolerance

從論文上看：直譯叫“分區容錯”，意思是區間通信可能失敗。

從百科上看：分區相當于對通信的時限要求。

總結：分區容錯=分區+容錯。分布式系統因為多實例部署，面臨多個子網絡，多個子網絡存在網絡通訊的需求；因為網絡通訊的不可靠性造成分區的存在。而分區的存在，不可避免出現數據和可用性問題，需要有容錯機制來處理。

3

? ?

實踐分析

3.1

? ?

A 與 P 的差異

從上述的描述中，因為兩者都有容錯可用的描述，我們很容易將 A 跟 P 混淆在一起。接下去，咱們從各個維度去分析 C 與 P 的差異。

從關注點來說，A 關注的是用戶對分布式系統的可用要求；P 關注的是分布式系統實例間的網絡連通性。

從要求上來看，A 從外部的視角，要求分布式系統在正常響應時間內一直可用；P 從實例節點的視角出發，在遇到某節點或節點間通信故障的時候，要求分布式系統整體對節點的容錯及恢復性。

從受眾上分析，A 針對的是用戶，P 針對的是服務實例。

3.2

? ?

CP 與 AP

三者的組合，產生了 AC、AP、CP 三個組合。但在分布式環境中，多實例部署是基本條件，因為網絡的不可靠性，造成了 P 成了硬性條件。所以結果就轉化成了 CP、AP 兩個分支。

CP、AP 分支代表的是硬性條件，在這個基礎上去追求利益化才是這個分支的本質問題。如果是粗暴的對另外一個選項直接放棄，那這個世界就太 simple、easy 了，而且也不符合咱們對系統的期望和基本使用。這就是 2012 年重新詮釋后 CAP 的最終狀態意義，“三選二”是一個偽命題。

基于這個 2012 年 CAP 的最終意義，咱們發現 CP 不是簡單的放棄 A，而是保障 CP 的硬性條件去追求 A。所以產生了過半寫入這樣非常經典的使用方式:過半寫入后，分布式節點可以根據少數服從多數完成數據的一致性要求。因此產生了最大的效益

分布式實例的更高可用性，對所有實例不在全部寫入成功才認為是成功。

分布式實例的更快響應性，使用廣播快速獲取過半結果后直接認定結果。依靠補充手段實現數據的一致性。

說完 CP 的改變，再說說 AP 的對應調整升級。咱們為了高可用放棄數據的一致性，其實這個說法是不嚴謹，也是錯誤的。數據一致性是系統的基本要求。那么要怎么理解 AP，應該從臟讀、幻讀來說，場景允許數據的短暫不一致，接受數據的最終一致性。

數據的嚴謹性是系統的一個要求，但允許數據的一定延遲是 AP 存在的意義。

系統的高可用可以滿足更多的群體，從這個的目標上，所以 AP 是比較友好的

因為分布式系統，系統是多層面的組合型存在，所以我們并不會說一個系統是 AP 還是 CP。我們是根據系統的業務場景去選擇 CP 和 AP，但是高可用是互聯網分布式應用的特性，所以我們絕大部分情況是追求 AP，盡量讓系統滿足更多的用戶。然后基于某些場景數據的強一致性必要性去選擇 CP。

4

? ?

總結

在分布式環境下，對 cap 的要求。不管 cp 還是 ap，并不是完全丟棄另一個，而是優先級問題；在滿足 C 或者 A 的基礎上去追求另外一個，結論如下：

CP--在強一致性的底線上追求可用性 (案例-過半寫入)。

AP—在高可用的基礎上追求數據的一致性(案例-最終一致性)。

系統以 AP 為基調，在一些數據高即時、一致性場景使用 CP 進行補充。

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

技術人成長精彩文章推薦

阿里高級技術專家宋意：平凡人在阿里十年的成長之旅

RocketMQ 大神丁威親述參與開源社區的方式

多隆：從工程師到阿里巴巴合伙人

為什么說IT科技公司應該留住35歲員工？

工程師的基本功是什么？如何練習？聽美團技術大咖怎么說

美團技術專家云鵬:寫給工程師的十條精進原則!

找CTO杜仲：再談中年危機和應對策略

阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話

Erik Dietrich：二十年的編程，教會我的五件事！

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路

Mobvista首席架構師蔡超：工作感悟之失敗與成功，我的8點總結

奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考

Netstars CTO陳斌：架構師的成長之路

阿里技術專家麒燁：修煉測試基本功

左耳朵耗子：程序員如何把控自己的職業？

阿里6年，我的技術蛻變之路！

程序員管理思維修煉，只需要反復閱讀本篇

“教授”洪強寧和他穿越的技術江湖

大神手把手教你投身技術18年而沒有中年危機的秘訣

阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽

CTO 技術管理的“三板斧”

技術管理者必備管理模板

張一鳴：優秀年輕人的五個特點

技術團隊的工程師文化：效率與價值

美團大咖：程序員35歲前應做好的技術積累

史海峰：萬字長文剖析技術人如何成長

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

以上是生活随笔為你收集整理的玄姐出品：想和兄弟、集美们聊聊“分布式CAP”中情侣的纠缠故事，真是剪不断 理还乱！...的全部內容，希望文章能夠幫你解決所遇到的問題。

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