面試題

分布式事務(wù)了解嗎忽妒？你們是如何解決分布式事務(wù)問題的？

面試官心理分析

只要聊到你做了分布式系統(tǒng)，必問分布式事務(wù)段直，你對(duì)分布式事務(wù)一無所知的話吃溅，確實(shí)會(huì)很坑，你起碼得知道有哪些方案鸯檬，一般怎么來做决侈，每個(gè)方案的優(yōu)缺點(diǎn)是什么。

現(xiàn)在面試喧务，分布式系統(tǒng)成了標(biāo)配赖歌，而分布式系統(tǒng)帶來的分布式事務(wù)也成了標(biāo)配了。因?yàn)槟阕鱿到y(tǒng)肯定要用事務(wù)吧功茴，如果是分布式系統(tǒng)庐冯，肯定要用分布式事務(wù)吧。先不說你搞過沒有坎穿，起碼你得明白有哪幾種方案展父，每種方案可能有啥坑？比如 TCC 方案的網(wǎng)絡(luò)問題玲昧、XA 方案的一致性問題栖茉。

面試題剖析

分布式事務(wù)的實(shí)現(xiàn)主要有以下 5 種方案：

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

兩階段提交方案/XA方案

所謂的 XA 方案，即：兩階段提交孵延，有一個(gè)事務(wù)管理器的概念吕漂，負(fù)責(zé)協(xié)調(diào)多個(gè)數(shù)據(jù)庫（資源管理器）的事務(wù)，事務(wù)管理器先問問各個(gè)數(shù)據(jù)庫你準(zhǔn)備好了嗎尘应？如果每個(gè)數(shù)據(jù)庫都回復(fù) ok惶凝，那么就正式提交事務(wù)，在各個(gè)數(shù)據(jù)庫上執(zhí)行操作菩收；如果任何其中一個(gè)數(shù)據(jù)庫回答不 ok梨睁，那么就回滾事務(wù)鲸睛。

這種分布式事務(wù)方案娜饵，比較適合單塊應(yīng)用里，跨多個(gè)庫的分布式事務(wù)官辈，而且因?yàn)閲?yán)重依賴于數(shù)據(jù)庫層面來搞定復(fù)雜的事務(wù)箱舞，效率很低，絕對(duì)不適合高并發(fā)的場(chǎng)景拳亿。如果要玩兒晴股，那么基于 Spring + JTA 就可以搞定，自己隨便搜個(gè) demo 看看就知道了肺魁。

這個(gè)方案电湘，我們很少用，一般來說某個(gè)系統(tǒng)內(nèi)部如果出現(xiàn)跨多個(gè)庫的這么一個(gè)操作，是不合規(guī)的寂呛。我可以給大家介紹一下怎诫， 現(xiàn)在微服務(wù)，一個(gè)大的系統(tǒng)分成幾十個(gè)甚至幾百個(gè)服務(wù)贷痪。一般來說幻妓，我們的規(guī)定和規(guī)范，是要求每個(gè)服務(wù)只能操作自己對(duì)應(yīng)的一個(gè)數(shù)據(jù)庫劫拢。

如果你要操作別的服務(wù)對(duì)應(yīng)的庫肉津，不允許直連別的服務(wù)的庫，違反微服務(wù)架構(gòu)的規(guī)范舱沧，你隨便交叉胡亂訪問妹沙，幾百個(gè)服務(wù)的話，全體亂套熟吏，這樣的一套服務(wù)是沒法管理的初烘，沒法治理的，可能會(huì)出現(xiàn)數(shù)據(jù)被別人改錯(cuò)分俯，自己的庫被別人寫掛等情況肾筐。

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

image

TCC 方案

TCC 的全稱是：Try、Confirm杏节、Cancel唬渗。

Try 階段：這個(gè)階段說的是對(duì)各個(gè)服務(wù)的資源做檢測(cè)以及對(duì)資源進(jìn)行鎖定或者預(yù)留。
Confirm 階段：這個(gè)階段說的是在各個(gè)服務(wù)中執(zhí)行實(shí)際的操作奋渔。
Cancel 階段：如果任何一個(gè)服務(wù)的業(yè)務(wù)方法執(zhí)行出錯(cuò)镊逝，那么這里就需要進(jìn)行補(bǔ)償，就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務(wù)邏輯的回滾操作嫉鲸。（把那些執(zhí)行成功的回滾）
這種方案說實(shí)話幾乎很少人使用撑蒜，我們用的也比較少，但是也有使用的場(chǎng)景玄渗。因?yàn)檫@個(gè)事務(wù)回滾實(shí)際上是嚴(yán)重依賴于你自己寫代碼來回滾和補(bǔ)償了座菠，會(huì)造成補(bǔ)償代碼巨大，非常之惡心藤树。

比如說我們浴滴，一般來說跟錢相關(guān)的，跟錢打交道的岁钓，支付升略、交易相關(guān)的場(chǎng)景微王，我們會(huì)用 TCC，嚴(yán)格保證分布式事務(wù)要么全部成功品嚣，要么全部自動(dòng)回滾骂远，嚴(yán)格保證資金的正確性，保證在資金上不會(huì)出現(xiàn)問題腰根。

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

但是說實(shí)話，一般盡量別這么搞额嘿，自己手寫回滾邏輯瘸恼，或者是補(bǔ)償邏輯，實(shí)在太惡心了册养，那個(gè)業(yè)務(wù)代碼是很難維護(hù)的东帅。

image

