分布式事務是非常核心的分布式系統，也是大廠經常考察對象，下面我就重點詳解分布式事務及原理實現@mikechen

分布式事務

分布式事務指的是涉及多個獨立服務的操作，這些服務可能分布在不同的節點、主機甚至不同的數據中心中。

如下圖所示：

圖片

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

分布式事務的目標是確保跨多個服務的一系列操作要么全部成功，要么全部回滾，以保持數據的一致性和完整性。

分布式事務的關鍵問題是如何協調和管理多個服務之間的事務狀態，以保證最終的一致性。

分布式事務實現方案

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

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

2PC是一種經典的分布式事務協議，在2PC中一個事務協調器（Transaction Coordinator）負責協調多個參與者（Participants）的操作。

2PC協議分為兩個階段：準備階段和提交階段。

圖片

第一階段：prepare

每個參與者執行本地事務但不提交，進入 ready 狀態，并通知協調者已經準 備就緒。

第二階段：commit

當協調者確認每個參與者都 ready 后，通知參與者進行 commit 操作，如果有 參與者 fail ，則發送 rollback 命令，各參與者做回滾。

2.TCC（Try-Confirm-Cancel）

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

圖片

第一階段：CanCommit階段

協調者向參與者發送CanCommit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。

第二階段：PreCommit階段

協調者根據參與者的反應情況來決定是否可以繼續事務的PreCommit操作。

第三階段：DoCommit階段

協調者基于每個參與者PreCommit階段的反饋結果，決定真正提交事務，還是中斷事務。

當一個事務涉及多個服務時，每個服務的Try操作會執行一系列預操作，如果所有服務的Try操作都成功，則執行Confirm操作，否則執行Cancel操作來回滾之前的操作。

TCC模式需要開發人員手動實現事務的補償邏輯，適用于一些需要自定義補償邏輯的場景。

3.消息隊列

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

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

如下圖所示：

圖片

消費者服務接收到消息后執行相應的操作，保證了數據的一致性，常用的消息隊列包括：RabbitMQ、Apache Kafka等。