分布式事務(wù)在分布式系統(tǒng)經(jīng)常遇見，也是大廠經(jīng)常考察的內(nèi)容，下面我就重點(diǎn)詳解四大主流分布式事務(wù)方案@mikechen

分布式事務(wù)

分布式事務(wù)是指涉及多個(gè)參與者，通常是不同的計(jì)算機(jī)節(jié)點(diǎn)或服務(wù)的事務(wù)操作，因此需要跨多個(gè)節(jié)點(diǎn)執(zhí)行事務(wù)操作。

如下圖所示：

圖片

分布式事務(wù)需要確保所有相關(guān)操作要么全部成功執(zhí)行，要么全部回滾，以維護(hù)數(shù)據(jù)的一致性和可靠性。

分布式事務(wù)解決方案

常見的分布式事務(wù)解決方案，主要包含有以下四種：

兩階段提交協(xié)議

兩階段提交協(xié)議，Two-Phase Commit，簡(jiǎn)稱是2PC，該協(xié)議包括：準(zhǔn)備和提交兩個(gè)階段。

如下圖所示:

圖片

1.準(zhǔn)備階段

協(xié)調(diào)者向所有參與者發(fā)送準(zhǔn)備請(qǐng)求，參與者執(zhí)行事務(wù)準(zhǔn)備，并向協(xié)調(diào)者發(fā)送準(zhǔn)備就緒的通知。

2.提交階段

如果所有參與者都準(zhǔn)備就緒，則協(xié)調(diào)者向所有參與者發(fā)送提交請(qǐng)求，參與者執(zhí)行事務(wù)提交。

如果所有參與者都成功提交了事務(wù)，則事務(wù)成功完成。

否則，如果任何一個(gè)參與者失敗或者無法提交，則所有參與者都會(huì)被要求回滾（Rollback）事務(wù)，以保持一致性。

2PC的優(yōu)點(diǎn)是簡(jiǎn)單易懂，并且在理想情況下能夠保證分布式系統(tǒng)中事務(wù)的原子性和一致性。

兩階段有如下幾個(gè)缺點(diǎn)：

1.阻塞問題

在2PC的準(zhǔn)備階段，協(xié)調(diào)者需要等待所有參與者的響應(yīng)，這可能會(huì)導(dǎo)致整個(gè)系統(tǒng)的阻塞。

2.單點(diǎn)故障

在2PC中，協(xié)調(diào)者是一個(gè)單點(diǎn)，它負(fù)責(zé)協(xié)調(diào)所有參與者的操作。

如果協(xié)調(diào)者發(fā)生故障，那么整個(gè)事務(wù)可能會(huì)無法完成，即使參與者的大部分已經(jīng)準(zhǔn)備好了，這種單點(diǎn)故障會(huì)影響系統(tǒng)的可用性和可靠性。

3.數(shù)據(jù)不一致性

2PC無法處理所有故障情況，例如：協(xié)調(diào)者和參與者之間的網(wǎng)絡(luò)分區(qū)或者通信失敗。

在這種情況下，可能會(huì)出現(xiàn)數(shù)據(jù)不一致性，一些參與者已經(jīng)提交了事務(wù)，而另一些參與者卻未收到提交指令，導(dǎo)致系統(tǒng)狀態(tài)混亂。

三階段提交協(xié)議

三階段提交協(xié)議，Three-phase commit, 簡(jiǎn)稱是3PC，3PC是2PC的改進(jìn)版。

如下圖所示：

圖片

3PC的主要思想是引入一個(gè)【預(yù)提交階段】，以減輕2PC中的阻塞問題，同時(shí)保持原子性和一致性。

3PC，主要分為三個(gè)階段：

1.預(yù)提交階段

協(xié)調(diào)者詢問參與者是否可以提交事務(wù)，并等待它們的響應(yīng)，如果所有參與者都同意，則進(jìn)入下一階段。

2.提交階段

協(xié)調(diào)者向所有參與者發(fā)送提交請(qǐng)求，要求它們提交事務(wù)，如果任何參與者無法提交，則執(zhí)行回滾。

