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

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

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

　　二. 解決思路

　　2.1 思路一

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

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

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

　　2.2 思路二

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

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

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

　　三. 問題復(fù)現(xiàn)

　　我們先來看看如下代碼：

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

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

　　四. 實(shí)現(xiàn)原理

　　原理分析

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

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

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

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

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

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

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

　　回查本地事務(wù);

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

　　實(shí)現(xiàn)代碼

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

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

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

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

　　ROLLBACK_MESSAGE：回滾。表示該消息將被刪除，消費(fèi)者不能消費(fèi)這個(gè)消息;

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

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

　　五. 注意事項(xiàng)

　　我們?cè)谑褂肦ocketMQ的時(shí)候，要注意以下兩個(gè)配置參數(shù)。

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

　　transactionCheckMax=N

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

　　默認(rèn)為 60s transactionCheckInterval=5000

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