在分布式事務(wù)中，通常使用兩階段協(xié)議或三階段協(xié)議來(lái)保障分布式事務(wù)的正常運(yùn)行，它也是 X/Open 公司定義的一套分布式事務(wù)標(biāo)準(zhǔn)。

X/Open 公司是由多家國(guó)際計(jì)算機(jī)廠商所組成的聯(lián)盟組織，它建立之初是為了向 UNIX 環(huán)境提供標(biāo)準(zhǔn)。

分布式事務(wù)是指在分布式系統(tǒng)中，多個(gè)節(jié)點(diǎn)之間進(jìn)行的事務(wù)操作。比如在分布式系統(tǒng)中，用戶在下單時(shí)，需要同時(shí)創(chuàng)建訂單信息和減庫(kù)存的操作，然而創(chuàng)建訂單信息和減庫(kù)存是分布在不同服務(wù)器和不同數(shù)據(jù)庫(kù)中的，如下圖所示：

圖片

此時(shí)我們就需要一個(gè)分布式事務(wù)介入，保證所有操作，要么一起提交，要么一起回滾。

1.兩階段提交

兩階段提交（Two-Phase Commit，簡(jiǎn)稱 2PC）是一種分布式事務(wù)協(xié)議，確保所有參與者在提交或回滾事務(wù)時(shí)都處于一致的狀態(tài)。2PC 協(xié)議包含以下兩個(gè)階段：

1. 準(zhǔn)備階段（prepare phase）：在這個(gè)階段，事務(wù)協(xié)調(diào)者（Transaction Coordinator）向所有參與者（Transaction Participant）發(fā)出準(zhǔn)備請(qǐng)求，詢問(wèn)它們是否準(zhǔn)備好提交事務(wù)。參與者執(zhí)行所有必要的操作，并回復(fù)協(xié)調(diào)者是否準(zhǔn)備好提交事務(wù)。如果所有參與者都回復(fù)準(zhǔn)備好提交事務(wù)，協(xié)調(diào)者將進(jìn)入下一個(gè)階段。如果任何參與者不能準(zhǔn)備好提交事務(wù)，協(xié)調(diào)者將通知所有參與者回滾事務(wù)。
2. 提交階段（commit phase）：在這個(gè)階段，如果所有參與者都已準(zhǔn)備好提交事務(wù)，則協(xié)調(diào)者向所有參與者發(fā)送提交請(qǐng)求。參與者執(zhí)行所有必要的操作，并將其結(jié)果記錄在持久性存儲(chǔ)中。一旦所有參與者都已提交事務(wù)，協(xié)調(diào)者將向它們發(fā)送確認(rèn)請(qǐng)求。如果任何參與者未能提交事務(wù)，則協(xié)調(diào)者將通知所有參與者回滾事務(wù)。

2PC 協(xié)議可以確保分布式事務(wù)的原子性和一致性，但是其效率較低，可能會(huì)出現(xiàn)阻塞等問(wèn)題。因此，在實(shí)際應(yīng)用中，可以使用其他分布式事務(wù)協(xié)議，如 3PC（Three-Phase Commit）或 Paxos 協(xié)議來(lái)代替。

兩階段提交問(wèn)題

兩階段提交存在以下幾個(gè)問(wèn)題：

1. 同步阻塞問(wèn)題：執(zhí)行過(guò)程中，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問(wèn)公共資源不得不處于阻塞狀態(tài)。也就是說(shuō)從投票階段到提交階段完成這段時(shí)間，資源是被鎖住的。
2. 單點(diǎn)故障：由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障。參與者會(huì)一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無(wú)法繼續(xù)完成事務(wù)操作。
3. 數(shù)據(jù)不一致問(wèn)題：在 2PC 最后提交階段中，當(dāng)協(xié)調(diào)者向參與者發(fā)送 commit 請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘咴诎l(fā)送 commit 請(qǐng)求過(guò)程中協(xié)調(diào)者發(fā)生了故障，這會(huì)導(dǎo)致只有一部分參與者接受到了 commit 請(qǐng)求。而在這部分參與者接到 commit 請(qǐng)求之后就會(huì)執(zhí)行 commit 操作。但是其他部分未接到 commit 請(qǐng)求的機(jī)器則無(wú)法執(zhí)行事務(wù)提交，于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致性的現(xiàn)象。

