分佈式一致性機制整理

時間 2020-02-06

原文原文鏈接

分佈式中一致性是很是重要的，分爲弱一致性和強一致性。如今主流的一致性協議通常都選擇的是弱一致性的特殊版本：最終一致性。下面就從分佈式系統的基本原則講起，再整理一些遵循這些原則的協議或者機制，爭取通俗易懂。可是要真正實施起來把這些協議落地，可不是一片文章能說清楚的，有太多的細節，要本身去看論文吶（順着維基百科找就好了）。java

基本原則與理論

CAP（Consistency一致性，Availability可用性，Partition tolerance分區容錯性）理論是當前分佈式系統公認的理論，亦即一個分佈式系統不可能同時知足這三個特性，只能三求其二。對於分佈式系統，P是基本要求，若是沒有P就不是分佈式系統了，因此通常都是在知足P的狀況下，在C和A之間尋求平衡。mysql

ACID（Atomicity原子性，Consistency一致性，Isolation隔離性，Durability持久性）是事務的特色，具備強一致性，通常用於單機事務，分佈式事務若採用這個原則會喪失必定的可用性，屬於CP系統。git

BASE（Basically Availabe基本可用，Soft state軟狀態，Eventually consistency最終一致性）理論是對大規模的互聯網分佈式系統實踐的總結，用弱一致性來換取可用性，不一樣於ACID，屬於AP系統。github

2PC

2 Phase Commit，兩階段提交，系統有兩個角色協調者和參與者，事務提交過程分爲兩階段：web

提交事務請求（投票階段）算法
- 協調者向參與者發送事務內容，詢問是否能夠執行事務提交操做，等待響應
- 參與者執行事務操做，並將undo和redo日誌記錄
- 參與者回覆協調者，執行成功則回Yes不然No
執行事務提交（執行階段）sql
- 若是都是參與者都回復Yes，則協調者向參與者發送提交請求，不然發送回滾請求
- 參與者根據協調者的請求執行事務提交或回滾，並向協調者發送Ack消息
- 協調者收到全部的Ack消息事後判斷事務的完成或者中斷

該協議能夠視爲強一致的算法，一般用來保證多份數據操做的原子性，也能夠實現數據副本之間的一致性，實現簡單，可是缺點也不少，好比單點故障（協調者掛了整個系統就無法對外服務，任一節點掛了事務就無法執行，沒有容錯機制）、阻塞（兩個階段都涉及同步等待阻塞，極大下降了吞吐量）、數據不一致（參與者回覆Yes/No後若是由於網絡緣由沒有收到提交/中斷請求，此時它就不知道該如何操做了，致使集羣數據不一致）......數據庫

2PC有些優化手段：超時判斷機制，好比協調者發出事務請求後等待全部參與者反饋，若超過期間沒有蒐集完畢全部回覆則能夠多播消息取消本次事務；互詢機制，參與者P回覆yes後，等待協調者發起最終的commitabort，若是沒收到那麼能夠詢問其餘參與者Q來決定自身下一步操做，避免一直阻塞（若是其餘參與者全都是等待狀態，那麼P也只能一直阻塞了）。因此2PC的阻塞問題是沒辦法完全解決的。安全

固然，若是網絡環境較好，該協議通常仍是能很好的工做的，2PC普遍應用於關係數據庫的分佈式事務處理，如mysql的內部與外部XA都是基於2PC的，通常想要把多個操做打包未原子操做也能夠用2PC。網絡

3PC

3 Phase Commit，三階段提交，是二階段提交的改進，系統也有兩個角色協調者和參與者，事務提交過程分爲三階段：

事務詢問（canCommit）
- 協調者向參與者發送一個包含事務內容的詢問請求，詢問是否能夠執行事務並等待
- 參與者根據本身狀態判斷並回復yes、no
執行事務預提交（preCommit）
- 若協調者收到全是yes，就發送preCommit請求不然發佈abort請求
- 參與者若收到preCommit則執行事務操做並記錄undo和redo而後發送Ack，若收到abort或者超時則中斷事務
執行事務提交（doCommit）
- 協調者收到全部的Ack則發送doCommit請求，若收到了No或者超時則發送abort請求
- 參與者收到doCommit就執行提交併發送ACk，不然執行回滾併發送Ack
- 協調者收到Ack判斷是完成事務仍是中斷事務

