分佈式事務的四種解決方案

簡述

分佈式事務指事務的操作位於不同的節點上，需要保證事務的 AICD 特性。

例如在下單場景下，庫存和訂單如果不在同一個節點上，就涉及分佈式事務。

解決方案

在分佈式系統中，要實現分佈式事務，無外乎那幾種解決方案。

一、兩階段提交（2PC）

兩階段提交（Two-phase Commit，2PC），通過引入協調者（Coordinator）來協調參與者的行爲，並最終決定這些參與者是否要真正執行事務。

1. 運行過程

1.1 準備階段

協調者詢問參與者事務是否執行成功，參與者發回事務執行結果。

1.2 提交階段

如果事務在每個參與者上都執行成功，事務協調者發送通知讓參與者提交事務；否則，協調者發送通知讓參與者回滾事務。

需要注意的是，在準備階段，參與者執行了事務，但是還未提交。只有在提交階段接收到協調者發來的通知後，才進行提交或者回滾。

2. 存在的問題

2.1 同步阻塞所有事務參與者在等待其它參與者響應的時候都處於同步阻塞狀態，無法進行其它操作。

2.2 單點問題協調者在 2PC 中起到非常大的作用，發生故障將會造成很大影響。特別是在階段二發生故障，所有參與者會一直等待狀態，無法完成其它操作。

2.3 數據不一致在階段二，如果協調者只發送了部分 Commit 消息，此時網絡發生異常，那麼只有部分參與者接收到 Commit 消息，也就是說只有部分參與者提交了事務，使得系統數據不一致。

2.4 太過保守任意一個節點失敗就會導致整個事務失敗，沒有完善的容錯機制。

二、補償事務（TCC）

TCC 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。它分爲三個階段：

Try 階段主要是對業務系統做檢測及資源預留
Confirm 階段主要是對業務系統做確認提交，Try 階段執行成功並開始執行 Confirm 階段時，默認 Confirm 階段是不會出錯的。即：只要 Try 成功，Confirm 一定成功。
Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。

舉個例子，假入 Bob 要向 Smith 轉賬，思路大概是：我們有一個本地方法，裏面依次調用

首先在 Try 階段，要先調用遠程接口把 Smith 和 Bob 的錢給凍結起來。
在 Confirm 階段，執行遠程調用的轉賬的操作，轉賬成功進行解凍。
如果第 2 步執行成功，那麼轉賬成功，如果第二步執行失敗，則調用遠程凍結接口對應的解凍方法 (Cancel)。

優點：跟 2PC 比起來，實現以及流程相對簡單了一些，但數據的一致性比 2PC 也要差一些

缺點：缺點還是比較明顯的，在 2,3 步中都有可能失敗。TCC 屬於應用層的一種補償方式，所以需要程序員在實現的時候多寫很多補償的代碼，在一些場景中，一些業務流程可能用 TCC 不太好定義及處理。

三、本地消息表（異步確保）

本地消息表與業務數據表處於同一個數據庫中，這樣就能利用本地事務來保證在對這兩個表的操作滿足事務特性，並且使用了消息隊列來保證最終一致性。

在分佈式事務操作的一方完成寫業務數據的操作之後向本地消息表發送一個消息，本地事務能保證這個消息一定會被寫入本地消息表中。
之後將本地消息表中的消息轉發到 Kafka 等消息隊列中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。
在分佈式事務操作的另一方從消息隊列中讀取一個消息，並執行消息中的操作。

優點：一種非常經典的實現，避免了分佈式事務，實現了最終一致性。

缺點：消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。

四、MQ 事務消息

有一些第三方的 MQ 是支持事務消息的，比如 RocketMQ，他們支持事務消息的方式也是類似於採用的二階段提交，但是市面上一些主流的 MQ 都是不支持事務消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中間件爲例，其思路大致爲：

第一階段 Prepared 消息，會拿到消息的地址。第二階段執行本地事務，第三階段通過第一階段拿到的地址去訪問消息，並修改狀態。

也就是說在業務方法內要想消息隊列提交兩次請求，一次發送消息和一次確認消息。如果確認消息發送失敗了 RocketMQ 會定期掃描消息集羣中的事務消息，這時候發現了 Prepared 消息，它會向消息發送者確認，所以生產方需要實現一個 check 接口，RocketMQ 會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。

優點：實現了最終一致性，不需要依賴本地數據庫事務。

缺點：實現難度大，主流 MQ 不支持，RocketMQ 事務消息部分代碼也未開源。

總結

通過本文我們總結並對比了幾種分佈式分解方案的優缺點，分佈式事務本身是一個技術難題，是沒有一種完美的方案應對所有場景的，具體還是要根據業務場景去抉擇吧。阿里 RocketMQ 去實現的分佈式事務，現在也有除了很多分佈式事務的協調器，比如 LCN 等，大家可以多去嘗試。

轉載：https://www.cnblogs.com/mayundalao/p/11798502.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://www.cnblogs.com/wuwuyong/p/14346180.html

簡述