2.三階段提交

三階段提交（Three-Phase Commit，簡(jiǎn)稱3PC）是在 2PC 協(xié)議的基礎(chǔ)上添加了一個(gè)額外的階段來(lái)解決 2PC 協(xié)議可能出現(xiàn)的阻塞問(wèn)題。3PC 協(xié)議包含三個(gè)階段：

1. CanCommit 階段（詢問(wèn)階段）：在這個(gè)階段，事務(wù)協(xié)調(diào)者（Transaction Coordinator）向所有參與者（Transaction Participant）發(fā)出 CanCommit 請(qǐng)求，詢問(wèn)它們是否準(zhǔn)備好提交事務(wù)。參與者執(zhí)行所有必要的操作，并回復(fù)協(xié)調(diào)者它們是否可以提交事務(wù)。
2. PreCommit 階段（準(zhǔn)備階段）：如果所有參與者都回復(fù)可以提交事務(wù)，則協(xié)調(diào)者將向所有參與者發(fā)送PreCommit 請(qǐng)求，通知它們準(zhǔn)備提交事務(wù)。參與者執(zhí)行所有必要的操作，并回復(fù)協(xié)調(diào)者它們是否已經(jīng)準(zhǔn)備好提交事務(wù)。
3. DoCommit 階段（提交階段）：如果所有參與者都已經(jīng)準(zhǔn)備好提交事務(wù)，則協(xié)調(diào)者將向所有參與者發(fā)送DoCommit 請(qǐng)求，通知它們提交事務(wù)。參與者執(zhí)行所有必要的操作，并將其結(jié)果記錄在持久性存儲(chǔ)中。一旦所有參與者都已提交事務(wù)，協(xié)調(diào)者將向它們發(fā)送確認(rèn)請(qǐng)求。如果任何參與者未能提交事務(wù)，則協(xié)調(diào)者將通知所有參與者回滾事務(wù)。

與 2PC 協(xié)議相比，3PC 協(xié)議將 CanCommit 階段（詢問(wèn)階段）添加到協(xié)議中，使參與者能夠在 CanCommit 階段發(fā)現(xiàn)并解決可能導(dǎo)致阻塞的問(wèn)題。這樣，3PC 協(xié)議能夠更快地執(zhí)行提交或回滾事務(wù)，并減少不必要的等待時(shí)間。需要注意的是，與 2PC 協(xié)議相比，3PC 協(xié)議仍然可能存在阻塞的問(wèn)題。

3.兩階段提交 VS 三階段提交

2PC 和 3PC 是分布式事務(wù)中兩種常見(jiàn)的協(xié)議，3PC 可以看作是 2PC 協(xié)議的改進(jìn)版本，相比于 2PC 它有兩點(diǎn)改進(jìn)：

1. 引入了超時(shí)機(jī)制，同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制（2PC 只有協(xié)調(diào)者有超時(shí)機(jī)制）；
2. 3PC 相比于 2PC 增加了 CanCommit 階段，可以盡早的發(fā)現(xiàn)問(wèn)題，從而避免了后續(xù)的阻塞和無(wú)效操作。

也就是說(shuō)，3PC 相比于 2PC，因?yàn)橐肓顺瑫r(shí)機(jī)制，所以發(fā)生阻塞的幾率變小了；同時(shí) 3PC 把之前 2PC 的準(zhǔn)備階段一分為二，變成了兩步，這樣就多了一個(gè)緩沖階段，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

4.數(shù)據(jù)一致性問(wèn)題和解決方案

3PC 雖然可以減少同步阻塞問(wèn)題和單點(diǎn)故障問(wèn)題，但依然存在數(shù)據(jù)一致性問(wèn)題（概率很小），而解決數(shù)據(jù)一致性問(wèn)題的方案有很多，比如 Paxos 算法或柔性事物機(jī)制等。

4.1 Paxos 算法