三階段相對於兩階段的改善就是把準備階段一分爲二，亦即多了一個canCommit階段，按我理解這樣就相似於TCP的三步握手，多了一次確認，增大了事務執行成功的機率。並且3PC的協調者即便出了故障，參與者也能繼續執行事務因此解決了2PC的阻塞問題，可是也可能所以致使集羣數據不一致。

Paxos

上面兩個協議的協調者都須要人爲設置而沒法自動生成，是不完整的分佈式協議，而Paxos 就是一個真正的完整的分佈式算法。系統一共有幾個角色：Proposer（提出提案）、Acceptor（參與決策）、Learner（不參與提案，只負責接收已肯定的提案，通常用於提升集羣對外提供讀服務的能力），實踐中一個節點能夠同時充當多個角色。提案選定過程也大概分爲2階段：

Prepare階段
- Proposer選擇一個提案編號M，向Acceptor某個超過半數的子集成員發送該編號的Prepare請求
- Acceptor收到M編號的請求時，若M大於該Acceptor已經響應的全部Prepare請求的編號中的最大編號N，那麼他就將N反饋給Proposer，同時承諾不會再批准任何編號小於M的提案
Accept階段
- 若是Proposer收到超過半數的Acceptor對於M的prepare請求的響應，就發送一個針對[M,V]提案的Accept請求給Acceptor，其中V是收到的響應編號中編號的最大的提案值，若是響應中不包括任何提案值，那麼他就是任意值
- Acceptor收到這個針對[M,V]的Accept請求只要改Acceptor還沒有對大於M編號的提案作出過響應，他就經過這個提案
Learn階段（本階段不屬於選定提案的過程）
- Proposer將經過的提案同步到全部的Learner

Paxos協議的容錯性很好，只要有超過半數的節點可用，整個集羣就能夠本身進行Leader選舉，也能夠對外服務，一般用來保證一份數據的多個副本之間的一致性，適用於構建一個分佈式的一致性狀態機。

Google的分佈式鎖服務Chubby就是用了Paxos協議，而開源的ZooKeeper使用的是Paxos的變種ZAB協議。

Raft

Raft協議對標Paxos，容錯性和性能都是一致的，可是Raft比Paxos更易理解和實施。系統分爲幾種角色： Leader（發出提案）、Follower（參與決策）、Candidate（Leader選舉中的臨時角色）。

剛開始全部節點都是Follower狀態，而後進行Leader選舉。成功後Leader接受全部客戶端的請求，而後把日誌entry發送給全部Follower，當收到過半的節點的回覆（而不是所有節點）時就給客戶端返回成功並把commitIndex設置爲該entry的index，因此是知足最終一致性的。

Leader同時還會週期性地發送心跳給全部的Follower（會經過心跳同步提交的序號commitIndex），Follower收到後就保持Follower狀態（並應用commitIndex及其以前對應的日誌entry），若是Follower等待心跳超時了，則開始新的Leader選舉：首先把當前term計數加1，本身成爲Candidate，而後給本身投票並向其它結點發投票請求。直到如下三種狀況：

它贏得選舉
另外一個節點成爲Leader
一段時間沒有節點成爲Leader

在選舉期間，Candidate可能收到來自其它自稱爲Leader的寫請求，若是該Leader的term不小於Candidate的當前term，那麼Candidate認可它是一個合法的Leader並回到Follower狀態，不然拒絕請求。
若是出現兩個Candidate得票同樣多，則它們都沒法獲取超過半數投票，這種狀況會持續到超時，而後進行新一輪的選舉，這時同時的機率就很低了，那麼首先發出投票請求的的Candidate就會獲得大多數贊成，成爲Leader。

在Raft協議出來以前，Paxos是分佈式領域的事實標準，可是Raft的出現打破了這一個現狀（raft做者也是這麼想的，請看論文），Raft協議把Leader選舉、日誌複製、安全性等功能分離並模塊化，使其更易理解和工程實現，未來發展怎樣咱們拭目以待（挺看好）。
Raft協議目前被用於 cockrouchDB，TiKV等項目中，據我聽的一些報告來看，一些大廠本身造的分佈式數據庫也在使用Raft協議。

