1.前言
前面一篇文章和大家一起學(xué)習(xí)了下分布式系統(tǒng)一致性問題的一些理論，其中重點是理解
PACELC理論、
BASE理論等問題，讓我們對于分布式一致性的重點是什么有一些認識。
在了解分布式一致性的理論和概念之后，后續(xù)將和大家一起討論分布式一致性協(xié)議，其中包括：
2PC、3PC、Paoxs協(xié)議、Raft協(xié)議。
篇幅有限，本文重點展開2PC協(xié)議，后續(xù)文章繼續(xù)深入。
圖(網(wǎng)絡(luò))|NASA合成的銀河系中心區(qū)域圖像
2. 單機事務(wù)和分布式事務(wù)
在聊2PC和3PC之前，我們有必要先了解下
單機事務(wù)和
分布式事務(wù)。
事務(wù)是一組原子操作，
要么全成功要么全失敗 All or Nothing，否則就會出現(xiàn)數(shù)據(jù)混亂，這種需求在
金融和電商領(lǐng)域很普遍。
試想你去天貓買了臺mac，訂單服務(wù)、扣款服務(wù)、庫存服務(wù)出現(xiàn)任何一個環(huán)節(jié)的失敗都會帶來問題，所以就需要事務(wù)來做保證，
一榮俱榮一損俱損。
單機事務(wù)具備ACID特性，大家都比較喜歡，但是單機的能力畢竟有限，我們常常必須在分布式場景下同樣完成這一組原子操作，也就是分布式事務(wù)。
由于分布式系統(tǒng)中各個子服務(wù)是部署在
不同的物理節(jié)點上，
不同交換機、
不同機房、不同城市，這樣以來，要想
像單機系統(tǒng)一樣完成這一組原子操作就沒那么容易了，因此就出現(xiàn)了很多分布式一致性協(xié)議和算法，來解決分布式事務(wù)問題保證數(shù)據(jù)一致性。
分布式系統(tǒng)的各個節(jié)點只能依靠
網(wǎng)絡(luò)來進行數(shù)據(jù)通信，但是網(wǎng)絡(luò)往往
并不完全可靠，同時節(jié)點
物理故障也時常發(fā)生，在這樣一個
復(fù)雜的環(huán)境中去保證數(shù)據(jù)一致性確實不太容易。
3.一致性協(xié)議的一些思路
突兀地去學(xué)習(xí)一個新的協(xié)議或者算法往往比較生硬，不如思考一下生活現(xiàn)象，大部分的計算機領(lǐng)域的算法和思想在實際生活中都有映像，又或者說
算法來源于生活。
舉個栗子：在規(guī)模盛大的閱兵儀式中會有陸?？斩啾N多方隊，為了讓命令和節(jié)奏準(zhǔn)確地下達，我們
需要樂曲、指揮、領(lǐng)隊、排頭、隊員等多種角色。整個活動需要在不同角色的相互作用之下，才能讓一個數(shù)量龐大的個體組成一個整體來完成一個目標(biāo)。
再舉個栗子：2018年5月在西安舉行了一場盛大的
無人機編組飛行燈光秀，共計1374架無人機組成一個龐大的編組來完成燈光表演，但是還是出現(xiàn)了問題，并未上演完美圖案：
圖(網(wǎng)絡(luò))|西安無人機編組飛行燈光秀
分布式系統(tǒng)也是如此，為了讓很多參與的機器節(jié)點節(jié)奏步調(diào)一致，我們就需要不同的角色各司其職，共同完成一項任務(wù)，但是仍然困難重重，因為會有網(wǎng)絡(luò)故障和節(jié)點物理故障等問題。
4. 2PC二階段提交協(xié)議基本過程
要理解2PC協(xié)議重點在于節(jié)點角色分工和兩個階段所執(zhí)行的動作以及不同情況下的處理邏輯。
2PC協(xié)議總體概覽
4.1 節(jié)點角色
二階段提交協(xié)議將節(jié)點分為：
協(xié)調(diào)者和
參與者，對于者兩種角色，當(dāng)然你也可以理解為
Leader和大頭兵。
-
協(xié)調(diào)者Leader
負責(zé)向參與者發(fā)送指令，收集參與者反饋，做出提交或者回滾決策
-
參與者大頭兵
接收協(xié)調(diào)者的指令執(zhí)行事務(wù)操作，向協(xié)調(diào)者反饋操作結(jié)果，并繼續(xù)執(zhí)行協(xié)調(diào)者發(fā)送的最終指令
4.2 兩個階段
2PC協(xié)議分為：
準(zhǔn)備階段和
提交階段。
協(xié)調(diào)者向所有參與者節(jié)點發(fā)送詢問并執(zhí)行事務(wù)的命令，參與者節(jié)點收到命令后根據(jù)自己的狀態(tài)執(zhí)行或者不執(zhí)行事務(wù)，并將動作記錄下來，最后將對命令的處理結(jié)果反饋給協(xié)調(diào)者。
圖|準(zhǔn)備階段的三個環(huán)節(jié)
1詢問環(huán)節(jié)：協(xié)調(diào)者向參與者詢問，是否準(zhǔn)備好可以執(zhí)行事務(wù)，之后協(xié)調(diào)者開始等待各參與者的響應(yīng)，這個環(huán)節(jié)協(xié)調(diào)者處于阻塞等待狀態(tài)。
2處理環(huán)節(jié)：參與者收到協(xié)調(diào)者的詢問后根據(jù)自身情況來決定是否執(zhí)行事務(wù)操作，如果參與者執(zhí)行事務(wù)成功，將Undo和Redo信息記入事務(wù)日志，但不提交事務(wù)；否則直接返回失敗。
3響應(yīng)環(huán)節(jié)：當(dāng)參與者成功執(zhí)行了事務(wù)操作，就反饋yes給協(xié)調(diào)者，表示事務(wù)在本地執(zhí)行；當(dāng)參與者沒有成功執(zhí)行事務(wù)，就反饋no給協(xié)調(diào)者，表示事務(wù)不可以執(zhí)行提交，這部分反饋對于協(xié)調(diào)者決策下個階段起到非常重要的作用。
協(xié)調(diào)者根據(jù)準(zhǔn)備階段收到的參與者反饋來決定最終提交事務(wù)或者中斷回滾事務(wù)，具體來說，當(dāng)協(xié)調(diào)者在準(zhǔn)備階段結(jié)束時收到的響應(yīng)反饋有一個no，那么就中斷事務(wù)，如果收到的反饋全部是yes就提交事務(wù)。
如果在準(zhǔn)備階段結(jié)束時，協(xié)調(diào)者收到了來自所有參與者的yes反饋，接下來協(xié)調(diào)者就會向所有參與者發(fā)送提交事務(wù)指令，具體的過程如下：
步驟1. 協(xié)調(diào)者向所有參與者發(fā)送事務(wù)提交消息Commit命令
步驟2. 參與者在收到來自協(xié)調(diào)者的Commit命令之后，執(zhí)行事務(wù)提交動作，并釋放事務(wù)期間所有持有的鎖和資源，這一步很重要
步驟3. 所有參與者在執(zhí)行本地事務(wù)且釋放資源完成后，向協(xié)調(diào)者發(fā)送事務(wù)提交確認消息ACK
步驟4. 協(xié)調(diào)者在收到所有參與者的ACK消息后確認完成本次事務(wù)
如果在準(zhǔn)備階段結(jié)束時，協(xié)調(diào)者
沒有收到來自所有參與者的yes反饋，接下來協(xié)調(diào)者就會向所有參與者發(fā)送
回滾事務(wù)指令，具體的過程如下：
步驟1. 協(xié)調(diào)者向所有參與者發(fā)送事務(wù)回滾消息Rollback
步驟2. 參與者收到Rollback回滾指令后，根據(jù)本地的回滾日志來撤銷階段一執(zhí)行的事務(wù)，并釋放事務(wù)期間所有持有的鎖和資源
步驟3. 所有參與者在完成指令后向協(xié)調(diào)者回復(fù)反饋ACK
步驟4. 協(xié)調(diào)者在收到所有參與者的ACK確認消息后撤銷該事務(wù)
通過上面的描述我們知道了，2PC協(xié)議通過將節(jié)點分為不同的角色，進行兩個階段的處理來執(zhí)行分布式事務(wù)，但是難免要去想2PC協(xié)議可以真正解決分布式數(shù)據(jù)一致問題嗎？
5. 2PC協(xié)議的異常分析
前面的兩個階段涉及了多次協(xié)調(diào)者和參與者的網(wǎng)絡(luò)通信交互，但是我們都知道
網(wǎng)絡(luò)是不可靠的，
節(jié)點也能出現(xiàn)故障，因此必須要考慮異常情況下2PC協(xié)議是否仍然可以正常工作。
故障可以分為很多種：
可恢復(fù)機器故障和
不可恢復(fù)機器故障、
網(wǎng)絡(luò)正常抖動故障、
網(wǎng)絡(luò)分區(qū)故障等多種情況。
2PC整個過程交互也很多，
不同階段發(fā)生不同故障造成的結(jié)果也是不一樣的，顯然
這是個m*n的組合問題，不同的異常情況會產(chǎn)生不同的結(jié)果要完全列出來并分析絕非易事，我們找其中幾個重點異常來做分析。
從前面的分析我們知道，在準(zhǔn)備階段本質(zhì)上是不會提交事務(wù)數(shù)據(jù)的，即使發(fā)生故障也可以根據(jù)日志來進行回滾，所以不會產(chǎn)生數(shù)據(jù)不一致的問題，但是在提交階段提交事務(wù)的情況下由于可能已經(jīng)有參與者提交了事務(wù)數(shù)據(jù)，因此可能出現(xiàn)數(shù)據(jù)不一致，這個是要重點分析的階段。
注：以下所說的參與者故障并非指全部的參與者，而是其中1個或者幾個。
協(xié)調(diào)者作為系統(tǒng)的領(lǐng)導(dǎo)者角色，由于協(xié)調(diào)者是單點的在任何過程出現(xiàn)異常都需要重點處理，發(fā)生不可恢復(fù)的物理故障時，選舉出新的協(xié)調(diào)者來接替之前的工作，這時新協(xié)調(diào)者就需要向所有參與者詢問當(dāng)前的階段和處理進度，但是如果只是出現(xiàn)網(wǎng)絡(luò)分區(qū)協(xié)調(diào)者暫時失聯(lián)，就可能出現(xiàn)腦裂的情況。
由于協(xié)調(diào)者做決策需要依據(jù)參與者的反饋，出現(xiàn)參與者故障會造成協(xié)調(diào)者決策困難，如果參與者的故障是可恢復(fù)的，在短時間內(nèi)恢復(fù)后則向協(xié)調(diào)者詢問自己需要做什么，從而跟上節(jié)奏，如果時間過長或者是不可恢復(fù)故障，那么協(xié)調(diào)者就會回滾本次事務(wù)。
-
協(xié)調(diào)者故障&參與者故障(重點)
協(xié)調(diào)者在提交階段會向所有參與者發(fā)送指令，假定在
協(xié)調(diào)者發(fā)送第一條指令之后掛掉，此時
只有一個參與者接收到了指令并執(zhí)行后也掛掉了，
其他
參與者并沒有收到指令。
新選舉出來的協(xié)調(diào)者詢問所有參與節(jié)點狀態(tài)時，如果
已經(jīng)掛掉的參與者恢復(fù)了，那么狀態(tài)就明確了commit或者rollback，如果掛掉的
參與者并沒有恢復(fù)并且已經(jīng)執(zhí)行了commit/rollback操作，那么將會
出現(xiàn)數(shù)據(jù)不一致，并且新的協(xié)調(diào)者由于沒有獲得足夠的信息無法明確當(dāng)前的狀態(tài)，其他的參與者在階段一執(zhí)行后
產(chǎn)生阻塞。
網(wǎng)絡(luò)分區(qū)是個很棘手的問題，極端情況下可能出現(xiàn)幾個分區(qū)，不同分區(qū)中有獨自的參與者和協(xié)調(diào)者。
綜上可知，2PC協(xié)議在協(xié)調(diào)者和參與者都掛掉的時候會出現(xiàn)數(shù)據(jù)不一致，并且在正常的交互過程中會有阻塞情況，以及協(xié)調(diào)者單點的問題。
6.2PC協(xié)議的優(yōu)缺點
2PC協(xié)議的原理簡單，實現(xiàn)方便，但是存在
同步阻塞、
單點問題、
網(wǎng)絡(luò)
分區(qū)腦裂、極端情況
數(shù)據(jù)不一致的問題，我們具體展開一下。
2PC在準(zhǔn)備階段等待參與者響應(yīng)反饋時是同步阻塞的，在實際網(wǎng)絡(luò)中可能會導(dǎo)致長時間阻塞的問題，因為我們無法保證所有參與者網(wǎng)絡(luò)的順暢。
協(xié)調(diào)者在整個兩階段中作用很大，但是存在單點問題，一旦出現(xiàn)協(xié)調(diào)者故障，所有的參與者都將處于阻塞資源無法釋放的情況，從而影響其他操作的進行。
2PC協(xié)議整個過程中基于所有參與者的反饋，但是由于異常情況的存在，在一些時候很難達成一致從而回滾事務(wù)，整個策略容錯性不強，并且網(wǎng)絡(luò)分區(qū)的存在可能產(chǎn)生腦裂造成分區(qū)數(shù)據(jù)不一致。
7.小結(jié)
本文對從單機事務(wù)和分布式事務(wù)的剛需作為切入點，描述了分布式數(shù)據(jù)一致性的難點和基本解決思路，重點闡述了2PC協(xié)議準(zhǔn)備階段和提交階段的詳細過程，最后對2PC協(xié)議的異常情況做出分析并給出2PC協(xié)議的優(yōu)缺點。
8.巨人的肩膀
-
https://www.cnblogs.com/sunsky303/p/9290992.html
-
https://segmentfault.com/q/1010000014439562
-
https://www.cnblogs.com/shangxiaofei/p/5196260.html
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
