本文轉(zhuǎn)載自微信公眾號(hào)「 后端技術(shù)指南針」，轉(zhuǎn)載本文請(qǐng)聯(lián)系 后端技術(shù)指南針公眾號(hào)。

1.前言

在了解分布式一致性的理論和概念之后，后續(xù)將和大家一起討論分布式一致性協(xié)議，其中包括：2PC、3PC、Paoxs協(xié)議、Raft協(xié)議。篇幅有限，本文重點(diǎn)展開(kāi)2PC協(xié)議，后續(xù)文章繼續(xù)深入。

[[325517]]

圖(網(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)域很普遍。試想你去天貓買了臺(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ì)有陸?？斩啾N多方隊(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)題，并未上演完美圖案：

[[325520]]

圖(網(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)然你也可以理解為L(zhǎng)eader和大頭兵。

• 協(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)備階段和提交階段。

4.2.1 準(zhǔn)備階段

協(xié)調(diào)者向所有參與者節(jié)點(diǎn)發(fā)送詢問(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詢問(wèn)環(huán)節(jié)：協(xié)調(diào)者向參與者詢問(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)者的詢問(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è)階段起到非常重要的作用。

4.2.2 準(zhǔn)備階段

協(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ù)。情況一: 提交事務(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ù)

情況二: 回滾事務(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)撤銷階段一執(zhí)行的事務(wù)，并釋放事務(wù)期間所有持有的鎖和資源

步驟3. 所有參與者在完成指令后向協(xié)調(diào)者回復(fù)反饋ACK

步驟4. 協(xié)調(diào)者在收到所有參與者的ACK確認(rèn)消息后撤銷該事務(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)者故障&參與者正常

協(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)者就需要向所有參與者詢問(wèn)當(dāng)前的階段和處理進(jìn)度，但是如果只是出現(xiàn)網(wǎng)絡(luò)分區(qū)協(xié)調(diào)者暫時(shí)失聯(lián)，就可能出現(xiàn)腦裂的情況。

• 協(xié)調(diào)者正常&參與者故障

由于協(xié)調(diào)者做決策需要依據(jù)參與者的反饋，出現(xiàn)參與者故障會(huì)造成協(xié)調(diào)者決策困難，如果參與者的故障是可恢復(fù)的，在短時(shí)間內(nèi)恢復(fù)后則向協(xié)調(diào)者詢問(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)者詢問(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ò)故障

網(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