CAP和BASE理論

CAP理論

CAP 理論指出對於一個分散式計算系統來說，不可能同時滿足一致性（C:Consistency）、可用性（A:Availability）和分割槽容錯性（P:Partition tolerance）這三個基本需求，最多隻能同時滿足其中的兩項，P 是必須的，因此只能在CP和AP中選擇。

一致性

在分散式環境中，一致性是指資料在多個副本之間是否能夠保持一致的特性，等同於所有節點訪問同一份最新的資料副本。在一致性的需求下，當一個系統在資料一致的狀態下執行更新操作後，應該保證系統的資料仍然處於一致的狀態。

可用性

​ 可用性是指系統提供的服務必須一直處於可用的狀態，對於使用者的每一個操作請求總是能夠在有限的時間內返回結果

分割槽容錯性

​ 分散式系統在遇到任何網路分割槽故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網路環境都發生了故障。

一個分散式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分割槽容錯性（Partition tolerance）這三項中的兩項。

在這三個基本需求中，最多隻能同時滿足其中的兩項，P 是必須的，因此只能在 CP 和 AP 中選擇。

BASE理論

BASE 是 Basically Available(基本可用)、Soft-state(軟狀態) 和 Eventually Consistent(最終一致性) 三個短語的縮寫。

基本可用

在分散式系統出現故障，允許損失部分可用性（服務降級、頁面降級）。

• 響應時間上的損失：
• 功能上的損失

軟狀態

允許分散式系統出現中間狀態。而且中間狀態不影響系統的可用性。這裡的中間狀態是指不同的data replication（資料備份節點）之間的資料更新可以出現延時的最終一致性。

最終一致性

data replications 經過一段時間達到一致性。

最終一致性是一種特殊的弱一致性：系統能保證在沒有其他新的更新操作的情況下，資料最終一定能夠達到一致的狀態，因此所有客戶端對系統的資料訪問都能夠獲取到最新的值。

在實際工程實踐中，最終一致性存在以下五類主要變種：因果一致性；讀己之所寫；會話一致性；單調讀一致性；單調寫一致性。

BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性。

一致性協議

設計一個分散式系統必定會遇到一個問題—— 因為分割槽容忍性（partition tolerance）的存在，就必定要求我們需要在系統可用性（availability）和資料一致性（consistency）中做出權衡 。這就是著名的 CAP 定理。

解決分散式一致性問題，有二階段提交協議、三階段提交協議和Paxos演算法。

2PC（兩階段提交）

2PC，是Two-Phase-Commit的縮寫，即二階段提交，是計算機網路尤其是資料庫領域內，為了是基於分散式系統架構下的所有節點在進行事務處理過程中能夠保持原子性和一致性而設計的一種演算法。

目前，絕大部分的關係型資料庫都是採用二階段提交協議來完成分散式事務處理的。

協議說明

顧名思義，二階段提交協議是將事務的提交過程分成了兩個階段來進行處理。

階段一：提交事務請求

整個過程近似是協調者組織各參與者對一次事務操作的投票表態過程，因此也成為“投票階段”。

1.事務詢問。

協調者向所有參與者傳送事務內容，詢問是否可以執行事務提交操作(vote)，並開始等待各參與者的響應。

2.執行事務。

各參與者執行事務操作，並將Undo資訊和Redo資訊寫入日誌。（注意：若成功這裡其實每個參與者已經執行了事務操作）

3.各參與者向協調者反饋事務詢問的相應。

如果參與者成功執行事務操作，那麼就反饋給協調者YES響應，表示事務可以執行；如果參與者的事務操作實際執行失敗，那麼久反饋給協調者No響應，表示事務不可以執行。

階段二：執行事務提交

在階段二中，協調者會根據各參與者的反饋情況來決定最終是否可以進行事務提交操作。正常情況下，包含以下兩種可能。

執行事務提交

假如協調者從所有的參與者獲得的反饋都是Yes相應，那麼就會執行事務提交。

1.傳送提交請求：協調者向所有參與者節點發出Commit請求。

2.事務提交：參與者接收到Commit請求後，會正式執行事務提交操作，並在完成提交之後釋放在整個事務執行期間佔用的事務資源，

3.反饋事務提交結果：參與者在完成事務提交之後，向協調者傳送Ack訊息。

4.完成事務：協調者接收到所有參與者反饋的Ack訊息後，完成事務。

中斷事務

