突破Java面試(44)-分布式事務解決方案0

Github

1 面試題

分布式事務了解嗎？你們如何解決分布式事務問題的？

2 考點分析

隻要聊到做了分布式系統，必問分布式事務，若你對分布式事務一無所知的話，确實很坑，起碼得知道有哪些方案，一般怎麼來做，每個方案的優缺點是什麼。

現在面試，分布式系統成了标配，而分布式系統帶來的分布式事務也成了标配.

你做系統肯定要用事務，那你用事務的話，分布式系統之後肯定要用分布式事務.

先不說你搞過沒有，起碼你得明白有哪幾種方案，每種方案可能有啥坑？比如TCC方案的網絡問題、XA方案的一緻性問題

• 單塊系統裡的事務
• 分布式系統裡的事務

3 XA方案也叫做兩階段送出事務方案.

舉個例子，比如公司經常團建，然後一般會有個主席（就是負責組織團建的那個人）。

tb，team building，團建

• 第一個階段，一般tb主席會提前問團隊裡的每個人，說，大家夥，下周六我們去滑雪+燒烤，去嗎？
  • 這個時候tb主席開始等待每個人的回答，如果所有人都說ok，那麼就可以決定一起去這次tb
  • 如果這個階段裡，任何一個人回答說，我有事不去了，那麼tb主席就會取消這次活動
• 第二個階段，那下周六大家就一起去滑雪+燒烤了

這就是所謂的XA事務，兩階段送出

有一個事務管理器，負責協調多個資料庫（資料總管）的事務，事務管理器先問各個資料庫你準備好了嗎？

• 如果每個資料庫都回複ok，那麼就正式送出事務，在各個資料庫上執行操作
• 任何一個資料庫回答不ok，那麼就復原事務。

這種分布式事務方案，比較适合單塊應用中，跨多個庫的分布式事務，而且因為嚴重依賴于資料庫層面來搞定複雜的事務，效率很低，絕對不适合高并發場景

如果要玩，那麼基于Spring + JTA就可以搞定，自己随便搜個demo看看~

這個方案，很少用，一般某個系統内部如果出現跨多個庫的操作，是不合規的!

現在的微服務，一個大的系統分成幾十甚至上百個服務。一般來說，我們的規約，是要求每個服務隻能操作自己對應的一個資料庫!

如果你要操作别的服務對應的庫，不允許直連别的服務的庫，違反微服務架構的規範

你随便交叉通路，幾百個服務的話，全體亂套，這樣的一套服務是沒法管理的，會經常資料被别人改錯，自己的庫被别人寫挂!

如果你要操作别人的服務的庫，你必須通過調用别的服務的接口實作，絕對不允許你交叉通路别人的資料庫！

• 兩階段送出方案示意圖

4 TCC方案

全稱:Try、Confirm、Cancel

4.1 三個階段

4.1.1 Try

對各個服務的資源做檢測,對資源進行鎖定或者預留

4.1.2 Confirm

在各個服務中執行實際的操作

4.1.3 Cancel

如果任何一個服務的業務方法執行出錯，那麼這裡就需要進行補償，即執行已操作成功的業務邏輯的復原操作

4.2 跨銀行轉賬案例

涉及到兩個銀行的分布式事務，如果用TCC方案來實作，思路是這樣的：

• Try階段

  先把兩個銀行賬戶中的資金給它當機住,不讓操作了

• Confirm階段

  執行實際的轉賬操作，A銀行賬戶的資金扣減，B銀行賬戶的資金增加

• Cancel階段

  如果任何一個銀行的操作執行失敗，那麼就需要復原進行補償

比如A銀行賬戶如果已經扣減了，但是B銀行賬戶資金增加失敗了，那麼就得把A銀行賬戶資金給加回去

該方案說實話幾乎很少使用，但也有使用場景.

因為這個事務的復原實際上嚴重依賴于你自己寫代碼來復原和補償了，會造成補償代碼巨大，非常惡心!

比如說我們，一般來說和錢相關的支付、交易等相關的場景，我們會用TCC，嚴格嚴格保證分布式事務要麼全部成功，要麼全部自動復原，嚴格保證資金的正确性!

4.3 适用場景

除非你是真的一緻性要求太高，是系統中核心之核心的場景!

常見的就是資金類的場景，那可以用TCC方案，自己編寫大量的業務邏輯，自己判斷一個事務中的各個環節是否ok，不ok就執行補償/復原代碼

而且最好是你的各個業務執行的時間都比較短

但是說實話，一般盡量别這麼搞，自己手寫復原邏輯，或者是補償邏輯，實在太惡心了，業務代碼也很難維護

• TCC方案

5 本地消息表

ebay搞出來的這麼一套思想

5.1 簡介

• A系統在本地一個事務裡操作的同時，插入一條資料到消息表
• 接着A系統将這個消息發送到MQ
• B系統接收到消息後，在一個事務裡，往自己本地消息表裡插入一條資料，同時執行其他的業務操作，如果這個消息已經被處理過了，那麼此時這個事務會復原，這樣保證不會重複處理消息
• B系統執行成功後，就會更新自己本地消息表的狀态以及A系統消息表的狀态
• 如果B系統處理失敗，那麼就不會更新消息表狀态，那麼此時A系統會定時掃描自己的消息表，如果有未處理的消息，會再次發送到MQ中去，讓B再處理