3.確認(rèn)階段

協(xié)調(diào)者向所有參與者發(fā)送確認(rèn)消息，告知它們事務(wù)已經(jīng)提交，這一階段用于解決2PC中的阻塞問題。

3PC相較于2PC的優(yōu)點(diǎn)是在第一階段引入了一個(gè)“詢問”階段，避免了2PC的直接準(zhǔn)備階段可能出現(xiàn)的長(zhǎng)時(shí)間阻塞問題。

兩階段與三階段對(duì)比，如下圖所示：

圖片

補(bǔ)償事務(wù)

TCC（Try-Confirm-Cancel）是一種補(bǔ)償性事務(wù)處理模式，用于實(shí)現(xiàn)分布式系統(tǒng)中的一致性操作。

如下圖所示：

圖片

TCC模式通過三個(gè)階段的操作來確保事務(wù)的一致性：嘗試（Try）、確認(rèn)（Confirm）和取消（Cancel）。

1.嘗試階段（Try）

在嘗試階段，系統(tǒng)會(huì)嘗試執(zhí)行事務(wù)操作的所有必要檢查和準(zhǔn)備工作，以確保事務(wù)能夠成功執(zhí)行。

這包括檢查資源的可用性、鎖定所需資源等，如果所有的檢查都通過，系統(tǒng)會(huì)記錄下所有的嘗試操作，但并不會(huì)實(shí)際執(zhí)行事務(wù)。

2.確認(rèn)階段（Confirm）

在確認(rèn)階段，系統(tǒng)會(huì)執(zhí)行事務(wù)操作，并且確認(rèn)之前所做的嘗試操作。

如果事務(wù)操作成功執(zhí)行，系統(tǒng)將確認(rèn)并提交事務(wù)，在這個(gè)階段，系統(tǒng)會(huì)持久化事務(wù)的結(jié)果，確保事務(wù)的最終執(zhí)行。

3.取消階段（Cancel）

如果在嘗試階段或者確認(rèn)階段發(fā)生了錯(cuò)誤或者異常情況，系統(tǒng)將進(jìn)入取消階段。

在這個(gè)階段，系統(tǒng)會(huì)執(zhí)行逆向操作，取消之前嘗試階段所做的操作，這樣可以確保系統(tǒng)的狀態(tài)回滾到事務(wù)開始之前的狀態(tài)，以維持?jǐn)?shù)據(jù)的一致性。

TCC模式允許開發(fā)人員在每個(gè)階段都定義自己的業(yè)務(wù)邏輯和補(bǔ)償操作，以適應(yīng)不同的業(yè)務(wù)需求。

但是，TCC模式要求開發(fā)人員在每個(gè)階段都顯式定義業(yè)務(wù)邏輯和補(bǔ)償操作，這增加了系統(tǒng)的復(fù)雜性和開發(fā)成本，需要設(shè)計(jì)和維護(hù)每個(gè)階段的邏輯，并確保它們之間的一致性。

最終一致性

最終一致性是分布式系統(tǒng)中的一種一致性模型，它允許數(shù)據(jù)副本在一段時(shí)間內(nèi)的狀態(tài)之間存在不一致，但最終將會(huì)達(dá)到一致的狀態(tài)。

如下圖所示：

圖片

在最終一致性模型中，節(jié)點(diǎn)之間的數(shù)據(jù)同步通常是通過消息傳遞來實(shí)現(xiàn)的。

當(dāng)一個(gè)節(jié)點(diǎn)的數(shù)據(jù)發(fā)生變化時(shí)，它會(huì)通過異步方式將消息發(fā)送給其他節(jié)點(diǎn)，由于消息傳遞是異步的，因此節(jié)點(diǎn)之間的數(shù)據(jù)同步可能會(huì)有一定的延遲。

因此，最終一致性模型允許節(jié)點(diǎn)之間的數(shù)據(jù)副本，在一段時(shí)間內(nèi)存在不一致，但最終會(huì)收斂到一致的狀態(tài)。