Paxos 算法是一種基于消息傳遞的分布式一致性算法，并在 2013 年獲得了圖靈獎(jiǎng)。圖靈獎(jiǎng)（ACM A.M. Turing Award）是計(jì)算機(jī)科學(xué)領(lǐng)域最高榮譽(yù)之一，由美國(guó)計(jì)算機(jī)協(xié)會(huì)（ACM）于 1966 年設(shè)立，每年頒發(fā)一次，表彰對(duì)計(jì)算機(jī)科學(xué)領(lǐng)域做出杰出貢獻(xiàn)的人士或團(tuán)體。簡(jiǎn)單來(lái)說(shuō)，Paxos 算法是一種分布式共識(shí)算法，用于在分布式系統(tǒng)中實(shí)現(xiàn)數(shù)據(jù)的一致性和共識(shí)，保證分布式系統(tǒng)中不同節(jié)點(diǎn)之間的數(shù)據(jù)同步和一致性。Paxos 算法由三個(gè)角色組成：提議者、接受者和學(xué)習(xí)者。當(dāng)一個(gè)節(jié)點(diǎn)需要發(fā)起一個(gè)提議時(shí)，它會(huì)向其他節(jié)點(diǎn)發(fā)送一個(gè)提議，接受者會(huì)接收到這個(gè)提議，并對(duì)其進(jìn)行處理，可能會(huì)拒絕提議，也可能會(huì)接受提議。如果有足夠多的節(jié)點(diǎn)接受了該提議，那么提議就會(huì)被確定下來(lái)，并且通知給所有學(xué)習(xí)者，最終所有節(jié)點(diǎn)都會(huì)達(dá)成共識(shí)。Paxos 算法看起來(lái)很簡(jiǎn)單，但它實(shí)際上是非常的復(fù)雜。Paxos 算法應(yīng)用的產(chǎn)品也很多，比如以下幾個(gè)：

• Redis：Redis 是一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，使用 Paxos 算法實(shí)現(xiàn)了分布式鎖服務(wù)和主從復(fù)制等功能。
• MySQL：MySQL 5.7 推出的用來(lái)取代傳統(tǒng)的主從復(fù)制的 MySQL Group Replication 等。
• ZooKeeper：ZooKeeper 是一個(gè)分布式協(xié)調(diào)服務(wù)，使用 Paxos 算法實(shí)現(xiàn)了分布式鎖服務(wù)和數(shù)據(jù)一致性等功能。
• Apache Cassandra：Cassandra 是一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)，使用 Paxos 算法實(shí)現(xiàn)了數(shù)據(jù)的一致性和復(fù)制等功能。
• Google Chubby：Chubby 是 Google 內(nèi)部使用的分布式鎖服務(wù)，使用 Paxos 算法實(shí)現(xiàn)了分布式鎖服務(wù)和命名服務(wù)等功能。

4.2 柔性事務(wù)

柔性事務(wù)機(jī)制：允許一定時(shí)間內(nèi)不同節(jié)點(diǎn)的數(shù)據(jù)不一致，但要求最終一致的機(jī)制。柔性事物有 TCC 補(bǔ)償事物、可靠消息事物（MQ 事物）等。

小結(jié)

在分布式事務(wù)中，通常使用兩階段或三階段提交協(xié)議來(lái)保障分布式事務(wù)的正常執(zhí)行。兩階段協(xié)議包含準(zhǔn)備階段和提交階段，然而它存在同步阻塞問(wèn)題、單點(diǎn)故障和數(shù)據(jù)一致性問(wèn)題。而三階段協(xié)議可以看作是兩階段協(xié)議的改進(jìn)版，它將兩階段的準(zhǔn)備階段一分為二，多了一個(gè)詢問(wèn)階段，保證了提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的，同時(shí)引入了超時(shí)機(jī)制，減少了同步阻塞問(wèn)題發(fā)生的幾率。但 2PC 和 3PC 都存在數(shù)據(jù)一致性問(wèn)題，此時(shí)可以采用 Paxos 算法或柔性事務(wù)機(jī)制等方案來(lái)解決事務(wù)一致性問(wèn)題。

參考 & 鳴謝

https://pdai.tech/md/arch/arch-z-transection.html