0 Github

1 面試題

分布式事務(wù)了解嗎？你們?nèi)绾谓鉀Q分布式事務(wù)問題的？

2 考點分析

只要聊到做了分布式系統(tǒng)，必問分布式事務(wù)，若你對分布式事務(wù)一無所知的話，確實很坑，起碼得知道有哪些方案，一般怎么來做，每個方案的優(yōu)缺點是什么。

現(xiàn)在面試，分布式系統(tǒng)成了標(biāo)配，而分布式系統(tǒng)帶來的分布式事務(wù)也成了標(biāo)配.

你做系統(tǒng)肯定要用事務(wù)，那你用事務(wù)的話，分布式系統(tǒng)之后肯定要用分布式事務(wù).

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

• 單塊系統(tǒng)里的事務(wù)

  
  
  image

• 分布式系統(tǒng)里的事務(wù)

  
  
  image

3 XA方案也叫做兩階段提交事務(wù)方案.

舉個例子，比如公司經(jīng)常團(tuán)建，然后一般會有個主席（就是負(fù)責(zé)組織團(tuán)建的那個人）。

tb，team building，團(tuán)建

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

這就是所謂的XA事務(wù)，兩階段提交

有一個事務(wù)管理器，負(fù)責(zé)協(xié)調(diào)多個數(shù)據(jù)庫（資源管理器）的事務(wù)，事務(wù)管理器先問各個數(shù)據(jù)庫你準(zhǔn)備好了嗎？

• 如果每個數(shù)據(jù)庫都回復(fù)ok，那么就正式提交事務(wù)，在各個數(shù)據(jù)庫上執(zhí)行操作
• 任何一個數(shù)據(jù)庫回答不ok，那么就回滾事務(wù)。

這種分布式事務(wù)方案，比較適合單塊應(yīng)用中，跨多個庫的分布式事務(wù)，而且因為嚴(yán)重依賴于數(shù)據(jù)庫層面來搞定復(fù)雜的事務(wù)，效率很低，絕對不適合高并發(fā)場景

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

這個方案，很少用，一般某個系統(tǒng)內(nèi)部如果出現(xiàn)跨多個庫的操作，是不合規(guī)的!

現(xiàn)在的微服務(wù)，一個大的系統(tǒng)分成幾十甚至上百個服務(wù)。一般來說，我們的規(guī)約，是要求每個服務(wù)只能操作自己對應(yīng)的一個數(shù)據(jù)庫!

如果你要操作別的服務(wù)對應(yīng)的庫，不允許直連別的服務(wù)的庫，違反微服務(wù)架構(gòu)的規(guī)范

你隨便交叉訪問，幾百個服務(wù)的話，全體亂套，這樣的一套服務(wù)是沒法管理的，會經(jīng)常數(shù)據(jù)被別人改錯，自己的庫被別人寫掛!

如果你要操作別人的服務(wù)的庫，你必須通過調(diào)用別的服務(wù)的接口實現(xiàn)，絕對不允許你交叉訪問別人的數(shù)據(jù)庫！

• 兩階段提交方案示意圖

  
  
  image

4 TCC方案

全稱:Try、Confirm、Cancel

4.1 三個階段

4.1.1 Try

對各個服務(wù)的資源做檢測,對資源進(jìn)行鎖定或者預(yù)留

4.1.2 Confirm

在各個服務(wù)中執(zhí)行實際的操作

4.1.3 Cancel

如果任何一個服務(wù)的業(yè)務(wù)方法執(zhí)行出錯，那么這里就需要進(jìn)行補償，即執(zhí)行已操作成功的業(yè)務(wù)邏輯的回滾操作

4.2 跨銀行轉(zhuǎn)賬案例

涉及到兩個銀行的分布式事務(wù)，如果用TCC方案來實現(xiàn)，思路是這樣的：

• Try階段
  先把兩個銀行賬戶中的資金給它凍結(jié)住,不讓操作了
• Confirm階段
  執(zhí)行實際的轉(zhuǎn)賬操作，A銀行賬戶的資金扣減，B銀行賬戶的資金增加
