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