分布式事務

標簽：比較   分布式事務   基本原理   概念   ref   缺點   ring   自己的   pre   

分布式事務的實現主要有以下 6 種方案：

• XA 方案
• TCC 方案
• SAGA 方案
• 本地消息表
• 可靠消息最終一致性方案
• 最大努力通知方案

兩階段提交方案/XA 方案

所謂的 XA 方案，即：兩階段提交，有一個事務管理器的概念，負責協調多個數據庫（資源管理器）的事務，事務管理器先問問各個數據庫你準備好了嗎？如果每個數據庫都回復 ok，那么就正式提交事務，在各個數據庫上執行操作；如果任何其中一個數據庫回答不 ok，那么就回滾事務。

這種分布式事務方案，比較適合單塊應用里，跨多個庫的分布式事務，而且因為嚴重依賴于數據庫層面來搞定復雜的事務，效率很低，絕對不適合高并發的場景。如果要玩兒，那么基于 Spring + JTA 就可以搞定，自己隨便搜個 demo 看看就知道了。

這個方案，我們很少用，一般來說某個系統內部如果出現跨多個庫的這么一個操作，是不合規的。我可以給大家介紹一下， 現在微服務，一個大的系統分成幾十個甚至幾百個服務。一般來說，我們的規定和規范，是要求每個服務只能操作自己對應的一個數據庫。

如果你要操作別的服務對應的庫，不允許直連別的服務的庫，違反微服務架構的規范，你隨便交叉胡亂訪問，幾百個服務的話，全體亂套，這樣的一套服務是沒法管理的，沒法治理的，可能會出現數據被別人改錯，自己的庫被別人寫掛等情況。

如果你要操作別人的服務的庫，你必須是通過調用別的服務的接口來實現，絕對不允許交叉訪問別人的數據庫。

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 模式要求的三個接口。

優勢

• 一階段提交本地事務，無鎖，高性能；
• 參與者可異步執行，高吞吐；
• 補償服務易于實現，因為一個更新操作的反向操作是比較容易理解的。

缺點

• 不保證事務的隔離性。

本地消息表

本地消息表其實是國外的 ebay 搞出來的這么一套思想。

這個大概意思是這樣的：

1. A 系統在自己本地一個事務里操作同時，插入一條數據到消息表；
2. 接著 A 系統將這個消息發送到 MQ 中去；
3. B 系統接收到消息之后，在一個事務里，往自己本地消息表里插入一條數據，同時執行其他的業務操作，如果這個消息已經被處理過了，那么此時這個事務會回滾，這樣保證不會重復處理消息；
4. B 系統執行成功之后，就會更新自己本地消息表的狀態以及 A 系統消息表的狀態；
5. 如果 B 系統處理失敗了，那么就不會更新消息表狀態，那么此時 A 系統會定時掃描自己的消息表，如果有未處理的消息，會再次發送到 MQ 中去，讓 B 再次處理；
6. 這個方案保證了最終一致性，哪怕 B 事務失敗了，但是 A 會不斷重發消息，直到 B 那邊成功為止。

這個方案說實話最大的問題就在于嚴重依賴于數據庫的消息表來管理事務啥的，如果是高并發場景咋辦呢？咋擴展呢？所以一般確實很少用。

可靠消息最終一致性方案

這個的意思，就是干脆不要用本地的消息表了，直接基于 MQ 來實現事務。比如阿里的 RocketMQ 就支持消息事務。

大概的意思就是：

1. A 系統先發送一個 prepared 消息到 mq，如果這個 prepared 消息發送失敗那么就直接取消操作別執行了；
2. 如果這個消息發送成功過了，那么接著執行本地事務，如果成功就告訴 mq 發送確認消息，如果失敗就告訴 mq 回滾消息；
3. 如果發送了確認消息，那么此時 B 系統會接收到確認消息，然后執行本地的事務；
4. mq 會自動定時輪詢所有 prepared 消息回調你的接口，問你，這個消息是不是本地事務處理失敗了，所有沒發送確認的消息，是繼續重試還是回滾？一般來說這里你就可以查下數據庫看之前本地事務是否執行，如果回滾了，那么這里也回滾吧。這個就是避免可能本地事務執行成功了，而確認消息卻發送失敗了。
5. 這個方案里，要是系統 B 的事務失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要么就是針對重要的資金類業務進行回滾，比如 B 系統本地回滾后，想辦法通知系統 A 也回滾；或者是發送報警由人工來手工回滾和補償。
6. 這個還是比較合適的，目前國內互聯網公司大都是這么玩兒的，要不你就用 RocketMQ 支持的，要不你就自己基于類似 ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。

最大努力通知方案

這個方案的大致意思就是：

1. 系統 A 本地事務執行完之后，發送個消息到 MQ；
2. 這里會有個專門消費 MQ 的最大努力通知服務，這個服務會消費 MQ 然后寫入數據庫中記錄下來，或者是放入個內存隊列也可以，接著調用系統 B 的接口；
3. 要是系統 B 執行成功就 ok 了；要是系統 B 執行失敗了，那么最大努力通知服務就定時嘗試重新調用系統 B，反復 N 次，最后還是不行就放棄。

分布式事務

標簽：比較   分布式事務   基本原理   概念   ref   缺點   ring   自己的   pre   

原文地址：https://www.cnblogs.com/caicz/p/15075052.html