面試題：如何解決分佈式事務問題

面試題

分佈式事務瞭解嗎？大家是如何解決分佈式事務問題的？

面試官心理分析

只要聊到你作了分佈式系統，必問分佈式事務，你對分佈式事務一無所知的話，確實會很坑，你起碼得知道有哪些方案，通常怎麼來作，每一個方案的優缺點是什麼。

如今面試，分佈式系統成了標配，而分佈式系統帶來的分佈式事務也成了標配了。由於你作系統確定要用事務吧，若是是分佈式系統，確定要用分佈式事務吧。先不說你搞過沒有，起碼你得明白有哪幾種方案，每種方案可能有啥坑？好比 TCC 方案的網絡問題、XA 方案的一致性問題。

面試題剖析

分佈式事務的實現主要有如下 5 種方案：

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

兩階段提交方案/XA方案

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

這種分佈式事務方案，比較適合單塊應用裏，跨多個庫的分佈式事務，並且由於嚴重依賴於數據庫層面來搞定複雜的事務，效率很低，絕對不適合高併發的場景。若是要玩兒，那麼基於 Spring + JTA 就能夠搞定，本身隨便搜個 demo 看看就知道了。

這個方案，咱們不多用，通常來講某個系統內部若是出現跨多個庫的這麼一個操做，是不合規的。我能夠給你們介紹一下， 如今微服務，一個大的系統分紅幾十個甚至幾百個服務。通常來講，咱們的規定和規範，是要求每一個服務只能操做本身對應的一個數據庫。

若是你要操道別的服務對應的庫，不容許直連別的服務的庫，違反微服務架構的規範，你隨便交叉胡亂訪問，幾百個服務的話，全體亂套，這樣的一套服務是無法管理的，無法治理的，可能會出現數據被別人改錯，本身的庫被別人寫掛等狀況。

若是你要操道別人的服務的庫，你必須是經過調用別的服務的接口來實現，絕對不容許交叉訪問別人的數據庫。

TCC 方案

TCC 的全稱是：Try、Confirm、Cancel。

• Try 階段：這個階段說的是對各個服務的資源作檢測以及對資源進行鎖定或者預留。
• Confirm 階段：這個階段說的是在各個服務中執行實際的操做。
• Cancel 階段：若是任何一個服務的業務方法執行出錯，那麼這裏就須要進行補償，就是執行已經執行成功的業務邏輯的回滾操做。（把那些執行成功的回滾）

這種方案說實話幾乎不多人使用，咱們用的也比較少，可是也有使用的場景。由於這個事務回滾其實是嚴重依賴於你本身寫代碼來回滾和補償了，會形成補償代碼巨大，很是之噁心。

好比說咱們，通常來講跟錢相關的，跟錢打交道的，支付、交易相關的場景，咱們會用 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 次，最後仍是不行就放棄。

大家公司是如何處理分佈式事務的？

若是你真的被問到，能夠這麼說，咱們某某特別嚴格的場景，用的是 TCC 來保證強一致性；而後其餘的一些場景基於阿里的 RocketMQ 來實現分佈式事務。

你找一個嚴格資金要求絕對不能錯的場景，你能夠說你是用的 TCC 方案；若是是通常的分佈式事務場景，訂單插入以後要調用庫存服務更新庫存，庫存數據沒有資金那麼的敏感，能夠用可靠消息最終一致性方案。

友情提示一下，RocketMQ 3.2.6 以前的版本，是能夠按照上面的思路來的，可是以後接口作了一些改變，我這裏再也不贅述了。

固然若是你願意，你能夠參考可靠消息最終一致性方案來本身實現一套分佈式事務，好比基於 RocketMQ 來玩兒。