详解分布式一致性机制
點擊上方“朱小廝的博客”，選擇“設為星標”
后臺回復"書"，獲取
后臺回復“k8s”，可領取k8s資料
-? ? ?前言? ? -
分布式中一致性是非常重要的，分為弱一致性和強一致性。現在主流的一致性協議一般都選擇的是弱一致性的特殊版本：最終一致性。下面就從分布式系統的基本原則講起，再整理一些遵循這些原則的協議或者機制，爭取通俗易懂。但是要真正實施起來把這些協議落地，可不是一篇文章能說清楚的，有太多的細節，要自己去看論文吶（順著維基百科找就行了）。
-? ? ?基本原則與理論? ? -
CAP（Consistency一致性，Availability可用性，Partition tolerance分區容錯性）理論是當前分布式系統公認的理論，亦即一個分布式系統不可能同時滿足這三個特性，只能三求其二。對于分布式系統，P是基本要求，如果沒有P就不是分布式系統了，所以一般都是在滿足P的情況下，在C和A之間尋求平衡。
ACID（Atomicity原子性，Consistency一致性，Isolation隔離性，Durability持久性）是事務的特點，具有強一致性，一般用于單機事務，分布式事務若采用這個原則會喪失一定的可用性，屬于CP系統。
BASE（Basically Availabe基本可用，Soft state軟狀態，Eventually consistency最終一致性）理論是對大規模的互聯網分布式系統實踐的總結，用弱一致性來換取可用性，不同于ACID，屬于AP系統。
-? ? ?2PC? ? -
2 Phase Commit，兩階段提交，系統有兩個角色協調者和參與者，事務提交過程分為兩階段：
提交事務請求（投票階段）
協調者向參與者發送事務內容，詢問是否可以執行事務提交操作，等待響應
參與者執行事務操作，并將undo和redo日志記錄
參與者回復協調者，執行成功則回Yes否則No
執行事務提交（執行階段）
如果都是參與者都回復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必然較舊，請求就失效了，老主機自動退出對外服務，備機完全接管服務。參考：
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
想知道更多？掃描下面的二維碼關注我后臺回復"技術"，加入技術群后臺回復“k8s”，可領取k8s資料【精彩推薦】
https://en.wikipedia.org/wiki/Three-phase_commit_protocol
https://en.wikipedia.org/wiki/Paxos_(computer_science)
https://raft.github.io/
https://en.wikipedia.org/wiki/Raft_(computer_science)
https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
http://www.infoq.com/cn/articles/raft-paper
https://en.wikipedia.org/wiki/Gossip_protocol
從Paxos到ZooKeeper
分布式java應用
大數據日知錄
http://m635674608.iteye.com/blog/2343038ClickHouse到底是什么？為什么如此牛逼！
原來ElasticSearch還可以這么理解
面試官：InnoDB中一棵B+樹可以存放多少行數據？
架構之道：分離業務邏輯和技術細節
星巴克不使用兩階段提交
面試官：Redis新版本開始引入多線程，談談你的看法？
喜馬拉雅自研網關架構演進過程
收藏：存儲知識全面總結
微博千萬級規模高性能高并發的網絡架構設計
總結
以上是生活随笔為你收集整理的详解分布式一致性机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kafka淘汰倒计时！这个新一代消息中间
- 下一篇： 简历上的“熟练掌握 RPC”，到底是个什