歷史
這個定理起源于柏克萊加州大學University of California, Berkeley的計算機科學家埃里克·布魯爾在2000年的分布式計算原則研討會(Symposium on Principles of Distributed Computing(PODC))上提出的一個猜想。 在2002年,麻省理工學院(MIT)的賽斯·吉爾伯特和南希·林奇發表了布魯爾猜想的證明,使之成為一個定理。
吉爾伯特和林奇證明的CAP定理比布魯爾設想的某種程度上更加狹義。定理討論了在兩個互相矛盾的請求到達彼此連接不通的兩個不同的分布式節點的時候的處理方案。
CAP介紹
在理論計算機科學中,CAP定理(CAP theorem),又被稱作布魯爾定理(Brewer's theorem),它指出對于一個分布式計算系統來說,不可能同時滿足以下三點:
- 一致性(Consistency) (等同于所有節點訪問同一份最新的數據副本)
- 可用性(Availability)(每次請求都能獲取到非錯的響應——但是不保證獲取的數據為最新數據)
- 分區容錯性(Partition tolerance)(以實際效果而言,分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性,就意味著發生了分區的情況,必須就當前操作在C和A之間做出選擇)
根據定理,分布式系統只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致,即喪失了C性質。如果為了保證數據一致性,將分區一側的節點設置為不可用,那么又喪失了A性質。除非兩個節點可以互相通信,才能既保證C又保證A,這又會導致喪失P性質。
CAP證明
我們現在有兩個網絡N1和N2,每個網絡中都存在一個服務用于從db獲取數據,初始狀態下,db中存儲的數據都是V0。
正常情況下,在網絡N1通過服務A更新V0到V1,更新成功后發送消息M使N2 db中的V0變為V1,此時我們通過服務B獲取數據時,獲取到V1。
此時為CA,沒有分區
但是一旦發生了網絡分區(分區容錯性強制擁有),此時我們通過服務A更新數據到V1后,由于網絡錯誤,V1值同步不到N2網絡中去,此時我們調用服務B去請求數據的時候,我們必須從C和A選一個,如果選擇C,我們需要等到數據同步到N2,但是從服務B獲取數據肯定是失敗了,失去了A。如果選擇A,那么從B我們獲取到的數據不是最新的,失去了C。
分區后,P滿足,只能CA之間選擇
CAP應用
CAP存在的問題
在CAP理論中,有一點很理想化,它沒有考慮網絡延遲,他認為C都是立刻生效的,實際上同步這個操作肯定存在延遲。因此對于分布式系統,我們一般都采用AP。
CA取舍
從上面這張圖,我們可以看到我們的分布式應用分為三個狀態,一致狀態,分區狀態,分區恢復狀態。
對于分布式系統來講,避免不了分區狀態和分區恢復狀態,一旦進入,我們必須在C和A之間做出妥協,這個妥協也不是說你只選擇C而完全不考慮A,可以在CA的實現比例上進行權衡,比如主A輔C,實現基本可用,最終一致。BASE理論就是用來解決這個問題。
BASE理論
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫,是對 CAP 中 AP 的一個擴展。
基本可用:分布式系統在出現故障時,允許損失部分可用功能,保證核心功能可用。
軟狀態:允許系統中存在中間狀態,這個狀態不影響系統可用性,這里指的是 CAP 中的不一致。
最終一致:最終一致是指經過一段時間后,所有節點數據都將會達到一致。
BASE 解決了 CAP 中理論沒有網絡延遲,在 BASE 中用軟狀態和最終一致,保證了延遲后的一致性。
BASE 和 ACID 是相反的,它完全不同于 ACID 的強一致性模型,而是通過犧牲強一致性來獲得可用性,并允許數據在一段時間內是不一致的,但最終達到一致狀態。
BASE理論的意義在于,我們不必在A或C中做出選擇,可以實現部分的A和C
應用CAP分析
應用 | 類型 | 其他 |
---|---|---|
Mysql | CA | 主從模式為AP |
ZooKeeper | CP | 在分區后,對于A,只有分區內節點大于quorum才對外服務 |
Eureka | AP | 最終一致性 |
Redis哨兵/集群模式 | AP | 最終一致性,單體肯定是CA |
RocketMQ主從 | AP | 最終一致性 |
分布式事務-2pc | CP | 鎖住資源,該資源其他請求阻塞 |
分布式事務-TCC | AP | 最終一致性 |
分布式事務-最大努力嘗試 | AP | 最終一致性 |
總結
個人認為,CAP定理的核心在于,在網絡分區的情況下,我們需要對C和A做出相應的妥協,我們不可能完全滿足CA,但是我們可以合理控制C和A之間的比例讓我們的應用/中間件正常提供服務。
下面是我公眾號,大家可以關注下。