假如任何一個參與者向協調者反饋了No響應，或者在等待超時之後，協調者尚無接收到所有參與者的反饋響應，那麼就會中斷事務。

1.傳送回滾請求：協調者向所有參與者節點發出Rollback請求。

2.事務回滾：參與者接收到Rollback請求後，會利用其在一階段中記錄的Undo資訊來執行事務回滾操作，並在完成回滾之後釋放在整個事務執行期間佔用的資源。

3.反饋事務回滾結果：參與者在完成事務回滾之後，向協調者傳送Ack訊息。

4.中斷事務：協調者接收到所有參與者反饋的Ack訊息後，完成事務中斷。

簡單地講，二階段提交將一個事務的處理過程分為了投票和執行兩個階段，其核心是對每個事務採用先嚐試後提交的處理方式，因此可以將二階段提交看作一個強一致性的演算法。

優缺點

二階段提交協議的優點是：原理簡單，實現方便，

二階段提交協議的缺點：同步堵塞、單點問題、腦裂、太過保守。

同步阻塞：在二階段提交的執行過程中，所有參與該事務操作的邏輯都處於堵塞狀態。

單點問題：一旦協調者出現問題，那麼整個二階段提交流程將無法運轉，更嚴重的是，如果協調者是在階段二出現問題的話，那麼其他參與者將會一直處於鎖定事務資源的狀態中，而無法繼續完成事務操作。

資料不一致：在二階段提交協議的階段二，即執行事務提交的時候，當協調者向所有的參與者傳送Commit請求之後，發生了局部網路異常或者是協調者在尚未傳送完Commit請求之前自身發生了崩潰，導致最終只有部分參與者收到了Commit請求。於是，這部分收到了Commit請求的參與者就會進行事務的提交，而其他沒有收到Commit請求的參與者則無法進行事務提交。

太過保守：二階段提交協議沒有設計較為完善的容錯機制，任意一個節點的失敗都會導致整個事務的失敗。

3PC（三階段提交 ）

二階段協議在實際執行過程中可能存在諸如同步阻塞、協調者的單點問題、腦裂和太過保守的容錯機制等缺陷。

協議說明

3PC，是Three-Phase Commit的縮寫，即三階段提交，其將二階段提交協議的“提交事務請求”過程一分為二，形成了由CanCommit、PreCommit和do Commit三個階段組成的事務處理協議。

階段一：CanCommit

1 .事務詢問。

協調者向所有的參與者傳送一個包含事務內容的canCommit請求，詢問是否可以執行事務提交操作，並開始等待各參與者的響應。

2 .各參與者向協調者反饋事務詢問的響應。

參與者在接收到來自協調者的canCommit請求後，正常情況下，如果其自身認為可以順利執行事務，那麼會反饋Yes響應，並進入預備狀態，否則反饋No響應。

階段二：PreCommit

在階段二中,協調者會根據各參與者的反饋情況來決定是否可以進行事務的PreCommit操作，正常情況下，包含兩種可能。

執行事務預提交

假如協調者從所有的參與者獲得的反饋都是Yes響應，那麼就會執行事務預提交。

1 .傳送預提交請求。

協調者向所有參與者節點發出preCommit的請求，並進入Prepared階段。

2 .事務預提交。

參與者接收到preCommit請求後，會執行事務操作，並將Undo和Redo資訊記錄到事務日誌中。

3.各參與者向協調者反饋事務執行的響應。

如果參與者成功執行了事務操作，那麼就會反饋給協調者Ack響應，同時等待最終的指令：提交(commit)或中止(abort)。

中斷事務

假如任何一個參與者向協調者反饋了 No響應，或者在等待超時之後，協調者尚無法接收到所有參與者的反饋響應，那麼就會中斷事務。

1 .傳送中斷請求。

協調者向所有參與者節點發出abort請求。

2 .中斷事務。

無論是收到來自協調者的abort請求，或者是在等待協調者請求過程中出現超時，參與者都會中斷事務。

階段三：doCommit

該階段將進行真正的事務提交,會存在以下兩種可能的情況。

執行提交

1.傳送提交請求。

進入這一階段，假設協調者處於正常工作狀態，並且它接收到了來自所有參與者的Ack響應，那麼它將從“預提交”狀態轉換到“提交”狀態，並向所有的參與者傳送doCommit請求。

2 .事務提交。

參與者接收到doCommil請求後，會正式執行事務提交操作，並在完成提交之後釋放在整個事務執行期間佔用的事務資源。

