猿創征文｜分布式事務常見解決方案

分布式事務有哪些解決方案

1、基于XA協定的：兩階段送出和三階段送出，需要資料庫層面支援

2、基于事務補償機制的：TCC，基于業務層面實作

3、本地消息表：基于本地資料庫+mq，維護本地狀态（進行中），通過mq調用服務，完成後響應一條消

息回調，将狀态改成完成。需要配合定時任務掃表、重新發送消息調用服務，需要保證幂等

4、基于事務消息：mq

相比兩階段，三階段有哪些改進

兩階段協定

第一階段（ prepare ） ：每個參與者執行本地事務但不送出，進入 ready 狀态，并通知協調者已經準

備就緒。

第二階段（ commit ） 當協調者确認每個參與者都 ready 後，通知參與者進行 commit 操作；如果有

參與者 fail ，則發送 rollback 指令，各參與者做復原。

問題

• 單點故障：一旦事務管理器出現故障，整個系統不可用（參與者都會阻塞住）

• 資料不一緻：在階段二，如果事務管理器隻發送了部分 commit 消息，此時網絡發生異常，那麼

  隻有部分參與者接收到 commit 消息，也就是說隻有部分參與者送出了事務，使得系統資料不一

  緻。

• 響應時間較長：參與者和協調者資源都被鎖住，送出或者復原之後才能釋放

• 不确定性：當協事務管理器發送 commit 之後，并且此時隻有一個參與者收到了 commit，那麼當

  該參與者與事務管理器同時當機之後，重新選舉的事務管理器無法确定該條消息是否送出成功。

三階段協定

主要是針對兩階段的優化，解決了2PC單點故障的問題，但是性能問題和不一緻問題仍然

沒有根本解決

引入了逾時機制解決參與者阻塞的問題，逾時後本地送出，2pc隻有協調者有逾時機制

• 第一階段：CanCommit階段，協調者詢問事務參與者，是否有能力完成此次事務。

  如果都傳回yes，則進入第二階段

  有一個傳回no或等待響應逾時，則中斷事務，并向所有參與者發送abort請求

• 第二階段：PreCommit階段，此時協調者會向所有的參與者發送PreCommit請求，參與者收到後

  開始執行事務操作。參與者執行完事務操作後（此時屬于未送出事務的狀态），就會向協調者回報

  “Ack”表示我已經準備好送出了，并等待協調者的下一步指令。

• 第三階段：DoCommit階段， 在階段二中如果所有的參與者節點都傳回了Ack，那麼協調者就會從

  “預送出狀态”轉變為“送出狀态”。然後向所有的參與者節點發送"doCommit"請求，參與者節點在

  收到送出請求後就會各自執行事務送出操作，并向協調者節點回報“Ack”消息，協調者收到所有參

  與者的Ack消息後完成事務。 相反，如果有一個參與者節點未完成PreCommit的回報或者回報超

  時，那麼協調者都會向所有的參與者節點發送abort請求，進而中斷事務。

TCC事務模型

TCC（補償事務）：Try、Confirm、Cancel

針對每個操作，都要注冊一個與其對應的确認和補償（撤銷）操作

Try操作做業務檢查及資源預留，Confirm做業務确認操作，Cancel實作一個與Try相反的操作既復原操

作。

TM首先發起所有的分支事務的try操作，任何一個分支事務的try操作執行失敗，TM将會發起所有

分支事務的Cancel操作，若try操作全部成功，TM将會發起所有分支事務的Confirm操作，其中

Confirm/Cancel操作若執行失敗，TM會進行重試。