分布式事務(wù)是非常核心的分布式系統(tǒng)，也是大廠經(jīng)?？疾鞂?duì)象，下面我就重點(diǎn)詳解分布式事務(wù)及原理實(shí)現(xiàn)@mikechen

分布式事務(wù)

分布式事務(wù)指的是涉及多個(gè)獨(dú)立服務(wù)的操作，這些服務(wù)可能分布在不同的節(jié)點(diǎn)、主機(jī)甚至不同的數(shù)據(jù)中心中。

如下圖所示：

圖片

上圖一次大的事務(wù)操作，由不同的小事務(wù)操作組成，這些小事務(wù)的操作分布在不同的服務(wù)器上，這些操作要么全部成功，要么全部失敗。

分布式事務(wù)的目標(biāo)是確?？缍鄠€(gè)服務(wù)的一系列操作要么全部成功，要么全部回滾，以保持?jǐn)?shù)據(jù)的一致性和完整性。

分布式事務(wù)的關(guān)鍵問題是如何協(xié)調(diào)和管理多個(gè)服務(wù)之間的事務(wù)狀態(tài)，以保證最終的一致性。

分布式事務(wù)實(shí)現(xiàn)方案

常見的分布式事務(wù)解決方案有兩階段提交（Two-Phase Commit，簡稱2PC）、TCC（Try-Confirm-Cancel）和消息隊(duì)列等。

1.兩階段提交（Two-Phase Commit，2PC）

2PC是一種經(jīng)典的分布式事務(wù)協(xié)議，在2PC中一個(gè)事務(wù)協(xié)調(diào)器（Transaction Coordinator）負(fù)責(zé)協(xié)調(diào)多個(gè)參與者（Participants）的操作。

2PC協(xié)議分為兩個(gè)階段：準(zhǔn)備階段和提交階段。

圖片

第一階段：prepare

每個(gè)參與者執(zhí)行本地事務(wù)但不提交，進(jìn)入 ready 狀態(tài)，并通知協(xié)調(diào)者已經(jīng)準(zhǔn) 備就緒。

第二階段：commit

當(dāng)協(xié)調(diào)者確認(rèn)每個(gè)參與者都 ready 后，通知參與者進(jìn)行 commit 操作，如果有 參與者 fail ，則發(fā)送 rollback 命令，各參與者做回滾。

2.TCC（Try-Confirm-Cancel）

TCC是一種基于補(bǔ)償機(jī)制的分布式事務(wù)解決方案，在TCC模式中，每個(gè)服務(wù)都提供三個(gè)操作：Try（嘗試）、Confirm（確認(rèn)）和Cancel（取消）。

圖片

第一階段：CanCommit階段

協(xié)調(diào)者向參與者發(fā)送CanCommit請求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

第二階段：PreCommit階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以繼續(xù)事務(wù)的PreCommit操作。

第三階段：DoCommit階段

協(xié)調(diào)者基于每個(gè)參與者PreCommit階段的反饋結(jié)果，決定真正提交事務(wù)，還是中斷事務(wù)。

當(dāng)一個(gè)事務(wù)涉及多個(gè)服務(wù)時(shí)，每個(gè)服務(wù)的Try操作會(huì)執(zhí)行一系列預(yù)操作，如果所有服務(wù)的Try操作都成功，則執(zhí)行Confirm操作，否則執(zhí)行Cancel操作來回滾之前的操作。

TCC模式需要開發(fā)人員手動(dòng)實(shí)現(xiàn)事務(wù)的補(bǔ)償邏輯，適用于一些需要自定義補(bǔ)償邏輯的場景。

3.消息隊(duì)列

用消息隊(duì)列作為分布式事務(wù)的解決方案，也是一種常見的方式。

在這種模式下，將事務(wù)操作封裝成消息發(fā)送到消息隊(duì)列，然后由消息隊(duì)列來確保消息的可靠傳遞和處理。

如下圖所示：

圖片

消費(fèi)者服務(wù)接收到消息后執(zhí)行相應(yīng)的操作，保證了數(shù)據(jù)的一致性，常用的消息隊(duì)列包括：RabbitMQ、Apache Kafka等。