來源：llc687.top/120.html
XA/二階段提交
基於XA協議的二階段提交
所謂的 XA 方案，即：兩階段提交，有一個事務管理器 的概念，負責協調多個數據庫（資源管理器）的事務，事務管理器先問各個數據庫準備好了嗎？如果每個數據庫都回 ok，那就正式提交事務，在各個數據庫上執行操作；如果任何其中一個數據庫回答不 ok，那麼就回滾事務。這種分佈式事務方案，比較適合單塊應用裏，跨多個庫的分佈式事務，而且因爲嚴重依賴於數據庫層面來搞定複雜的事務，效率很低，不適合高併發的場景。
JTA
JTA只是Java實現XA事務的一個規範，全稱Java``事務規範JTA（Java Transaction API) ，我們日常使用的@Transactional。都可以叫JTA事務管理。實際上，JTA是基於XA架構上建模的，對於Spring來說，可以使用如JBoss之類的應用服務器提供的JTA事務管理器；可以以使用Atomikos、Bitronix等庫提供的JTA事務管理器。Spring都有封裝，開箱即用。
鏈式
對於Spring，還有個鏈式事務管理，就是聲明一個ChainedTransactionManager 將所有的數據源事務按順序放到該對象中，則事務會按相反的順序來執行事務。事務依次提交後提交的事務若出錯不能回滾。
1.start message transaction
2.receive message
3.start database transaction
4.update database
5.commit database transaction
6.commit message transaction ##當這一步出現錯誤時，上面的因爲已經commit，所以不會rollback
和JTA比起來，更輕量，但只能單機用。
參考
這個方案，很少用，一般來說某個系統內部如果出現跨多個庫 的這麼一個操作，是不合規 的。我可以給大家介紹一下， 現在微服務，一個大的系統分成幾十個甚至幾百個服務。一般來說，我們的規定和規範，是要求每個服務只能操作自己對應的一個數據庫 。如果你要操作別的服務對應的庫，不允許直連別的服務的庫，違反微服務架構的規範，你隨便交叉胡亂訪問，幾百個服務的話，全體亂套，這樣的一套服務是沒法管理的，沒法治理的，可能會出現數據被別人改錯，自己的庫被別人寫掛等情況。如果你要操作別人的服務的庫，你必須是通過調用別的服務的接口 來實現，絕對不允許交叉訪問別人的數據庫。
問題
-
同步阻塞問題 ：二階段提交算法在執行過程中，所有參與節點都是事務阻塞型的。也就是說，當本地資源管理器佔有臨界資源時，其他資源管理器如果要訪問同一臨界資源，會處於阻塞狀態。 -
單點故障問題： 基於 XA 的二階段提交算法類似於集中式算法，一旦事務管理器發生故障，整個系統都處於停滯狀態。尤其是在提交階段，一旦事務管理器發生故障，資源管理器會由於等待管理器的消息，而一直鎖定事務資源，導致整個系統被阻塞。 -
數據不一致問題： 在提交階段，當協調者向參與者發送 DoCommit 請求之後，如果發生了局部網絡異常，或者在發送提交請求的過程中協調者發生了故障，就會導致只有一部分參與者接收到了提交請求並執行提交操作，但其他未接到提交請求的那部分參與者則無法執行事務提交。於是整個分佈式系統便出現了數據不一致的問題。
3PC
三階段提交協議（Three-phase commit protocol，3PC），是對二階段提交（2PC）的改進。爲了解決兩階段提交的同步阻塞和數據不一致問題，三階段提交引入了超時機制和準備階段 。
-
同時在協調者和參與者中引入超時機制。如果協調者或參與者在規定的時間內沒有接收到來自其他節點的響應，就會根據當前的狀態選擇提交或者終止整個事務。 -
在第一階段和第二階段中間引入了一個準備階段，也就是在提交階段之前，加入了一個預提交階段。在預提交階段排除一些不一致的情況，保證在最後提交之前各參與節點的狀態是一致的。
也就是說，除了引入超時機制之外，3PC 把 2PC 的提交階段一分爲二，這樣三階段提交協議就有 CanCommit、PreCommit、DoCommit 三個階段。
canCommit
precommit
-
如果所有參與者回覆的都是“Yes”，那麼協調者就會執行事務的預執行： -
發送預提交請求。 協調者向參與者發送 PreCommit 請求，進入預提交階段。 -
事務預提交 。參與者接收到 PreCommit 請求後執行事務操作，並將 Undo 和 Redo 信息記錄到事務日誌中。 -
響應反饋 。如果參與者成功執行了事務操作，則返回 ACK 響應，同時開始等待最終指令。 -
假如任何一個參與者向協調者發送了“No”消息，或者等待超時之後，協調者都沒有收到參與者的響應，就執行中斷事務的操作： -
發送中斷請求 。協調者向所有參與者發送“Abort”消息。 -
終斷事務 。參與者收到“Abort”消息之後，或超時後仍未收到協調者的消息，執行事務的終斷操作。
doCommit
DoCmmit 階段進行真正的事務提交，根據 PreCommit 階段協調者發送的消息，進入執行提交階段或事務中斷階段。
-
執行提交階段： -
發送提交請求。協調者接收到所有參與者發送的 Ack 響應，從預提交狀態進入到提交狀態，並向所有參與者發送 DoCommit 消息。 -
事務提交。參與者接收到 DoCommit 消息之後，正式提交事務。完成事務提交之後，釋放所有鎖住的資源。 -
響應反饋。參與者提交完事務之後，向協調者發送 Ack 響應。 -
完成事務。協調者接收到所有參與者的 Ack 響應之後，完成事務。 -
事務中斷階段： -
發送中斷請求。協調者向所有參與者發送 Abort 請求。 -
事務回滾。參與者接收到 Abort 消息之後，利用其在 PreCommit 階段記錄的 Undo 信息執行事務的回滾操作，並釋放所有鎖住的資源。 -
反饋結果。參與者完成事務回滾之後，向協調者發送 Ack 消息。
)
TCC
TCC 的全稱是：Try 、 Confirm 、 Cancel 。
-
Try 階段：這個階段說的是對各個服務的資源做檢測以及對資源進行 鎖定或者預留 。 -
Confirm 階段：這個階段說的是在各個服務中 執行實際的操作 。 -
Cancel 階段：如果任何一個服務的業務方法執行出錯，那麼這裏就需要 進行補償 ，就是執行已經執行成功的業務邏輯的回滾操作。
這種方案說實話幾乎很少人使用。因爲這個事務回滾 實際上是嚴重依賴於你自己寫代碼來回滾和補償 了，會造成補償代碼巨大，非常之噁心。等於一個藉口拆成三個。一般來說跟錢 相關的，支付 、交易 ，會用 TCC，嚴格保證分佈式事務要麼全部成功，要麼全部自動回滾，嚴格保證資金正確。而且最好是各個業務執行的時間都比較短。
Saga
金融核心等業務可能會選擇 TCC 方案，以追求強一致性和更高的併發量，而對於更多的金融核心以下的業務系統 往往會選擇補償事務，補償事務處理在 30 多年前就提出了 Saga 理論，隨着微服務的發展，近些年才逐步受到大家的關注。目前業界比較公認的是採用 Saga 作爲長事務的解決方案。
基本原理
業務流程中每個參與者都提交本地事務，若某一個參與者失敗，則補償前面已經成功的參與者。下圖左側是正常的事務流程，當執行到 T3 時發生了錯誤，則開始執行右邊的事務補償流程，反向執行 T3、T2、T1 的補償服務 C3、C2、C1，將 T3、T2、T1 已經修改的數據補償掉。
使用場景
對於一致性要求高、短流程、併發高 的場景，如：金融核心系統，會優先考慮 TCC 方案。而在另外一些場景下，我們並不需要這麼強的一致性，只需要保證最終一致性即可。比如 很多金融核心以上的業務（渠道層、產品層、系統集成層），這些系統的特點是最終一致即可、流程多、流程長、還可能要調用其它公司的服務。這種情況如果選擇 TCC 方案開發的話，一來成本高，二來無法要求其它公司的服務也遵循 TCC 模式。同時流程長，事務邊界太長，加鎖時間長，也會影響併發性能。所以 Saga 模式的適用場景是：
-
業務流程長、業務流程多； -
參與者包含其它公司或遺留系統服務，無法提供 TCC 模式要求的三個接口。
優勢
-
一階段提交本地事務，無鎖，高性能； -
參與者可異步執行，高吞吐； -
補償服務易於實現，因爲一個更新操作的反向操作是比較容易理解的。
缺點
-
不保證事務的隔離性。
可靠消息最終一致性
流程
-
A 系統先發送一個 prepared 消息到 mq，如果這個 prepared 消息發送失敗那麼就直接取消操作別執行了； -
如果這個消息發送成功過了，那麼接着執行本地事務，如果成功就告訴 mq 發送確認消息，如果失敗就告訴 mq 回滾消息； -
如果發送了確認消息，那麼此時 B 系統會接收到確認消息，然後執行本地的事務； -
mq 會自動 定時輪詢 所有 prepared 消息回調你的接口，問你，這個消息是不是本地事務處理失敗了，所有沒發送確認的消息，是繼續重試還是回滾？一般來說這裏你就可以查下數據庫看之前本地事務是否執行，如果回滾了，那麼這裏也回滾吧。這個就是避免可能本地事務執行成功了，而確認消息卻發送失敗了。 -
這個方案裏，要是系統 B 的事務失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要麼就是針對重要的資金類業務進行回滾，比如 B 系統本地回滾後，想辦法通知系統 A 也回滾；或者是發送報警由人工來手工回滾和補償。 -
這個還是比較合適的，目前國內互聯網公司大都是這麼玩兒的，要不你就用 RocketMQ 支持的，要不你就自己基於類似 ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。
下單爲例
以下單爲例
-
訂單系統把訂單消息發給消息中間件，消息狀態標記爲“待確認”。 -
消息中間件收到消息後，進行消息持久化操作，即在消息存儲系統中新增一條狀態爲“待發送”的消息。 -
消息中間件返回消息持久化結果（成功 / 失敗），訂單系統根據返回結果判斷如何進行業務操作。失敗，放棄訂單，結束（必要時向上層返回失敗結果）；成功，則創建訂單。 -
訂單操作完成後，把操作結果（成功 / 失敗）發送給消息中間件。 -
消息中間件收到業務操作結果後，根據結果進行處理：失敗，刪除消息存儲中的消息，結束；成功，則更新消息存儲中的消息狀態爲“待發送（可發送）”，並執行消息投遞。 -
如果消息狀態爲“可發送”，則 MQ 會將消息發送給支付系統，表示已經創建好訂單，需要對訂單進行支付。支付系統也按照上述方式進行訂單支付操作。 -
訂單系統支付完成後，會將支付消息返回給消息中間件，中間件將消息傳送給訂單系統。訂單系統再調用庫存系統，進行出貨操作。
最大努力通知方案
這個方案的大致意思就是：
-
系統 A 本地事務執行完之後，發送個消息到 MQ； -
這裏會有個專門消費 MQ 的 最大努力通知服務 ，這個服務會消費 MQ 然後寫入數據庫中記錄下來，或者是放入個內存隊列也可以，接着調用系統 B 的接口； -
要是系統 B 執行成功就 ok 了；要是系統 B 執行失敗了，那麼最大努力通知服務就定時嘗試重新調用系統 B，反覆 N 次，最後還是不行就放棄。
總結
一般來說，最嚴格的就是TCC。其他常用的是基於消息的最終一致性。
ACID
Base理論
BASE 理論包括基本可用（Basically Available）、柔性狀態（Soft State）和最終一致性（Eventual Consistency）。
-
基本可用：分佈式系統出現故障的時候，允許損失一部分功能的可用性。比如，某些電商 618 大促的時候，會對一些非核心鏈路的功能進行降級處理。 -
柔性狀態：在柔性事務中，允許系統存在中間狀態，且這個中間狀態不會影響系統整體可用性。比如，數據庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會有一個延時，其實就是一種柔性狀態。 -
最終一致性：事務在操作過程中可能會由於同步延遲等問題導致不一致，但最終狀態下，數據都是一致的。
可見，BASE 理論爲了支持大型分佈式系統，通過犧牲強一致性，保證最終一致性，來獲得高可用性，是對 ACID 原則的弱化。具體到今天的三種分佈式事務實現方式，二階段提交、三階段提交方法，遵循的是 ACID 原則，而消息最終一致性方案遵循的就是 BASE 理論。
往期推薦
本文分享自微信公衆號 - 俠夢的開發筆記（xmdevnote）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。