本地消息表

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

這個(gè)大概意思是這樣的：

A 系統(tǒng)在自己本地一個(gè)事務(wù)里操作同時(shí)球拦，插入一條數(shù)據(jù)到消息表靠闭；
接著 A 系統(tǒng)將這個(gè)消息發(fā)送到 MQ 中去；
B 系統(tǒng)接收到消息之后坎炼，在一個(gè)事務(wù)里愧膀，往自己本地消息表里插入一條數(shù)據(jù)，同時(shí)執(zhí)行其他的業(yè)務(wù)操作谣光，如果這個(gè)消息已經(jīng)被處理過了檩淋，那么此時(shí)這個(gè)事務(wù)會(huì)回滾，這樣保證不會(huì)重復(fù)處理消息萄金；
B 系統(tǒng)執(zhí)行成功之后蟀悦，就會(huì)更新自己本地消息表的狀態(tài)以及 A 系統(tǒng)消息表的狀態(tài)；
如果 B 系統(tǒng)處理失敗了氧敢，那么就不會(huì)更新消息表狀態(tài)日戈，那么此時(shí) A 系統(tǒng)會(huì)定時(shí)掃描自己的消息表，如果有未處理的消息孙乖，會(huì)再次發(fā)送到 MQ 中去浙炼，讓 B 再次處理；
這個(gè)方案保證了最終一致性的圆，哪怕 B 事務(wù)失敗了鼓拧，但是 A 會(huì)不斷重發(fā)消息半火，直到 B 那邊成功為止越妈。
這個(gè)方案說實(shí)話最大的問題就在于嚴(yán)重依賴于數(shù)據(jù)庫的消息表來管理事務(wù)啥的，如果是高并發(fā)場(chǎng)景咋辦呢钮糖？咋擴(kuò)展呢梅掠？所以一般確實(shí)很少用酌住。

image

可靠消息最終一致性方案

這個(gè)的意思，就是干脆不要用本地的消息表了阎抒，直接基于 MQ 來實(shí)現(xiàn)事務(wù)酪我。比如阿里的 RocketMQ 就支持消息事務(wù)。

大概的意思就是：

• A 系統(tǒng)先發(fā)送一個(gè) prepared 消息到 mq且叁，如果這個(gè) prepared 消息發(fā)送失敗那么就直接取消操作別執(zhí)行了都哭；
• 如果這個(gè)消息發(fā)送成功過了，那么接著執(zhí)行本地事務(wù)逞带，如果成功就告訴 mq 發(fā)送確認(rèn)消息欺矫，如果失敗就告訴 mq 回滾消息；
• 如果發(fā)送了確認(rèn)消息展氓，那么此時(shí) B 系統(tǒng)會(huì)接收到確認(rèn)消息穆趴，然后執(zhí)行本地的事務(wù)；
• mq 會(huì)自動(dòng)定時(shí)輪詢所有 prepared 消息回調(diào)你的接口遇汞，問你未妹，這個(gè)消息是不是本地事務(wù)處理失敗了，所有沒發(fā)送確認(rèn)的消息空入，是繼續(xù)重試還是回滾络它？一般來說這里你就可以查下數(shù)據(jù)庫看之前本地事務(wù)是否執(zhí)行，如果回滾了歪赢，那么這里也回滾吧酪耕。這個(gè)就是避免可能本地事務(wù)執(zhí)行成功了，而確認(rèn)消息卻發(fā)送失敗了轨淌。
• 這個(gè)方案里迂烁，要是系統(tǒng) B 的事務(wù)失敗了咋辦？重試咯递鹉，自動(dòng)不斷重試直到成功盟步，如果實(shí)在是不行，要么就是針對(duì)重要的資金類業(yè)務(wù)進(jìn)行回滾躏结，比如 B 系統(tǒng)本地回滾后却盘，想辦法通知系統(tǒng) A 也回滾；或者是發(fā)送報(bào)警由人工來手工回滾和補(bǔ)償媳拴。

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

最大努力通知方案

這個(gè)方案的大致意思就是：

• 系統(tǒng) A 本地事務(wù)執(zhí)行完之后小压，發(fā)送個(gè)消息到 MQ；
• 這里會(huì)有個(gè)專門消費(fèi) MQ 的最大努力通知服務(wù)椰于，這個(gè)服務(wù)會(huì)消費(fèi) MQ 然后寫入數(shù)據(jù)庫中記錄下來怠益，或者是放入個(gè)內(nèi)存隊(duì)列也可以，接著調(diào)用系統(tǒng) B 的接口瘾婿；
• 要是系統(tǒng) B 執(zhí)行成功就 ok 了蜻牢；要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時(shí)嘗試重新調(diào)用系統(tǒng) B偏陪，反復(fù) N 次孩饼，最后還是不行就放棄。

你們公司是如何處理分布式事務(wù)的竹挡？

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

你找一個(gè)嚴(yán)格資金要求絕對(duì)不能錯(cuò)的場(chǎng)景好啰，你可以說你是用的 TCC 方案轩娶；如果是一般的分布式事務(wù)場(chǎng)景，訂單插入之后要調(diào)用庫存服務(wù)更新庫存框往，庫存數(shù)據(jù)沒有資金那么的敏感鳄抒，可以用可靠消息最終一致性方案。

友情提示一下椰弊，RocketMQ 3.2.6 之前的版本许溅，是可以按照上面的思路來的，但是之后接口做了一些改變秉版，我這里不再贅述了贤重。

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