• Cancel階段
  如果任何一個銀行的操作執(zhí)行失敗，那么就需要回滾進(jìn)行補償
  比如A銀行賬戶如果已經(jīng)扣減了，但是B銀行賬戶資金增加失敗了，那么就得把A銀行賬戶資金給加回去

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

因為這個事務(wù)的回滾實際上嚴(yán)重依賴于你自己寫代碼來回滾和補償了，會造成補償代碼巨大，非常惡心!

比如說我們，一般來說和錢相關(guān)的支付、交易等相關(guān)的場景，我們會用TCC，嚴(yán)格嚴(yán)格保證分布式事務(wù)要么全部成功，要么全部自動回滾，嚴(yán)格保證資金的正確性!

4.3 適用場景

除非你是真的一致性要求太高，是系統(tǒng)中核心之核心的場景!

常見的就是資金類的場景，那可以用TCC方案，自己編寫大量的業(yè)務(wù)邏輯，自己判斷一個事務(wù)中的各個環(huán)節(jié)是否ok，不ok就執(zhí)行補償/回滾代碼

而且最好是你的各個業(yè)務(wù)執(zhí)行的時間都比較短

但是說實話，一般盡量別這么搞，自己手寫回滾邏輯，或者是補償邏輯，實在太惡心了，業(yè)務(wù)代碼也很難維護(hù)

• TCC方案

  
  
  image

5 本地消息表

ebay搞出來的這么一套思想

5.1 簡介

• A系統(tǒng)在本地一個事務(wù)里操作的同時，插入一條數(shù)據(jù)到消息表
• 接著A系統(tǒng)將這個消息發(fā)送到MQ
• B系統(tǒng)接收到消息后，在一個事務(wù)里，往自己本地消息表里插入一條數(shù)據(jù)，同時執(zhí)行其他的業(yè)務(wù)操作，如果這個消息已經(jīng)被處理過了，那么此時這個事務(wù)會回滾，這樣保證不會重復(fù)處理消息
• B系統(tǒng)執(zhí)行成功后，就會更新自己本地消息表的狀態(tài)以及A系統(tǒng)消息表的狀態(tài)
• 如果B系統(tǒng)處理失敗，那么就不會更新消息表狀態(tài)，那么此時A系統(tǒng)會定時掃描自己的消息表，如果有未處理的消息，會再次發(fā)送到MQ中去，讓B再處理

5.2 優(yōu)點

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

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

5.3 缺陷

最大的問題就在于嚴(yán)重依賴于數(shù)據(jù)庫的消息表來管理事務(wù),這個會導(dǎo)致高并發(fā)場景無力,難以擴展呢,一般確實很少用

• 本地消息表方案

  
  
  image

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

干脆不用本地的消息表了，直接基于MQ來實現(xiàn)事務(wù)。比如阿里的RocketMQ就支持消息事務(wù)!

6.1 簡介

• A系統(tǒng)先發(fā)送一個prepared消息到MQ，如果這個prepared消息發(fā)送失敗,那么就直接取消操作,不執(zhí)行了
• 如果這個消息發(fā)送成功過了，那么接著執(zhí)行本地事務(wù)，如果成功就告訴MQ發(fā)送確認(rèn)消息，如果失敗就告訴MQ回滾消息
• 如果發(fā)送了確認(rèn)消息，那么此時B系統(tǒng)會接收到確認(rèn)消息，然后執(zhí)行本地的事務(wù)
• MQ會自動定時輪詢所有prepared消息回調(diào)你的接口，問你這個消息是不是本地事務(wù)處理失敗了，所有沒發(fā)送確認(rèn)的消息,是繼續(xù)重試還是回滾？
  這里你就可以查下數(shù)據(jù)庫看之前本地事務(wù)是否執(zhí)行，如果回滾了，那么這里也回滾吧。這個就是避免可能本地事務(wù)執(zhí)行成功了，別確認(rèn)消息發(fā)送失敗了。