5.2 優點

這個方案保證了最終一緻性

哪怕B事務失敗了，但是A會不斷重發消息，直到B那邊成功為止

5.3 缺陷

最大的問題就在于嚴重依賴于資料庫的消息表來管理事務,這個會導緻高并發場景無力,難以擴充呢,一般确實很少用

• 本地消息表方案

6 可靠消息最終一緻性方案

幹脆不用本地的消息表了，直接基于MQ來實作事務。比如阿裡的RocketMQ就支援消息事務!

6.1 簡介

• A系統先發送一個prepared消息到MQ，如果這個prepared消息發送失敗,那麼就直接取消操作,不執行了
• 如果這個消息發送成功過了，那麼接着執行本地事務，如果成功就告訴MQ發送确認消息，如果失敗就告訴MQ復原消息
• 如果發送了确認消息，那麼此時B系統會接收到确認消息，然後執行本地的事務

• MQ會自動定時輪詢所有prepared消息回調你的接口，問你這個消息是不是本地事務處理失敗了，所有沒發送确認的消息,是繼續重試還是復原？

  這裡你就可以查下資料庫看之前本地事務是否執行，如果復原了，那麼這裡也復原吧。這個就是避免可能本地事務執行成功了，别确認消息發送失敗了。

• 如果系統B的事務失敗了咋辦？

  重試咯，自動不斷重試直到成功，如果實在是不行，要麼就是針對重要的資金類業務進行復原，比如B系統本地復原後，想辦法通知系統A也復原；或者是發送報警由人工來手工復原和補償

這個還是比較合适的，目前國内網際網路公司大都是這麼玩的，要不你舉用RocketMQ支援的，要不你就自己基于類似ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的

• 可靠消息最終一緻性方案

7 最大努力通知方案

7.1 簡介

• 系統A本地事務執行完後，發送一個消息到MQ
• 有一專門消費MQ的最大努力通知服務，會消費MQ,然後寫入資料庫中記錄下來，亦可是放入記憶體隊列，接着調用系統B的接口
• 若系統B執行成功就ok；若系統B執行失敗，那麼最大努力通知服務就定時嘗試重新調用系統B，反複N次，最後還是不行才放棄
• 最大努力通知方案示意圖

8 總結

你們公司是如何處理分布式事務的呢?歡迎評論交流!

講真的，該突破面試教程沒法帶着大家實戰，因為定位不是這個.

如果你真的被問到，你可以這麼說，我們某某特别嚴格的場景，用的是TCC來保證強一緻性；然後其他的一些場景基于了阿裡的RocketMQ來實作了分布式事務~

你找一個嚴格資金要求絕對不能錯的場景，你可以說你是用的TCC方案

如果是一般的分布式事務場景，訂單插入之後要調用庫存服務更新庫存，庫存資料沒有資金那麼的敏感，可以用可靠消息最終一緻性方案

Rocketmq 3.2.6之前的版本，是可以按照上面的思路來的，但是之後接口做了一些改變，不再贅述,歡迎關注後續筆者的RocketMQ實戰系列

當然如果你願意，你可以參考可靠消息最終一緻性方案來自己實作一套分布式事務，比如基于RabbitMQ來玩兒。

你其實用任何一個分布式事務的這麼一個方案，都會導緻你那塊兒代碼會複雜10倍。很多情況下，系統A調用系統B、系統C、系統D，我們可能根本就不做分布式事務。如果調用報錯會列印異常日志。

每個月也就那麼幾個bug，很多bug是功能性的，體驗性的，真的是涉及到資料層面的一些bug，一個月就幾個，兩三個？如果你為了確定系統自動保證資料100%不能錯，上了幾十個分布式事務，代碼太複雜；性能太差，系統吞吐量、性能大幅度下跌。

99%的分布式接口調用，不要做分布式事務，直接就是監控（發郵件、發短信）、記錄日志（一旦出錯，完整的日志）、事後快速的定位、排查和出解決方案、修複資料。

每個月，每隔幾個月，都會對少量的因為代碼bug，導緻出錯的資料，進行人工的修複資料，自己臨時動手寫個程式，可能要補一些資料，可能要删除一些資料，可能要修改一些字段的值。

比你做50個分布式事務，成本要來的低上百倍，低幾十倍

trade off，權衡，要用分布式事務的時候，一定是有成本，代碼會很複雜，開發很長時間，性能和吞吐量下跌，系統更加複雜更加脆弱反而更加容易出bug；好處，如果做好了，TCC、可靠消息最終一緻性方案，一定可以100%保證你那快資料不會出錯。

1%，0.1%，0.01%的業務，資金、交易、訂單，我們會用分布式事務方案來保證，會員積分、優惠券、商品資訊，其實不要這麼搞了

參考

• 《Java工程師面試突擊第1季-中華石杉老師》