3 .反饋事務提交結果。

參與者在完成事務提交之後，向協調者傳送Ack訊息。

4 .完成事務。

協調者接收到所有參與者反饋的Ack訊息後,完成事務。

中斷事務

進入這一階段，假設協調者處f正常工作狀態,並且有任意一個參與者向協調者反饋了 No響應,或者在等待超時之後，協調者尚無法接收到所有參與者的反饋響應，那麼就會中斷事務。

1 .傳送中斷請求。

協調者向所有的參與者節點發送abort請求。

2 .事務回滾。

參與者接收到abort請求後，會利用其在階段二中記錄的Undo資訊來執行事務回滾操作，並在完成同潦之後釋放在整個事務執行期間佔用的資源。

3 .反饋事務回滾結果。

參與者在完成事務回滾之後，向協調者傳送Ack訊息。

4 .中斷事務。

協調者接收到所有參與者反饋的Ack訊息後，中斷事務。

需要注意的是，一旦進入階段三，可能會存在以下兩種故障。

• 協調者出現問題。
• 協調者和參與者之間的網路出現故障。

無論出現哪種情況，最終都會導致參與者無法及時接收到來自協調者的doCommit或是 abort請求，針對這樣的異常情況，參與者都會在等待超時之後，繼續進行事務提交。

優缺點

三階段提交協議的優點：相較於二階段提交協議，三階段提交協議最大的優點就是降低了參與者的阻塞範圍，並且能夠在出現單點故障後繼續達成一致。

三階段提交協議的缺點：三階段提交協議在去除阻塞的同時也引入了新的問題，那就是在參與者接收到PreCommit訊息後，如果網路出現分割槽，此時協調者所在的節點和參與者無法進行正常的網路通訊，在這種情況下，該參與者依然會進行事務的提交，這必然出現數據的不一致性。

Paxos演算法

Paxos演算法需要解決的是在可能發生機器宕機或網路異常的分散式系統中，快速且正確地在叢集內部對某個資料的值達成一致，並且保證不論發生以上任何異常，都不會破壞整個系統的一致性。

Paxos 演算法是基於訊息傳遞且具有高度容錯特性的一致性演算法，是目前公認的解決分散式一致性問題最有效的演算法之一，其解決的問題就是在分散式系統中如何就某個值（決議）達成一致 。

在 Paxos 中主要有三個角色，分別為 Proposer提案者、Acceptor表決者、Learner學習者。Paxos 演算法和 2PC 一樣，也有兩個階段，分別為 Prepare 和 accept 階段。

prepare 階段

Proposer提案者：負責提出 proposal，每個提案者在提出提案時都會首先獲取到一個 具有全域性唯一性的、遞增的提案編號N，即在整個叢集中是唯一的編號 N，然後將該編號賦予其要提出的提案，在第一階段是隻將提案編號傳送給所有的表決者。

Acceptor表決者：每個表決者在 accept 某提案後，會將該提案編號N記錄在本地，這樣每個表決者中儲存的已經被 accept 的提案中會存在一個編號最大的提案，其編號假設為 maxN。每個表決者僅會 accept 編號大於自己本地 maxN 的提案，在批准提案時表決者會將以前接受過的最大編號的提案作為響應反饋給 Proposer 。

accept 階段

當一個提案被 Proposer 提出後，如果 Proposer 收到了超過半數的 Acceptor 的批准（Proposer 本身同意），那麼此時 Proposer 會給所有的 Acceptor 傳送真正的提案（你可以理解為第一階段為試探），這個時候 Proposer 就會發送提案的內容和提案編號。

表決者收到提案請求後會再次比較本身已經批准過的最大提案編號和該提案編號，如果該提案編號 大於等於 已經批准過的最大提案編號，那麼就 accept 該提案（此時執行提案內容但不提交），隨後將情況返回給 Proposer 。如果不滿足則不迴應或者返回 NO 。

當 Proposer 收到超過半數的 accept ，那麼它這個時候會向所有的 acceptor 傳送提案的提交請求。需要注意的是，因為上述僅僅是超過半數的 acceptor 批准執行了該提案內容，其他沒有批准的並沒有執行該提案內容，所以這個時候需要向未批准的 acceptor 傳送提案內容和提案編號並讓它無條件執行和提交，而對於前面已經批准過該提案的 acceptor 來說 僅僅需要傳送該提案的編號 ，讓 acceptor 執行提交就行了。

