建站
咨詢
售后
建站咨詢
新聞中心
分布式 CAP 原則與 BASE 理論
CAP
CAP 是 Consistency、Availablity、Partition-tolerance 的縮寫，由計算機科學家埃里克·布魯爾在 2000 年提出的，所以又稱布魯爾定理 （Brewer’s theorem），它指出對于一個分布式計算系統(tǒng)來說，不可能同時滿足以下三點
Consistency（一致性）：如果對任意一個節(jié)點的數(shù)據(jù)就行修改成功后，所有其他節(jié)點都能讀取到最新的值，那么這個系統(tǒng)就被認為具有嚴格的一致性。
Availability（可用性）：每次請求都能獲取到非錯的響應，即單節(jié)點宕機可從其他節(jié)點獲取到響應，但是不能保障獲取到的數(shù)據(jù)為最新的數(shù)據(jù)，即和一致性互斥
Partition tolerance（分區(qū)容錯性）：當節(jié)點間出現(xiàn)網(wǎng)絡分區(qū)（不同節(jié)點處于不同的子網(wǎng)絡，子網(wǎng)絡之間是聯(lián)通的，但是子網(wǎng)絡之間是無法聯(lián)通的，也就是被切分成了孤立的集群網(wǎng)絡），照樣可以提供滿足一致性和可用性的服務，除非整個網(wǎng)絡環(huán)境都發(fā)生了故障。
任何一個分布式系統(tǒng)只能滿足三選二，即只能 AP 或 CP，必須要有 P 。
為什么 CAP 只能達到 CP 或者 AP？
CAP 認為分布式環(huán)境下網(wǎng)絡的故障是常態(tài)，比如我們多機房部署下機房間就可能發(fā)生光纜被挖斷、專線故障等網(wǎng)絡分區(qū)情況（導致部分節(jié)點無法通信，原本一個大集群變成多個獨立的小集群），也可能出現(xiàn)網(wǎng)絡波動、丟包、節(jié)點宕機等，所以分布式系統(tǒng)設計要考慮的是在滿足 P 的前提下選擇 C 還是 A。
拋開嚴謹?shù)膶W術證明我們設想工作中的例子：我們要開發(fā)一個分布式緩存服務，只提供簡單的讀取與寫入功能，服務支持多個節(jié)點做數(shù)據(jù)冗余及負載，請求由網(wǎng)關隨機分發(fā)到其中一個節(jié)點，我們必須確保其中一個或幾個節(jié)點故障時另一些節(jié)點仍然可以提供服務，在網(wǎng)絡分區(qū)形成獨立小集群時也可以提供服務，這就必須滿足分區(qū)容錯性（P），我們假設部署了兩個服務節(jié)點，那么：
如果要保證一致性（C），即所有節(jié)點可查詢到的數(shù)據(jù)隨時隨刻都是一致的（同步中的數(shù)據(jù)不可查詢），就要求一個節(jié)點寫入數(shù)據(jù)后必須再將數(shù)據(jù)寫入到另一個節(jié)點后才能返回成功，這樣當我們讀取之前寫入的數(shù)據(jù)時才能確保一致，但上文說明過網(wǎng)絡異常在所難免，如果兩個服務節(jié)點無法相互通訊時為保證一致性在數(shù)據(jù)寫入發(fā)現(xiàn)無法同步到另一節(jié)點時就會返回錯誤進而犧牲了可用性（A）。
如果要保證可用性（A），即只要不是服務宕機所有請求都可得到正確的響應，那么在網(wǎng)絡異常節(jié)點不能通訊的情況下要讓數(shù)據(jù)沒有同步到另一節(jié)點的請求也返回成功，這就必須犧牲一致性（C）導致在一段時間內(nèi)（網(wǎng)絡異常期間）兩個服務節(jié)點所查詢到的數(shù)據(jù)可能不同。
所以從中可以簡單地發(fā)現(xiàn)一致性（C）與可用性（A）是不可能同時滿足的。同 FLP Impossibility 一樣 CAP 理論也為我們做分布式服務架構指明了方向：分布式系統(tǒng)中我們只能選擇 CP（滿足一致性犧牲可用性）或 AP（滿足可用性犧牲一致性）。
當我們選擇 CP，即滿足一致性而犧牲可用性時意味著在網(wǎng)絡異常出現(xiàn)多個節(jié)點孤島時為了保證各個節(jié)點的數(shù)據(jù)一致系統(tǒng)會停止服務，反之選擇 AP，即滿足可用性犧牲一致性時網(wǎng)絡異常時系統(tǒng)仍可工作，但會出現(xiàn)各節(jié)點數(shù)據(jù)不致的情況。
在我們做微服務架構時需要知道 CAP 并做出架構設計或選型。比如注冊中心常用的 Eureka 和 Zookeepr 實現(xiàn)，Eureka 是 AP 的，Zookeeper 是 CP 的，Spring Cloud 之所以推薦 Eureka 是因為它認為注冊中心的場景允許出現(xiàn)短暫的數(shù)據(jù)不一致情況，可用性要高于強一致性，
上面出現(xiàn)了“強一致性”與“弱一致性”兩個概念，這其實是對一致性的延展，大量的工程實踐的經(jīng)驗表明可用性很重要，一致性也很重要，但可以容許一定的時差，即只要保證在一定時間內(nèi)達到一致即可，這也就是所謂的最終一致性。要實現(xiàn)強一致性的成本很高，尤其是存在很多數(shù)據(jù)副本的情況下，區(qū)塊鏈的 PoW 及其衍生算法就是典型的代表，它的共識機制是概率強一致性（Probabilistic Strong Consistency），要求等待大多數(shù)節(jié)點都接受了這筆交易再真正接受它，但是帶來的問題是交易的確認嚴重滯后。
基于此出現(xiàn)了 Base 理論。
BASE
BASE 是由 Basically Available（基本可用）、Soft state（軟狀態(tài)）、Eventually consistent（最終一致性）縮寫而來的。BASE 理論是對 CAP 中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據(jù)自身的業(yè)務特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性，讓 CAP 三者同時基本實現(xiàn)。
Basically Available：基本可用，就是在某個節(jié)點宕機或者發(fā)生網(wǎng)絡分區(qū)的情況，可以讓所有請求都強制走主節(jié)點，這樣保證了數(shù)據(jù)的一致性可可用性，如果主節(jié)點壓力比較大可以觸發(fā)降級熔斷機制等，或者限流等，讓原先 0.5 秒響應的請求以更長的時間去相應
Soft state：軟狀態(tài)相對原子性來說各個要求都有所降低，原子性（硬狀態(tài)），要求多個節(jié)點的數(shù)據(jù)副本都是一致的,這是一種"硬狀態(tài)"。軟狀態(tài)（弱狀態(tài)）允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài),并認為該狀態(tài)不影響系統(tǒng)的整體可用性,即允許系統(tǒng)在多個不同節(jié)點的數(shù)據(jù)副本存在數(shù)據(jù)延遲
Eventually consistent：最終一致性，一致性也分強一致性和弱一致性，而最終一致性屬于弱一致性，就是系統(tǒng)并不保證連續(xù)進程或者線程的訪問都會返回最新的更新過的值。系統(tǒng)在數(shù)據(jù)寫入成功之后，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之后可以讀到。但會盡可能保證在某個時間級別（比如秒級別）之后，可以讓數(shù)據(jù)達到一致性狀態(tài)。
基于 zookeeper 實現(xiàn)注冊中心(CP)
CP 模式，保證一致性
zookeeper 集群
zookeeper 集群是一主多從的模式
zookeeper 集群中的節(jié)點有三種角色
- Leader：處理集群的所有事務請求，集群中只有一個 Leader
- Follwoer：只能處理讀請求，參與 Leader 選舉
- Observer：只能處理讀請求，提升集群讀的性能，但不能參與 Leader 選舉
ZK 集群的數(shù)據(jù)同步機制
正常的客戶端數(shù)據(jù)提交流程（zookeeper 集群服務注冊訂閱）
步驟：
1、首先集群啟動時，會先進行領導者選舉，確定哪個節(jié)點是 Leader ，哪些節(jié)點是 Follower 和 Observer
2、然后 Leader 會和其他節(jié)點進行數(shù)據(jù)同步，采用發(fā)送快照和發(fā)送 Diff 日志的方式
3、集群在工作過程中，所有的寫請求都會交給 Leader 節(jié)點來進行處理，從節(jié)點只能處理讀請求
4、Leader 節(jié)點收到一個寫請求時，會通過兩階段機制來處理
5、Leader 節(jié)點會將該寫請求對應的日志發(fā)送給其他 Follower 節(jié)點，并等待 Follower 節(jié)點持久化日志成功
6、Follower 節(jié)點收到日志后會進行持久化，如果持久化成功則發(fā)送一個 Ack 給 Leader 節(jié)點
7、當 Leader 節(jié)點收到半數(shù)以上的 Ack 后，就會開始提交，先更新 Leader 節(jié)點本地的內(nèi)存數(shù)據(jù)
8、然后發(fā)送 commit 命令給 Follower 節(jié)點， Follower 節(jié)點收到 commit 命令后就會更新各自本地內(nèi)存數(shù)據(jù)
9、同時 Leader 節(jié)點還是將當前寫請求直接發(fā)送給 Observer 節(jié)點， Observer 節(jié)點收到 Leader 發(fā)過來的寫請求后直接執(zhí)行更新本地內(nèi)存數(shù)據(jù)
10、最后 Leader 節(jié)點返回客戶端請求響應成功
結論：通過同步機制和兩階段提交機制來達到集群中節(jié)點數(shù)據(jù)一致
節(jié)點宕機后的 Leader 選舉和數(shù)據(jù)同步流程
當 zookeeper 集群中的 Leader 宕機后，會觸發(fā)新的選舉，選舉期間，整個集群是沒法對外提供服務的。直到選出新的 Leader 之后，才能重新提供服務
選舉
步驟：
1、Leader 掛了，zookeeper 集群不可用
2、通過選舉，F(xiàn)ollwoer1 成為了 Leader，zookeeper 集群可用
3、原來的 Leader 啟動起來了，變成了集群的 Follwoer5
4、Leader 通過 ZXID 事務 ID 向 Follwoer5 同步數(shù)據(jù)，F(xiàn)ollwoer5 可用
結論：在 zookeeper 選舉和同步過程，zookeeper 集群不可用
結論：
不管是正常的客戶端數(shù)據(jù)提交流程還是節(jié)點宕機后的 Leader 選舉和數(shù)據(jù)同步流程都保證了 zookeeper 集群的一致性，但是在節(jié)點宕機后的 Leader 選舉和數(shù)據(jù)同步流程中 zookeeper 集群是不可用的，無法提供可用性，所以 zookeeper 保證了 AP，放棄了 C。
基于 Eureka 實現(xiàn)注冊中心(AP)
AP 模式保證可用性
Eureka 集群
eureka 集群中每個節(jié)點的角色都一樣，都可以提供事物請求和讀請求
eureka 服務注冊與發(fā)現(xiàn)
步驟：
1、Eureka Server 啟動成功，等待服務端注冊。在啟動過程中如果配置了集群，集群之間定時通過 Replicate 同步注冊表，每個 Eureka Server 都存在獨立完整的服務注冊表信息
2、Eureka Client 啟動時根據(jù)配置的 Eureka Server 地址去注冊中心注冊服務
3、Eureka Client 會每 30s 向 Eureka Server 發(fā)送一次心跳請求，證明客戶端服務正常
4、當 Eureka Server 90s 內(nèi)沒有收到 Eureka Client 的心跳，注冊中心則認為該節(jié)點失效，會注銷該實例
5、單位時間內(nèi) Eureka Server 統(tǒng)計到有大量的 Eureka Client 沒有上送心跳，則認為可能為網(wǎng)絡異常，進入自我保護機制，不再剔除沒有上送心跳的客戶端
6、當 Eureka Client 心跳請求恢復正常之后，Eureka Server 自動退出自我保護模式
7、Eureka Client 定時全量或者增量從注冊中心獲取服務注冊表，并且將獲取到的信息緩存到本地
8、服務調(diào)用時，Eureka Client 會先從本地緩存找尋調(diào)取的服務。如果獲取不到，先從注冊中心刷新注冊表，再同步到本地緩存
9、Eureka Client 獲取到目標服務器信息，發(fā)起服務調(diào)用
10、Eureka Client 程序關閉時向 Eureka Server 發(fā)送取消請求，Eureka Server 將實例從注冊表中刪除
結論：
Eureka 集群每個節(jié)點都相等，都可以提供事物請求和讀請求，集群之間定時通過 Replicate 同步注冊表并通過心跳檢測機制去處理 Client 的上下線，保證了 CP，放棄了 A，這里放棄了一致性，只是說放棄了強一致性，去追求最終一致性
參考文獻
《全面解讀 CAP 定理》（https://github.com/Netflix/eureka）
《ZooKeeper：分布式過程協(xié)同技術詳解》（http://www.17bigdata.com/book/zookeeper/index.html）
當前文章：CAP原則之ZK和Eureka注冊中心
網(wǎng)頁路徑：http://m.5511xx.com/article/dhogicj.html