Gossip

Gossip協議與上述全部協議最大的區別就是它是去中心化的，上面全部的協議都有一個相似於Leader的角色來統籌安排事務的響應、提交與中斷，可是Gossip協議中就沒有Leader，每一個節點都是平等的。

每一個節點存放了一個key,value,version構成的列表，每隔必定的時間，節點都會主動挑選一個在線節點進行上圖的過程（不在線的也會挑一個嘗試），兩個節點各自修改本身較爲落後的數據，最終數據達成一致而且都較新。節點加入或退出都很容易。

去中心化的Gossip看起來很美好：沒有單點故障，看似無上限的對外服務能力......原本隨着Cassandra火了一把，可是如今Cassandra也被拋棄了，去中心化的架構貌似難以真正應用起來。歸根到底我以爲仍是由於去中心化自己管理太複雜，節點之間溝通成本高，最終一致等待時間較長...... 往更高處看，一個企業（甚至整個社會）不也是須要中心化的領導（或者制度）來管理嗎，若是沒有領導（或者制度）管理，你們就是人心渙散，難成大事啊。
事實上現代互聯網架構只要把單點作得足夠強大，再加上若干個強一致的熱備，通常問題都不大。

NWR機制

首先看看這三個字母在分佈式系統中的含義：
N：有多少份數據副本
W：一次成功的寫操做至少有w份數據寫入成功
R：一次成功的讀操做至少有R份數據讀取成功
NWR值的不一樣組合會產生不一樣的一致性效果，當W+R>N的時候，讀取操做和寫入操做成功的數據必定會有交集，這樣就能夠保證必定可以讀取到最新版本的更新數據，數據的強一致性獲得了保證，若是R+W<=N，則沒法保證數據的強一致性，由於成功寫和成功讀集合可能不存在交集，這樣讀操做沒法讀取到最新的更新數值，也就沒法保證數據的強一致性。
版本的新舊須要版本控制算法來判別，好比向量時鐘。
固然R或者W不能太大，由於越大須要操做的副本越多，耗時越長。

Quorum機制

Quorom機制，是一種分佈式系統中經常使用的，用來保證數據冗餘和最終一致性的投票算法，主要思想來源於鴿巢原理。在有冗餘數據的分佈式存儲系統當中，冗餘數據對象會在不一樣的機器之間存放多份拷貝。可是同一時刻一個數據對象的多份拷貝只能用於讀或者用於寫。
分佈式系統中的每一份數據拷貝對象都被賦予一票。每個操做必需要得到最小的讀票數（Vr）或者最小的寫票數(Vw）才能讀或者寫。若是一個系統有V票（意味着一個數據對象有V份冗餘拷貝），那麼這最小讀寫票必須知足：

Vr + Vw > V
Vw > V/2

第一條規則保證了一個數據不會被同時讀寫。當一個寫操做請求過來的時候，它必需要得到Vw個冗餘拷貝的許可。而剩下的數量是V-Vw 不夠Vr，所以不能再有讀請求過來了。同理，當讀請求已經得到了Vr個冗餘拷貝的許可時，寫請求就沒法得到許可了。
第二條規則保證了數據的串行化修改。一份數據的冗餘拷貝不可能同時被兩個寫請求修改。

Quorum機制其實就是NWR機制。

Lease機制

master給各個slave分配不一樣的數據，每一個節點的數據都具備有效時間好比1小時，在lease時間內，客戶端能夠直接向slave請求數據，若是超過期間客戶端就去master請求數據。通常而言，slave能夠定時主動向master要求續租並更新數據，master在數據發生變化時也能夠主動通知slave，不一樣方式的選擇也在於可用性與一致性之間進行權衡。
租約機制也能夠解決主備之間網絡不通致使的雙主腦裂問題，亦即：主備之間原本心跳連線的，可是忽然之間網絡不通或者暫停又恢復了或者太繁忙沒法回覆，這時備機開始接管服務，可是主機依然存活能對外服務，這是就發生爭奪與分區，可是引入lease的話，老主機頒發給具體server的lease必然較舊，請求就失效了，老主機自動退出對外服務，備機徹底接管服務。