一. 業(yè)務(wù)場景

　　大家好，我是千鋒，今天和大家分享一個關(guān)于RocketMQ的面試題——“RocketMQ事務(wù)消息”。

　　在給面試官講解這個問題之前，你可以先設(shè)計一個業(yè)務(wù)場景，越真實越好，越貼近生產(chǎn)越好，如果沒有生產(chǎn)案例，可以直接列舉電商中大家都容易懂的業(yè)務(wù)場景。比如，在分布式場景中用戶取消訂單，增加用戶賬戶余額。這個業(yè)務(wù)簡單易懂，業(yè)務(wù)大致流程是兩個服務(wù)協(xié)同完成業(yè)務(wù)，訂單服務(wù)取消訂單，賬戶服務(wù)新增用戶賬戶余額。場景有了，那接下來咱們就可以跟面試官溝通怎么解決，把思路分析清楚。

　　二. 解決思路

　　2.1 思路一

　　在分布式場景中，我們可以通過遠程調(diào)用協(xié)議(RPC/HTTP)來完成服務(wù)間的遠程調(diào)用，如果我們使用的是Dubbo、HSF、GRPC 等技術(shù)方案，那么使用RPC協(xié)議就可以完成服務(wù)間遠程調(diào)用;如果使用的是SpringCloud技術(shù)方案，那么可以通過Openfeign(底層http協(xié)議)來完成服務(wù)間遠程調(diào)用。具體實現(xiàn)流程如下圖：

　　在分布式場景中，數(shù)據(jù)一致性是我們必須要面對的問題。在分布式項目中，保證數(shù)據(jù)的一致性，我們不能用本地事務(wù)的思維去解決，必須采用分布式事務(wù)的解決方案。

　　在這里千鋒給大家推薦阿里的生產(chǎn)實踐方案seata，至于seata具體是怎么實現(xiàn)的，解決原理是什么，我這里就不給大家詳細說明了，我們的線下課程中有詳細的講解。

　　2.2 思路二

　　其實思路一并不是在正面回答面試官的問題，只是說了業(yè)務(wù)的實現(xiàn)方案，我們講解思路一的目的是在告訴面試官，我知道什么是分布式事務(wù)，以及分布式事務(wù)應(yīng)該怎么去解決。而思路二則是正面去回答面試官的問題，比如上面說到的業(yè)務(wù)場景，我們還可以利用MQ的事務(wù)消息來解決。

　　那為什么要使用MQ呢? 這是因為MQ有解耦以及異步處理的特性。具體流程如下：

　　基于MQ實現(xiàn)分布式事務(wù)的大概思路是，當order服務(wù)取消訂單時，我們可以不用直接去調(diào)用賬戶服務(wù)。而是可以通過發(fā)送消息，然后賬戶服務(wù)監(jiān)聽消息隊列，賬戶服務(wù)收到消息時處理賬戶業(yè)務(wù)。這個實現(xiàn)思路其實很簡單，但要想落地實現(xiàn)卻沒那么簡單，我們必須要解決取消訂單與發(fā)送消息的一致性問題。試想一下，如果取消訂單失敗，結(jié)果消息發(fā)送成功;或者取消訂單成功，但發(fā)送消息失敗，那么就會導致數(shù)據(jù)的不一致問題。接下來千鋒就給大家簡單復現(xiàn)一下。

　　三. 問題復現(xiàn)

　　我們先來看看如下代碼：

　　如上代碼，當運行異常時，本地事務(wù)一定會回滾，但消息卻發(fā)送出去了，數(shù)據(jù)的一致性就得不到保證了。那該怎么解決呢?這時我們就可以采用事務(wù)消息了，事務(wù)消息就能解決這個問題!

　　接下來我們就可以跟面試官講解事務(wù)消息的具體實現(xiàn)過程，注意千鋒這里用的MQ是RocketMQ，大家也可以采用其他MQ產(chǎn)品，只要支持事務(wù)消息就可以。

　　四. 實現(xiàn)原理

　　原理分析

　　在展示具體實現(xiàn)代碼之前，千鋒先把MQ實現(xiàn)分布式事務(wù)的原理講解一下。

　　根據(jù)上圖，千鋒給大家梳理了RocketMQ實現(xiàn)分布式事務(wù)的流程原理，如下：

　　將發(fā)送消息的功能從業(yè)務(wù)中剝離出來。業(yè)務(wù)的第一步不是取消訂單操作，而是發(fā)送消息，當然這里發(fā)送消息只能是”半消息“，”半消息“的特點是消費者不能消費;

　　當broker收到”半消息“時會應(yīng)答生產(chǎn)者，生產(chǎn)者收到成功應(yīng)答后再執(zhí)行本地事務(wù);

　　執(zhí)行本地事務(wù)也就是取消訂單;

　　本地事務(wù)如果處理成功則提交消息。提交消息后，消息就可以入隊，消費者就可以消費消息。當然如果本地事務(wù)失敗，那么就回滾消息，消息就會被刪除，消費者也收不到消息;

　　如果不確定本地事務(wù)是否成功，我們可以進行本地事務(wù)回查;

　　回查本地事務(wù);

　　回查可以直接查詢數(shù)據(jù)庫，檢查本地事務(wù)是否成功，如果成功提交消息，否則回滾消息。

　　實現(xiàn)代碼

　　我們把上圖中展現(xiàn)的功能，在如下代碼中進行實現(xiàn)：

　　事務(wù)消息監(jiān)聽器

　　另外RocketMQ的事務(wù)消息是基于兩階段提交方案來實現(xiàn)的，也就是說消息會有兩個狀態(tài)，prepared和commited。當消息執(zhí)行完send方法后，進入到prepared狀態(tài)，然后就會執(zhí)行executeLocalTransaction方法，該方法的返回值有3個，這些返回值決定著該消息的命運。

　　COMMIT_MESSAGE：提交消息。表示該消息由prepared狀態(tài)進入到commited狀態(tài)，消費者可以消費這個消息;

　　ROLLBACK_MESSAGE：回滾。表示該消息將被刪除，消費者不能消費這個消息;

　　UNKNOW：未知。這個狀態(tài)有點意思，如果返回這個狀態(tài)，則表示該消息既不提交，也不回滾，還是保持prepared狀態(tài)。而最終決定這個消息命運的，是checkLocalTransaction這個方法。

　　事務(wù)監(jiān)聽器的實現(xiàn)代碼如下：

　　五. 注意事項

　　我們在使用RocketMQ的時候，要注意以下兩個配置參數(shù)。

　　事務(wù)消息最大反查次數(shù)

　　transactionCheckMax=N

　　事務(wù)消息檢查間隔時間

　　默認為 60s transactionCheckInterval=5000

　　好啦，關(guān)于RocketMQ的事務(wù)消息，今天就給大家分享到這里啦。