• 如果系統(tǒng)B的事務(wù)失敗了咋辦？
  重試咯，自動不斷重試直到成功，如果實在是不行，要么就是針對重要的資金類業(yè)務(wù)進(jìn)行回滾，比如B系統(tǒng)本地回滾后，想辦法通知系統(tǒng)A也回滾；或者是發(fā)送報警由人工來手工回滾和補償

這個還是比較合適的，目前國內(nèi)互聯(lián)網(wǎng)公司大都是這么玩的，要不你舉用RocketMQ支持的，要不你就自己基于類似ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的

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

image

7 最大努力通知方案

7.1 簡介

• 系統(tǒng)A本地事務(wù)執(zhí)行完后，發(fā)送一個消息到MQ
• 有一專門消費MQ的最大努力通知服務(wù)，會消費MQ,然后寫入數(shù)據(jù)庫中記錄下來，亦可是放入內(nèi)存隊列，接著調(diào)用系統(tǒng)B的接口
• 若系統(tǒng)B執(zhí)行成功就ok；若系統(tǒng)B執(zhí)行失敗，那么最大努力通知服務(wù)就定時嘗試重新調(diào)用系統(tǒng)B，反復(fù)N次，最后還是不行才放棄

• 最大努力通知方案示意圖
  image

8 總結(jié)

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

講真的，該突破面試教程沒法帶著大家實戰(zhàn)，因為定位不是這個.

如果你真的被問到，你可以這么說，我們某某特別嚴(yán)格的場景，用的是TCC來保證強一致性；然后其他的一些場景基于了阿里的RocketMQ來實現(xiàn)了分布式事務(wù)~

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

如果是一般的分布式事務(wù)場景，訂單插入之后要調(diào)用庫存服務(wù)更新庫存，庫存數(shù)據(jù)沒有資金那么的敏感，可以用可靠消息最終一致性方案

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

當(dāng)然如果你愿意，你可以參考可靠消息最終一致性方案來自己實現(xiàn)一套分布式事務(wù)，比如基于RabbitMQ來玩兒。

你其實用任何一個分布式事務(wù)的這么一個方案，都會導(dǎo)致你那塊兒代碼會復(fù)雜10倍。很多情況下，系統(tǒng)A調(diào)用系統(tǒng)B、系統(tǒng)C、系統(tǒng)D，我們可能根本就不做分布式事務(wù)。如果調(diào)用報錯會打印異常日志。

每個月也就那么幾個bug，很多bug是功能性的，體驗性的，真的是涉及到數(shù)據(jù)層面的一些bug，一個月就幾個，兩三個？如果你為了確保系統(tǒng)自動保證數(shù)據(jù)100%不能錯，上了幾十個分布式事務(wù)，代碼太復(fù)雜；性能太差，系統(tǒng)吞吐量、性能大幅度下跌。

99%的分布式接口調(diào)用，不要做分布式事務(wù)，直接就是監(jiān)控（發(fā)郵件、發(fā)短信）、記錄日志（一旦出錯，完整的日志）、事后快速的定位、排查和出解決方案、修復(fù)數(shù)據(jù)。

每個月，每隔幾個月，都會對少量的因為代碼bug，導(dǎo)致出錯的數(shù)據(jù)，進(jìn)行人工的修復(fù)數(shù)據(jù)，自己臨時動手寫個程序，可能要補一些數(shù)據(jù)，可能要刪除一些數(shù)據(jù)，可能要修改一些字段的值。

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

trade off，權(quán)衡，要用分布式事務(wù)的時候，一定是有成本，代碼會很復(fù)雜，開發(fā)很長時間，性能和吞吐量下跌，系統(tǒng)更加復(fù)雜更加脆弱反而更加容易出bug；好處，如果做好了，TCC、可靠消息最終一致性方案，一定可以100%保證你那快數(shù)據(jù)不會出錯。

1%，0.1%，0.01%的業(yè)務(wù)，資金、交易、訂單，我們會用分布式事務(wù)方案來保證，會員積分、優(yōu)惠券、商品信息，其實不要這么搞了

參考

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