兄弟們?cè)谧龇植际较到y(tǒng)的時(shí)候一定遇到過(guò)這種場(chǎng)景單機(jī)數(shù)據(jù)庫(kù)里的本地事務(wù)跑得挺順結(jié)果一拆成微服務(wù)、一上分布式數(shù)據(jù)庫(kù)數(shù)據(jù)就各種對(duì)不上。訂單狀態(tài)改了庫(kù)存卻扣重了用戶支付成功了積分系統(tǒng)卻查不到記錄。這些問(wèn)題歸根結(jié)底就倆字一致性。而一致性背后是分布式事務(wù)模型和一致性算法在撐著。今天這篇不是教科書復(fù)讀我盡量用干活的視角把CAP、分布式事務(wù)模型、還有Raft這套東西捋清楚講明白它們到底怎么落到工程里踩過(guò)哪些坑選型的時(shí)候該怎么權(quán)衡。這篇內(nèi)容適合真正在做微服務(wù)拆分、分布式數(shù)據(jù)庫(kù)選型、或者自己動(dòng)手寫共識(shí)模塊的工程師。不需要你數(shù)學(xué)多好但最好對(duì)分布式系統(tǒng)的基本概念有點(diǎn)體感。我會(huì)把整個(gè)鏈路拆成四塊來(lái)講先回到問(wèn)題源頭看一致性的本質(zhì)再展開CAP這個(gè)不可能三角然后擼一遍分布式事務(wù)的主流模型和選型依據(jù)最后把從Paxos到Raft的演進(jìn)邏輯以及Raft的核心機(jī)制逐層扒開。全程有類比、有場(chǎng)景、有參數(shù)、有對(duì)比盡量讓你看完能直接拿來(lái)用。1. 分布式系統(tǒng)的一致性問(wèn)題根源1.1 從單機(jī)事務(wù)到分布式事務(wù)問(wèn)題是怎么產(chǎn)生的單機(jī)數(shù)據(jù)庫(kù)里ACID事務(wù)是數(shù)據(jù)庫(kù)自己通過(guò)鎖、日志、回滾段來(lái)保證的。你執(zhí)行一條UPDATE要么成功要么失敗中間狀態(tài)外部不可見(jiàn)異常了還能回滾。這套機(jī)制在單機(jī)上是天經(jīng)地義的因?yàn)樗袛?shù)據(jù)和操作都在同一個(gè)進(jìn)程、同一塊磁盤上數(shù)據(jù)庫(kù)自己就能把控全局。但分布式系統(tǒng)不一樣。你的服務(wù)拆成了多個(gè)節(jié)點(diǎn)數(shù)據(jù)分散到多臺(tái)機(jī)器甚至分布在多個(gè)數(shù)據(jù)中心。這時(shí)候要完成一個(gè)跨節(jié)點(diǎn)的業(yè)務(wù)操作比如創(chuàng)建訂單扣庫(kù)存加積分這個(gè)操作涉及三個(gè)不同的服務(wù)每個(gè)服務(wù)又各自連著自己的數(shù)據(jù)庫(kù)。如果按照單機(jī)思路每個(gè)服務(wù)干自己的事、提交自己的事務(wù)問(wèn)題馬上就來(lái)了訂單建好了庫(kù)存扣減失敗了或者積分服務(wù)超時(shí)了這時(shí)怎么辦最直接的辦法就是讓這三個(gè)操作保持同生共死要么全成功要么全回滾。這就是分布式事務(wù)要解決的問(wèn)題。跟單機(jī)事務(wù)最大的不同在于單機(jī)事務(wù)有統(tǒng)一的協(xié)調(diào)者數(shù)據(jù)庫(kù)自身有全局可見(jiàn)的鎖狀態(tài)有可靠的本地日志而分布式系統(tǒng)里協(xié)調(diào)者需要自己設(shè)計(jì)節(jié)點(diǎn)間的通信是不可靠的網(wǎng)絡(luò)可能延遲、亂序、斷連節(jié)點(diǎn)可能宕機(jī)根本不存在一個(gè)上帝視角能一眼看清全局狀態(tài)。所以分布式事務(wù)的核心難點(diǎn)不是怎么做操作而是怎么讓多個(gè)節(jié)點(diǎn)達(dá)成共識(shí)并且容忍各種故障。1.2 分布式環(huán)境下的新挑戰(zhàn)網(wǎng)絡(luò)分區(qū)與節(jié)點(diǎn)故障分布式系統(tǒng)里兩個(gè)最棘手的問(wèn)題一個(gè)是節(jié)點(diǎn)故障宕機(jī)、進(jìn)程崩潰一個(gè)是網(wǎng)絡(luò)分區(qū)網(wǎng)絡(luò)不通、消息丟失、消息延遲。這兩種故障還不是互斥的經(jīng)常疊加出現(xiàn)。網(wǎng)絡(luò)分區(qū)特別惡心人的一點(diǎn)在于它讓判斷一個(gè)節(jié)點(diǎn)是否真的死了變得非常困難。假設(shè)你的訂單服務(wù)向庫(kù)存服務(wù)發(fā)送一條扣減請(qǐng)求超時(shí)了。這個(gè)超時(shí)代表什么可能是庫(kù)存服務(wù)真的掛了可能是網(wǎng)絡(luò)斷了幾秒鐘可能是消息在隊(duì)列里堵了也可能是庫(kù)存服務(wù)處理完但響應(yīng)丟了。你根本沒(méi)法區(qū)分。在這個(gè)不確定面前任何全局一致的企圖都會(huì)受挫。所以在分布式事務(wù)和一致性算法的設(shè)計(jì)里你到處都能看到對(duì)故障的明確假設(shè)。CAP定理把所有可能的系統(tǒng)分成了三類就是對(duì)這種不確定性最經(jīng)典的抽象表達(dá)。理解了這個(gè)前提后面再看兩階段提交的協(xié)調(diào)者超時(shí)處理、看Raft的領(lǐng)導(dǎo)者選舉、看各種一致性模型的取舍你就知道每一項(xiàng)設(shè)計(jì)都是在跟不可靠網(wǎng)絡(luò)做斗爭(zhēng)。2. CAP定理深度拆解分布式系統(tǒng)的不可能三角2.1 CAP三個(gè)字母到底在說(shuō)什么CAP是Consistency一致性、Availability可用性、Partition Tolerance分區(qū)容錯(cuò)性的縮寫。這套理論最早是Eric Brewer在2000年提出的后來(lái)由Gilbert和Lynch給出了形式化證明簡(jiǎn)單說(shuō)就是在網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)一個(gè)分布式系統(tǒng)無(wú)法同時(shí)保證強(qiáng)一致性和高可用性只能在兩者之間做取舍。先把三個(gè)概念摳清楚不然很多討論都是在雞同鴨講。一致性Consistency在這里指的是線性一致性Linearizability也就是強(qiáng)一致性?？蛻舳俗x取數(shù)據(jù)時(shí)如果某個(gè)寫操作已經(jīng)成功返回那么后續(xù)任何讀操作都必須讀到這個(gè)新值并且所有節(jié)點(diǎn)對(duì)數(shù)據(jù)的讀取順序在全球范圍內(nèi)完全一致。你可以把它理解為整個(gè)系統(tǒng)就像只有一份數(shù)據(jù)、一個(gè)操作順序所有并發(fā)操作被串行化了?？捎眯訟vailability指的是每次請(qǐng)求都能在有限時(shí)間內(nèi)得到回應(yīng)。這里不要求回應(yīng)的內(nèi)容一定是最新的但必須是一個(gè)合法的結(jié)果成功或失敗都行不能無(wú)限掛起。換句話說(shuō)系統(tǒng)不能因?yàn)槟硞€(gè)節(jié)點(diǎn)故障或網(wǎng)絡(luò)問(wèn)題就拒絕服務(wù)。分區(qū)容錯(cuò)性Partition Tolerance指的是系統(tǒng)在網(wǎng)絡(luò)分區(qū)節(jié)點(diǎn)間消息丟失或延遲無(wú)限大的情況下仍能繼續(xù)運(yùn)行。注意P不是一種選擇而是分布式系統(tǒng)的必然屬性——只要你的系統(tǒng)部署在網(wǎng)絡(luò)上分區(qū)就是不可避免的。所謂三選二其實(shí)是個(gè)偽命題正確的理解是在分區(qū)發(fā)生時(shí)C和A只能保留一個(gè)。2.2 為什么最多只能滿足兩個(gè)用一個(gè)特別經(jīng)典的例子來(lái)解釋。假設(shè)有兩個(gè)副本節(jié)點(diǎn)N1和N2初始值都是X0?，F(xiàn)在客戶端向N1發(fā)起一個(gè)寫請(qǐng)求把X改成1并且N1成功執(zhí)行了這個(gè)寫操作。但緊接著N1和N2之間的網(wǎng)絡(luò)斷開了分區(qū)發(fā)生。這時(shí)客戶端向N2發(fā)起讀請(qǐng)求問(wèn)題來(lái)了如果N2返回X0那就沒(méi)有滿足一致性因?yàn)榭蛻舳藙倢懭氲闹凳?但讀到的卻是舊值。如果為了滿足一致性N2必須停下來(lái)等待與N1同步等待期間無(wú)法響應(yīng)——那就沒(méi)有滿足可用性。你看在分區(qū)這個(gè)前提下C和A出現(xiàn)了不可調(diào)和的沖突。那如果不發(fā)生分區(qū)呢當(dāng)然可以同時(shí)滿足C和A但那只是單機(jī)或無(wú)故障的特例沒(méi)有討論意義。在真實(shí)生產(chǎn)環(huán)境中分區(qū)是常態(tài)所以每個(gè)分布式系統(tǒng)實(shí)際都在做選擇題要CP還是AP。2.3 CP與AP的工程取舍實(shí)際系統(tǒng)怎么選選CP還是AP沒(méi)有絕對(duì)的對(duì)錯(cuò)完全看業(yè)務(wù)場(chǎng)景。CP系統(tǒng)在分區(qū)發(fā)生時(shí)選擇暫停服務(wù)拒絕寫入、拒絕讀取或部分拒絕以換取數(shù)據(jù)絕對(duì)的強(qiáng)一致。典型代表是ZooKeeper、etcd、HBase、Google Spanner。適用場(chǎng)景是那些數(shù)據(jù)錯(cuò)了比暫時(shí)不可用更可怕的業(yè)務(wù)比如金融交易、分布式鎖、配置中心、元數(shù)據(jù)存儲(chǔ)。舉個(gè)例子分布式鎖如果出現(xiàn)兩個(gè)節(jié)點(diǎn)同時(shí)拿到鎖那可能引發(fā)嚴(yán)重的資源競(jìng)爭(zhēng)或數(shù)據(jù)損壞所以鎖服務(wù)寧可短暫不可用也不能給客戶端分發(fā)出錯(cuò)的結(jié)果。AP系統(tǒng)在分區(qū)發(fā)生時(shí)選擇繼續(xù)服務(wù)允許各分區(qū)臨時(shí)出現(xiàn)數(shù)據(jù)不一致但通過(guò)異步補(bǔ)償機(jī)制在分區(qū)恢復(fù)后逐步收斂到一致狀態(tài)。典型代表是Cassandra、DynamoDB、CouchDB以及大量微服務(wù)架構(gòu)中的業(yè)務(wù)系統(tǒng)。適用場(chǎng)景是那些短暫讀到舊數(shù)據(jù)可以接受但必須一直能用的業(yè)務(wù)比如商品列表、用戶會(huì)話、社交動(dòng)態(tài)、購(gòu)物車。電商大促時(shí)你看到商品庫(kù)存多顯示了幾件這個(gè)可以忍但如果你因?yàn)閹?kù)存服務(wù)不可用導(dǎo)致連商品詳情都刷不出來(lái)那損失就大了去了。我在實(shí)際項(xiàng)目里的感受是大部分業(yè)務(wù)系統(tǒng)的核心矛盾不是強(qiáng)一致而是高可用。真正需要強(qiáng)一致的地方往往是元數(shù)據(jù)層、配置層和資金流轉(zhuǎn)的核心環(huán)節(jié)其他業(yè)務(wù)全部走最終一致就夠用了。這也是為什么微服務(wù)架構(gòu)落地時(shí)分布式事務(wù)越往業(yè)務(wù)側(cè)越軟用最終一致性的方案越來(lái)越多。3. 分布式事務(wù)模型的分類與選型前面講了理論這一節(jié)來(lái)點(diǎn)實(shí)際能用的東西。分布式事務(wù)模型目前主流的有這么幾類2PC兩階段提交、3PC三階段提交、TCCTry-Confirm-Cancel、Saga長(zhǎng)事務(wù)、本地消息表事務(wù)消息。它們對(duì)一致性的保障強(qiáng)度不同實(shí)現(xiàn)復(fù)雜度也天差地別。3.1 強(qiáng)一致路線2PC兩階段提交2PC是最經(jīng)典的分布式事務(wù)協(xié)議也最能體現(xiàn)強(qiáng)一致的思路。它引入一個(gè)協(xié)調(diào)者Coordinator節(jié)點(diǎn)把整個(gè)事務(wù)分成兩個(gè)階段階段一準(zhǔn)備階段協(xié)調(diào)者向所有參與者比如訂單庫(kù)、庫(kù)存庫(kù)、積分庫(kù)發(fā)送準(zhǔn)備提交的請(qǐng)求各參與者執(zhí)行本地事務(wù)到可提交狀態(tài)但不提交把事務(wù)寫入本地日志然后向協(xié)調(diào)者回復(fù)就緒或失敗。階段二提交階段協(xié)調(diào)者收集所有參與者的回復(fù)。如果全部就緒就廣播提交命令各參與者正式提交本地事務(wù)如果任一參與者回復(fù)失敗或超時(shí)未響應(yīng)協(xié)調(diào)者就廣播回滾命令各參與者撤銷本地操作。這個(gè)方案聽起來(lái)邏輯清晰但工程實(shí)現(xiàn)里全是坑。最大的問(wèn)題是同步阻塞所有參與者在準(zhǔn)備好之后持有資源鎖直到第二階段結(jié)束才能釋放。如果協(xié)調(diào)者宕機(jī)所有參與者都要一直阻塞著整個(gè)系統(tǒng)就卡住了。另外協(xié)調(diào)者是單點(diǎn)它掛了整個(gè)事務(wù)就沒(méi)法推進(jìn)極端情況下甚至?xí)霈F(xiàn)各參與者狀態(tài)不一致協(xié)調(diào)者廣播提交時(shí)崩潰一部分節(jié)點(diǎn)收到消息提交了另一部分沒(méi)收到就回滾了。所以純2PC在分布式數(shù)據(jù)庫(kù)內(nèi)部用得比較多比如TiDB的PD調(diào)度、MySQL XA因?yàn)閿?shù)據(jù)庫(kù)可以在內(nèi)部通過(guò)超時(shí)、重試和節(jié)點(diǎn)恢復(fù)機(jī)制來(lái)兜底。但在微服務(wù)架構(gòu)中跨服務(wù)調(diào)用鏈上直接裸用2PC非常痛苦——網(wǎng)絡(luò)超時(shí)、服務(wù)重試、事務(wù)狀態(tài)丟失都是麻煩這也是后來(lái)TCC和Saga被大量應(yīng)用的原因。3.2 最終一致路線TCC、Saga、本地消息表TCC的思想是把一個(gè)業(yè)務(wù)操作拆成三個(gè)動(dòng)作Try資源檢查和鎖定、Confirm確認(rèn)執(zhí)行、Cancel取消回滾。它比2PC更貼合業(yè)務(wù)因?yàn)門ry階段做的不是數(shù)據(jù)的物理變更而是預(yù)留資源。比如扣庫(kù)存Try階段只是凍結(jié)庫(kù)存數(shù)量Confirm階段才真正扣減Cancel階段解凍。TCC解決了2PC的同步阻塞問(wèn)題——Try階段完成就可以釋放資源鎖Confirm和Cancel都是異步補(bǔ)償。但TCC對(duì)業(yè)務(wù)代碼侵入非常強(qiáng)每個(gè)操作都得寫三套邏輯而且Confirm和Cancel要做到冪等否則重復(fù)調(diào)用會(huì)產(chǎn)生臟數(shù)據(jù)。這里我說(shuō)一個(gè)TCC落地最常見(jiàn)的坑Confirm和Cancel的觸發(fā)順序在某些異常場(chǎng)景下不可控。比如協(xié)調(diào)者在發(fā)送Confirm前宕機(jī)恢復(fù)后重發(fā)但業(yè)務(wù)方因?yàn)橹耙呀?jīng)執(zhí)行過(guò)Confirm且網(wǎng)絡(luò)丟了響應(yīng)重復(fù)執(zhí)行就不能報(bào)錯(cuò)必須能識(shí)別這已提交過(guò)。Saga則是把一個(gè)長(zhǎng)事務(wù)拆成一系列本地事務(wù)每個(gè)本地事務(wù)完成后都發(fā)布一個(gè)事件由后續(xù)的本地事務(wù)響應(yīng)事件繼續(xù)推進(jìn)。如果某個(gè)步驟失敗Saga會(huì)反向執(zhí)行補(bǔ)償事務(wù)把之前的操作逐步回滾。Saga的典型實(shí)現(xiàn)方式是Choreography編排式和Orchestration編排中心式。前者靠事件驅(qū)動(dòng)各服務(wù)自己訂閱發(fā)布適合流程簡(jiǎn)單的情況后者有一個(gè)中心化的Saga執(zhí)行器來(lái)串聯(lián)整個(gè)事務(wù)流程復(fù)雜性可控適合業(yè)務(wù)邏輯較長(zhǎng)的場(chǎng)景。本地消息表事務(wù)消息的思路也很實(shí)用把某個(gè)核心操作和發(fā)消息放在同一個(gè)本地事務(wù)里。比如訂單服務(wù)在創(chuàng)建訂單的同時(shí)往本地消息表插入一條扣減庫(kù)存的事情記錄提交事務(wù)后再異步發(fā)送消息到MQ。消息隊(duì)列確保至少投遞成功下游消費(fèi)成功后再回調(diào)確認(rèn)。如果本地事務(wù)提交了但消息發(fā)送失敗后臺(tái)任務(wù)會(huì)定時(shí)掃描消息表把未確認(rèn)的消息重新投遞。這個(gè)方案最大的優(yōu)勢(shì)是簡(jiǎn)單、不侵入業(yè)務(wù)落地成本低而且各服務(wù)解耦。3.3 事務(wù)模型選型對(duì)比為了讓你選型時(shí)有概念我直接整理了一張對(duì)比表方案一致性強(qiáng)度性能開銷實(shí)現(xiàn)復(fù)雜度業(yè)務(wù)侵入適用場(chǎng)景2PC強(qiáng)一致高鎖持續(xù)時(shí)間長(zhǎng)中低數(shù)據(jù)庫(kù)內(nèi)部事務(wù)、小規(guī)?？鐜?kù)操作TCC最終一致Confirm階段業(yè)務(wù)保證中高高資金、庫(kù)存等核心資源操作需精細(xì)控制資源狀態(tài)Saga最終一致中低中中長(zhǎng)流程業(yè)務(wù)如訂單創(chuàng)建支付出庫(kù)允許中間狀態(tài)本地消息表/事務(wù)消息最終一致低低低消息驅(qū)動(dòng)的異步流程跨服務(wù)解耦注意事務(wù)模型的選擇不能脫離業(yè)務(wù)單獨(dú)談。我在實(shí)際項(xiàng)目里一般先畫一張事務(wù)邊界圖把每個(gè)核心操作的數(shù)據(jù)寫入路徑梳理出來(lái)判斷每個(gè)路徑對(duì)一致性的真實(shí)容忍度再?zèng)Q定哪一段用TCC、哪一段走Saga、哪一段只靠MQ解耦。不存在銀彈只有適不適合當(dāng)前場(chǎng)景。4. 一致性算法的演進(jìn)從Paxos到Raft搞清楚了分布式事務(wù)再看一致性算法就順了。因?yàn)榉植际绞聞?wù)的強(qiáng)一致方案比如2PC本質(zhì)上需要一個(gè)讓多個(gè)節(jié)點(diǎn)對(duì)某個(gè)決策達(dá)成一致的機(jī)制而真正健壯、能容錯(cuò)的共識(shí)算法一直到Paxos才算是有了突破。4.1 Paxos為什么難懂又難實(shí)現(xiàn)Paxos是Leslie Lamport在1990年提出、1998年正式發(fā)表的共識(shí)算法也是歷史上第一個(gè)被廣泛認(rèn)可的容錯(cuò)共識(shí)算法。它解決的問(wèn)題是在異步通信、節(jié)點(diǎn)可能宕機(jī)的環(huán)境下如何讓多個(gè)節(jié)點(diǎn)對(duì)同一個(gè)值比如某條日志記錄的序號(hào)、某個(gè)配置項(xiàng)的值達(dá)成一致。Paxos的核心設(shè)計(jì)是引入提議者Proposer、接受者Acceptor和學(xué)習(xí)者Learner三種角色通過(guò)兩輪RPCPrepare和Accept來(lái)保證一旦某個(gè)值被選定后續(xù)所有提議都只能提議同樣的值。安全性Safety由法定人數(shù)Quorum機(jī)制保證——任何兩個(gè)法定人數(shù)的交集不為空所以不會(huì)被同時(shí)選出兩個(gè)不同的值。但Paxos的臭名昭著在于它極其抽象工程實(shí)現(xiàn)的門檻極高。Lamport原始的論文用議會(huì)提案做類比理解起來(lái)簡(jiǎn)直是一種折磨。而且Paxos本身只解決單值共識(shí)真實(shí)系統(tǒng)要復(fù)制日志、選主、做成員變更還得在Paxos之上疊加大量工程細(xì)節(jié)。多PaxosMulti-Paxos雖然實(shí)際應(yīng)用很廣Google的Chubby、Spanner內(nèi)部都用了類Paxos協(xié)議但因?yàn)闆](méi)有一篇公認(rèn)的、可以直接照著寫的權(quán)威實(shí)現(xiàn)文檔各家實(shí)現(xiàn)五花八門團(tuán)隊(duì)之間交流起來(lái)特別費(fèi)勁。4.2 Raft的重新設(shè)計(jì)可理解性優(yōu)先Raft的作者Diego Ongaro和John Ousterhout在2014年發(fā)表論文《In Search of an Understandable Consensus Algorithm》開頭就直說(shuō)了Paxos正確但不夠可理解所以我們?cè)O(shè)計(jì)了一個(gè)更容易理解、更適合教學(xué)和工程實(shí)現(xiàn)的共識(shí)算法。目標(biāo)就是可理解性優(yōu)先把共識(shí)問(wèn)題拆成相對(duì)獨(dú)立的子問(wèn)題逐一解決。Raft跟Paxos最大的區(qū)別是先選主再?gòu)?fù)制。Raft把節(jié)點(diǎn)分成Leader、Follower、Candidate三種狀態(tài)正常情況下只有一個(gè)Leader所有寫請(qǐng)求都經(jīng)過(guò)Leader由Leader把日志條目復(fù)制給Follower提交后返回成功。這樣整個(gè)共識(shí)過(guò)程從多個(gè)提議者互相競(jìng)爭(zhēng)變成了單一Leader負(fù)責(zé)推進(jìn)邏輯線特別清晰。下面我詳細(xì)拆Raft的幾個(gè)核心機(jī)制這部分建議你找個(gè)本子記一下面試和實(shí)戰(zhàn)都經(jīng)?？?。5. Raft算法核心機(jī)制逐層拆解5.1 領(lǐng)導(dǎo)者選舉Raft的班長(zhǎng)機(jī)制Raft把時(shí)間劃分成一個(gè)個(gè)任期Term每個(gè)任期最多對(duì)應(yīng)一個(gè)Leader。所有節(jié)點(diǎn)啟動(dòng)時(shí)都是Follower如果在一段時(shí)間內(nèi)沒(méi)收到Leader的心跳Heartbeat它就會(huì)變成Candidate給自己currentTerm加1然后發(fā)起選舉。選舉過(guò)程這樣的Candidate先投自己一票然后向其他節(jié)點(diǎn)廣播RequestVote RPC。每個(gè)節(jié)點(diǎn)在一個(gè)任期里只能投一票收到投票請(qǐng)求時(shí)如果對(duì)方的日志至少不比自己舊后面會(huì)細(xì)說(shuō)并且自己還沒(méi)有投過(guò)票就投給對(duì)方。候選人拿到大多數(shù)節(jié)點(diǎn)N/21的票數(shù)就當(dāng)選Leader成為L(zhǎng)eader后立即開始周期性發(fā)送心跳Heartbeat告訴其他節(jié)點(diǎn)我活著繼續(xù)保持Follower身份。選舉的關(guān)鍵參數(shù)是隨機(jī)超時(shí)時(shí)間。每個(gè)節(jié)點(diǎn)的選舉超時(shí)是在固定區(qū)間論文推薦150ms到300ms內(nèi)隨機(jī)選擇的。為什么要隨機(jī)如果所有節(jié)點(diǎn)同時(shí)超時(shí)就會(huì)同時(shí)發(fā)起選舉票數(shù)分散誰(shuí)都當(dāng)不上Leader然后反復(fù)選舉系統(tǒng)一直震蕩。隨機(jī)化之后總有一個(gè)節(jié)點(diǎn)先超時(shí)它發(fā)起選舉時(shí)其他節(jié)點(diǎn)還在等待票基本都會(huì)投給它這樣就能快速穩(wěn)定地選出Leader。這里有個(gè)工程細(xì)節(jié)實(shí)際的超時(shí)時(shí)間不能離心跳間隔太近否則網(wǎng)絡(luò)抖動(dòng)就會(huì)引發(fā)頻繁選舉。我推薦心跳間隔在100ms到500ms之間選舉超時(shí)設(shè)為心跳間隔的3到5倍。比如心跳200ms選舉超時(shí)600ms到1000ms之間隨機(jī)。調(diào)得太小一有網(wǎng)絡(luò)毛刺就觸發(fā)選舉調(diào)得太大Leader掛了之后的恢復(fù)時(shí)間又變長(zhǎng)。5.2 日志復(fù)制讓所有節(jié)點(diǎn)保持同步選出了Leader接下來(lái)就是日志復(fù)制?？蛻舳说乃袑懻?qǐng)求都發(fā)送給LeaderLeader先把請(qǐng)求封裝成一條日志條目Log Entry里面包含任期號(hào)、索引、命令等字段然后并行發(fā)給所有Follower。Follower收到AppendEntries RPC日志復(fù)制請(qǐng)求做一系列一致性檢查它會(huì)確認(rèn)前一條日志的任期和索引是否跟自己的日志匹配只有匹配才接受新日志條目。為什么這么嚴(yán)格因?yàn)槿罩颈仨毐３謬?yán)格有序任何跳號(hào)或沖突都可能導(dǎo)致狀態(tài)機(jī)應(yīng)用出問(wèn)題。這里有個(gè)重點(diǎn)日志提交Commit才意味著生效。Leader只有確認(rèn)某條日志已經(jīng)被復(fù)制到了大多數(shù)節(jié)點(diǎn)Quorum才能更新commitIndex并把這條日志應(yīng)用到狀態(tài)機(jī)Apply然后才向客戶端返回成功。也就是說(shuō)只要一個(gè)寫操作被大多數(shù)節(jié)點(diǎn)接收了即使其他節(jié)點(diǎn)暫時(shí)落后這條日志也已經(jīng)穩(wěn)了——因?yàn)楹罄m(xù)任何新的Leader選舉出來(lái)它的日志一定包含這條記錄。我在實(shí)際調(diào)試Raft實(shí)現(xiàn)時(shí)最常遇到的問(wèn)題就是日志覆蓋Overwrite。Raft允許Leader通過(guò)檢查日志的任期和索引讓Follower刪除并覆蓋掉那些沖突的日志條目。很多人剛學(xué)的時(shí)候不理解刪日志不是破壞一致性嗎其實(shí)不會(huì)。因?yàn)闆_突的日志本來(lái)就沒(méi)被提交過(guò)未提交的日志是不穩(wěn)定的刪掉它們不會(huì)影響已提交的狀態(tài)。這個(gè)機(jī)制保證了最終所有節(jié)點(diǎn)日志收斂到和Leader一致。5.3 安全性保證為什么不會(huì)選錯(cuò)日志復(fù)制看起來(lái)簡(jiǎn)單但有個(gè)致命問(wèn)題怎么保證新選出的Leader一定擁有所有已提交的日志如果沒(méi)有這個(gè)保證新Leader可能會(huì)覆蓋掉已經(jīng)提交的數(shù)據(jù)導(dǎo)致系統(tǒng)丟失數(shù)據(jù)。Raft用兩個(gè)規(guī)則解決了這個(gè)問(wèn)題。第一是選舉限制Candidate在發(fā)起選舉時(shí)必須帶上自己日志的最新任期和索引。收到投票請(qǐng)求的節(jié)點(diǎn)會(huì)比較自己和對(duì)方的日志新鮮度如果對(duì)方的最后一條日志任期比自己的新或者任期相同但索引更大說(shuō)明對(duì)方日志更完整就把票投給它。這樣日志更完整的節(jié)點(diǎn)更容易勝出確保新Leader至少不落后于大多數(shù)節(jié)點(diǎn)。第二是提交限制Leader只能直接提交當(dāng)前任期的日志對(duì)于之前任期的日志必須等當(dāng)前任期有一條日志提交了才能間接提交之前的日志。這個(gè)規(guī)則比較繞但非常關(guān)鍵。假設(shè)Leader在Term 2復(fù)制了一條日志到大多數(shù)節(jié)點(diǎn)但隨后宕機(jī)了Term 3的新Leader可能并不包含這條日志因?yàn)樗侵叭纹谖刺峤坏?。如果Term 3的Leader擅自把Term 2的日志標(biāo)記為提交就相當(dāng)于提交了一個(gè)自己都沒(méi)有的日志這絕對(duì)不行。所以Raft規(guī)定舊日志只能通過(guò)當(dāng)前任期的日志間接確認(rèn)提交。這兩個(gè)規(guī)則配在一起Raft就具備了完整的安全性Safety任何已提交的日志條目一定存在于之后任意任期的Leader的日志中。這就保證了數(shù)據(jù)不會(huì)丟也不會(huì)被覆蓋。5.4 成員變更生產(chǎn)環(huán)境繞不開的難題Raft的另一個(gè)關(guān)鍵機(jī)制是成員變更Membership Change。這在生產(chǎn)環(huán)境里是真的繞不開——你要擴(kuò)縮容、替換故障節(jié)點(diǎn)都涉及成員變更。Raft論文里給出的是**聯(lián)合共識(shí)Joint Consensus**方案把成員變更拆成兩個(gè)階段。第一階段新老配置同時(shí)生效任何決策都需要老配置的Quorum和新配置的Quorum都同意第二階段確認(rèn)穩(wěn)定后完全切換到新配置。這個(gè)方案理論上很完美但實(shí)現(xiàn)起來(lái)還是有點(diǎn)復(fù)雜。工程上更常用的簡(jiǎn)化版本是單節(jié)點(diǎn)變更Single-Server Membership Change每次只添加或刪除一個(gè)節(jié)點(diǎn)不搞聯(lián)合共識(shí)。論文后續(xù)附錄證明了在每次只變更一個(gè)節(jié)點(diǎn)的情況下系統(tǒng)的安全性依然能得到保證。etcd、Hashicorp Raft庫(kù)基本都是走這個(gè)路線。我在實(shí)踐里建議優(yōu)先選單節(jié)點(diǎn)變更實(shí)現(xiàn)復(fù)雜度低出問(wèn)題的概率小得多。6. 工程實(shí)踐分布式事務(wù)與一致性算法在真實(shí)系統(tǒng)中的配合聊了這么多理論最后落到工程上。很多人有個(gè)誤解學(xué)了Raft是不是就該自己寫一個(gè)共識(shí)模塊我的建議是除非你想造輪子否則生產(chǎn)環(huán)境千萬(wàn)別自己實(shí)現(xiàn)Raft。Raft的難度不在算法本身而在邊角場(chǎng)景——磁盤故障、網(wǎng)絡(luò)抖動(dòng)、時(shí)鐘漂移、快照、配置變更任何一個(gè)都能讓一個(gè)看似正確的實(shí)現(xiàn)翻車。實(shí)際工程中Raft早就被封裝成了可靠的基礎(chǔ)組件。etcd的raft庫(kù)Go、Hashicorp的Raft庫(kù)Go、百度的braftC、螞蟻的sofa-jraftJava都是成熟選擇。你在業(yè)務(wù)代碼里要做的不是重寫Raft而是基于這些庫(kù)把共識(shí)組的能力用起來(lái)。比如用etcd做分布式鎖、用ZooKeeper做元數(shù)據(jù)管理、用TiKV或CockroachDB做分布式數(shù)據(jù)庫(kù)這些系統(tǒng)內(nèi)部都用了Raft或類Paxos算法你不需要操心內(nèi)部實(shí)現(xiàn)但要理解它們的行為模型什么操作是線性的、什么操作是最終一致的、分區(qū)時(shí)會(huì)發(fā)生什么。另外分布式事務(wù)模型在微服務(wù)架構(gòu)里很少單獨(dú)使用一般會(huì)配合本地消息表重試對(duì)賬的組合拳。比如我做過(guò)的一個(gè)供應(yīng)鏈項(xiàng)目訂單創(chuàng)建走本地消息表發(fā)事件庫(kù)存扣減走Saga編排資金扣減走TCC。外圍架設(shè)一套定時(shí)對(duì)賬任務(wù)每隔一段時(shí)間掃描兩邊數(shù)據(jù)發(fā)現(xiàn)不一致就告警并自動(dòng)補(bǔ)償。這套組合下來(lái)絕大多數(shù)數(shù)據(jù)不一致問(wèn)題都能在秒級(jí)到分鐘級(jí)內(nèi)收斂關(guān)鍵時(shí)刻用對(duì)賬兜底比純追求強(qiáng)一致要穩(wěn)妥得多。7. 常見(jiàn)問(wèn)題與排查經(jīng)驗(yàn)7.1 Raft集群頻繁選舉Leader怎么辦這是Raft集群最常見(jiàn)的問(wèn)題。先看心跳間隔和選舉超時(shí)配置是否合理——心跳太慢或超時(shí)太短都會(huì)導(dǎo)致誤判。其次是網(wǎng)絡(luò)延遲和抖動(dòng)如果節(jié)點(diǎn)間延遲超過(guò)心跳間隔Follower就會(huì)認(rèn)為L(zhǎng)eader掛了。排查手段包括查CPU和磁盤IORaft需要持久化日志磁盤慢會(huì)導(dǎo)致心跳RPC處理延遲、抓包看心跳間隔的P99延遲、檢查是否存在GC停頓JVM進(jìn)程Full GC會(huì)卡住心跳響應(yīng)。7.2 2PC協(xié)調(diào)者宕機(jī)事務(wù)卡死怎么辦生產(chǎn)環(huán)境里2PC協(xié)調(diào)者宕機(jī)是最惡心的場(chǎng)景之一因?yàn)樗袇⑴c者都在等協(xié)調(diào)者發(fā)最終決定。解決思路一般是超時(shí)回查。協(xié)調(diào)者把每個(gè)事務(wù)的狀態(tài)持久化到本地存儲(chǔ)恢復(fù)后根據(jù)事務(wù)日志重新決策參與者在等待協(xié)調(diào)者響應(yīng)超時(shí)后主動(dòng)向協(xié)調(diào)者發(fā)起狀態(tài)查詢。在MySQL XA等實(shí)現(xiàn)里這個(gè)機(jī)制是內(nèi)置的。如果你的自研方案沒(méi)有狀態(tài)持久化和回查那這個(gè)2PC根本不具備上線條件。7.3 Saga補(bǔ)償操作沒(méi)有冪等導(dǎo)致重復(fù)扣款Saga的補(bǔ)償執(zhí)行不保證只執(zhí)行一次網(wǎng)絡(luò)重試、執(zhí)行器重啟都可能讓同一個(gè)補(bǔ)償動(dòng)作被執(zhí)行多次。解決方案是對(duì)每個(gè)補(bǔ)償操作打上全局唯一的事務(wù)ID在數(shù)據(jù)庫(kù)里用唯一索引去重或者在操作前先查詢補(bǔ)償記錄是否已存在。這里我推薦一個(gè)實(shí)踐所有補(bǔ)償操作必須是冪等的而且要能處理補(bǔ)償本身也失敗的情況——需要把失敗的補(bǔ)償記錄下來(lái)交給人工或?qū)~任務(wù)處理不能讓它無(wú)限重試打到下游。7.4 常見(jiàn)問(wèn)題速查表問(wèn)題可能原因排查方法Raft選主頻繁心跳間隔過(guò)短、網(wǎng)絡(luò)抖動(dòng)、磁盤慢檢查心跳配置、抓包統(tǒng)計(jì)延遲、觀察GC停頓數(shù)據(jù)短暫不一致AP系統(tǒng)正常特性確認(rèn)業(yè)務(wù)容忍度檢查補(bǔ)償任務(wù)是否運(yùn)行正常TCC的Confirm重復(fù)觸發(fā)報(bào)錯(cuò)缺乏冪等控制用事務(wù)ID唯一索引做冪等重復(fù)執(zhí)行返回成功本地消息表中的消息始終投遞不成功MQ異常、序列化失敗、消息體過(guò)大查看MQ是否可用、檢查消息表狀態(tài)、增加重試退避Saga事務(wù)回滾后業(yè)務(wù)流程中斷補(bǔ)償時(shí)序不對(duì)、補(bǔ)償未執(zhí)行梳理補(bǔ)償依賴順序補(bǔ)充補(bǔ)償失敗告警和人工介入機(jī)制7.5 一致性排查的通用方法論排查數(shù)據(jù)一致性問(wèn)題時(shí)我有一套固定的三段法先確認(rèn)時(shí)間線哪個(gè)操作先發(fā)生哪個(gè)后發(fā)生操作順序?qū)Σ粚?duì)再確認(rèn)狀態(tài)線每條數(shù)據(jù)在各個(gè)節(jié)點(diǎn)的當(dāng)前狀態(tài)是什么是否有版本號(hào)或時(shí)間戳輔助判斷最后確認(rèn)日志線操作日志、事務(wù)日志、消息投遞記錄是否完整有沒(méi)有丟失或重復(fù)。把三條線疊在一起比對(duì)80%的不一致問(wèn)題都能定位到具體環(huán)節(jié)。剩下的20%往往是某些節(jié)點(diǎn)狀態(tài)機(jī)應(yīng)用邏輯的bug那就需要靠對(duì)賬系統(tǒng)跑批來(lái)兜底了。8. 從理論到落地我的幾點(diǎn)體會(huì)說(shuō)到底CAP定理、分布式事務(wù)模型、Raft算法這些東西從來(lái)都不是孤立的知識(shí)點(diǎn)。它們串起來(lái)其實(shí)是一條完整的決策鏈先認(rèn)清分布式系統(tǒng)的故障模型再想清楚業(yè)務(wù)到底需要什么程度的一致性然后選擇合適的事務(wù)模型最后用讀寫路徑上的核心組件數(shù)據(jù)庫(kù)、消息隊(duì)列、共識(shí)服務(wù)把模型落地。我自己踩過(guò)最大的坑就是一開始總想一步到位搞強(qiáng)一致覺(jué)得最終一致是偷懶。后來(lái)在真實(shí)的電商支付鏈路里做壓測(cè)才發(fā)現(xiàn)強(qiáng)一致方案的代價(jià)不只是性能還有運(yùn)維復(fù)雜度——你要處理協(xié)調(diào)者狀態(tài)持久化、處理故障恢復(fù)、處理網(wǎng)絡(luò)分區(qū)下的僵局。業(yè)務(wù)側(cè)根本等不起。反而是Saga加消息補(bǔ)償?shù)姆桨概浜贤晟频膶?duì)賬監(jiān)控既保證了最終不丟數(shù)據(jù)又扛得住高并發(fā)流量。Raft那套東西真正吃透之后有個(gè)額外的好處你能讀懂etcd、TiKV這些基礎(chǔ)組件在極端情況下的行為邏輯了。比如為什么etcd在Leader選舉期間不能寫、為什么TiKV的分區(qū)容錯(cuò)行為是優(yōu)先保證已提交數(shù)據(jù)的安全這些都能從Raft的機(jī)制里找到答案。知其所以然排查問(wèn)題的時(shí)候就不慌。最后分享一個(gè)小技巧學(xué)習(xí)分布式事務(wù)和一致性算法別只看理論一定要親手搭一個(gè)環(huán)境實(shí)驗(yàn)一下。用Docker拉一個(gè)三節(jié)點(diǎn)的etcd停掉一個(gè)節(jié)點(diǎn)看看讀寫表現(xiàn)再停掉兩個(gè)節(jié)點(diǎn)看看或者起一個(gè)Seata服務(wù)把一個(gè)TCC事務(wù)跑到一半斷掉網(wǎng)絡(luò)看看補(bǔ)償怎么觸發(fā)。這些實(shí)驗(yàn)比讀十篇博客都管用。理論給你地圖實(shí)驗(yàn)給你腳感兩者都到位了分布式系統(tǒng)里的這片坑你才算是真正趟明白了。