而如果 Proposer 如果沒有收到超過半數的 accept 那麼它將會將 遞增 該 Proposal 的編號，然後 重新進入 Prepare 階段 。

ZAB協議

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協議是為分散式協調服務 ZooKeeper 專門設計的一種支援崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分散式資料一致性，基於該協議，ZooKeeper 實現了一種主備模式的系統架構來保持叢集中各個副本之間的資料一致性。

ZooKeeper 在解決分散式資料一致性問題時並沒有直接使用 Paxos ，而是專門定製了一致性協議叫做 ZAB(ZooKeeper Atomic Broadcast) 原子廣播協議，該協議能夠很好地支援 崩潰恢復 。

ZAB 中三個主要的角色，Leader 領導者、Follower跟隨者、Observer觀察者 。

• Leader ：叢集中 唯一的寫請求處理者 ，能夠發起投票（投票也是為了進行寫請求）。
• Follower：能夠接收客戶端的請求，如果是讀請求則可以自己處理，如果是寫請求則要轉發給 Leader 。在選舉過程中會參與投票，有選舉權和被選舉權 。
• Observer ：就是沒有選舉權和被選舉權的 Follower 。

ZAB 協議包括兩種基本模式，分別是 訊息廣播 和 崩潰恢復 。

訊息廣播

當叢集中已經有過半的 Follower 伺服器完成了和 Leader 伺服器的狀態同步，那麼整個服務框架就可以進入訊息廣播模式了。 當一臺同樣遵守 ZAB 協議的伺服器啟動後加入到叢集中時，如果此時叢集中已經存在一個 Leader 伺服器在負責進行訊息廣播，那麼新加入的伺服器就會自覺地進入資料恢復模式：找到 Leader 所在的伺服器，並與其進行資料同步，然後一起參與到訊息廣播流程中去。

崩潰恢復

當整個服務框架在啟動過程中，或是當 Leader 伺服器出現網路中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進入恢復模式並選舉產生新的 Leader 伺服器。當選舉產生了新的 Leader 伺服器，同時叢集中已經有過半的機器與該 Leader 伺服器完成了狀態同步之後，ZAB 協議就會退出恢復模式。其中，所謂的狀態同步是指資料同步，用來保證叢集中存在過半的機器能夠和 Leader 伺服器的資料狀態保持一致。

Zookeeper概述

ZooKeeper 是一個開源的分散式協調服務，它的設計目標是將那些複雜且容易出錯的分散式一致性服務封裝起來，構成一個高效可靠的原語集，並以一系列簡單易用的介面提供給使用者使用。

ZooKeeper 為我們提供了高可用、高效能、穩定的分散式資料一致性解決方案，通常被用於實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。

ZooKeeper 特點

• 順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。
• 原子性： 所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一致的，也就是說，要麼整個叢集中所有的機器都成功應用了某一個事務，要麼都沒有應用。
• 單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 伺服器上，其看到的服務端資料模型都是一致的。
• 可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。

ZooKeeper 典型應用場景

ZooKeeper 通常被用於實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。

分散式鎖 ： 通過建立唯一節點獲得分散式鎖，當獲得鎖的一方執行完相關程式碼或者是掛掉之後就釋放鎖。

讓多個客戶端同時建立一個臨時節點，建立成功的就說明獲取到了鎖 。然後沒有獲取到鎖的客戶端的非主節點建立一個 watcher 進行節點狀態的監聽，如果這個鎖被釋放了（可能獲取鎖的客戶端宕機了，或者那個客戶端主動釋放了鎖）可以呼叫回撥函式重新獲得鎖。

命名服務 ：可以通過 ZooKeeper 的順序節點生成全域性唯一 ID

資料釋出/訂閱 ：通過 Watcher 機制 可以很方便地實現資料釋出/訂閱。當你將資料釋出到 ZooKeeper 被監聽的節點上，其他機器可通過監聽 ZooKeeper 上節點的變化來實現配置的動態更新。

用到 ZooKeeper的開源專案

Kafka : ZooKeeper 主要為 Kafka 提供 Broker 和 Topic 的註冊以及多個 Partition 的負載均衡等功能。

Hbase : ZooKeeper 為 Hbase 提供確保整個叢集只有一個 Master 以及儲存和提供 regionserver 狀態資訊（是否線上）等功能。

Hadoop : ZooKeeper 為 Namenode 提供高可用支援。