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

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

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

圖片

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

1.兩階段提交

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

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

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

兩階段提交問題

兩階段提交存在以下幾個問題：

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

2.三階段提交

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

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

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

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

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

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

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

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

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

4.1 Paxos 算法

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

• Redis：Redis 是一個內(nèi)存數(shù)據(jù)庫，使用 Paxos 算法實(shí)現(xiàn)了分布式鎖服務(wù)和主從復(fù)制等功能。
• MySQL：MySQL 5.7 推出的用來取代傳統(tǒng)的主從復(fù)制的 MySQL Group Replication 等。
• ZooKeeper：ZooKeeper 是一個分布式協(xié)調(diào)服務(wù)，使用 Paxos 算法實(shí)現(xiàn)了分布式鎖服務(wù)和數(shù)據(jù)一致性等功能。
• Apache Cassandra：Cassandra 是一個分布式數(shù)據(jù)庫系統(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ī)制：允許一定時間內(nèi)不同節(jié)點(diǎn)的數(shù)據(jù)不一致，但要求最終一致的機(jī)制。柔性事物有 TCC 補(bǔ)償事物、可靠消息事物（MQ 事物）等。

小結(jié)

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

參考 & 鳴謝

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