一、寫(xiě)在前面

?上一篇文章咱們聊了聊TCC分布式事務(wù)，對(duì)于常見(jiàn)的微服務(wù)系統(tǒng)，大部分接口調(diào)用是同步的，也就是一個(gè)服務(wù)直接調(diào)用另外一個(gè)服務(wù)的接口。

這個(gè)時(shí)候，用TCC分布式事務(wù)方案來(lái)保證各個(gè)接口的調(diào)用，要么一起成功，要么一起回滾，是比較合適的。

但是在實(shí)際系統(tǒng)的開(kāi)發(fā)過(guò)程中，可能服務(wù)間的調(diào)用是異步的。

也就是說(shuō)，一個(gè)服務(wù)發(fā)送一個(gè)消息給MQ，即消息中間件，比如RocketMQ、RabbitMQ、Kafka、ActiveMQ等等。

然后，另外一個(gè)服務(wù)從MQ消費(fèi)到一條消息后進(jìn)行處理。這就成了基于MQ的異步調(diào)用了。

那么針對(duì)這種基于MQ的異步調(diào)用，如何保證各個(gè)服務(wù)間的分布式事務(wù)呢？

也就是說(shuō)，我希望的是基于MQ實(shí)現(xiàn)異步調(diào)用的多個(gè)服務(wù)的業(yè)務(wù)邏輯，要么一起成功，要么一起失敗。

這個(gè)時(shí)候，就要用上可靠消息最終一致性方案，來(lái)實(shí)現(xiàn)分布式事務(wù)。?

大家看看上面那個(gè)圖，其實(shí)如果不考慮各種高并發(fā)、高可用等技術(shù)挑戰(zhàn)的話，單從“可靠消息”以及“最終一致性”兩個(gè)角度來(lái)考慮，這種分布式事務(wù)方案還是比較簡(jiǎn)單的。

二、可靠消息最終一致性方案的核心流程

1、上游服務(wù)投遞消息

如果要實(shí)現(xiàn)可靠消息最終一致性方案，一般你可以自己寫(xiě)一個(gè)可靠消息服務(wù)，實(shí)現(xiàn)一些業(yè)務(wù)邏輯。

首先，上游服務(wù)需要發(fā)送一條消息給可靠消息服務(wù)。

這條消息說(shuō)白了，你可以認(rèn)為是對(duì)下游服務(wù)一個(gè)接口的調(diào)用，里面包含了對(duì)應(yīng)的一些請(qǐng)求參數(shù)。

然后，可靠消息服務(wù)就得把這條消息存儲(chǔ)到自己的數(shù)據(jù)庫(kù)里去，狀態(tài)為“待確認(rèn)”。

接著，上游服務(wù)就可以執(zhí)行自己本地的數(shù)據(jù)庫(kù)操作，根據(jù)自己的執(zhí)行結(jié)果，再次調(diào)用可靠消息服務(wù)的接口。

如果本地?cái)?shù)據(jù)庫(kù)操作執(zhí)行成功了，那么就找可靠消息服務(wù)確認(rèn)那條消息。如果本地?cái)?shù)據(jù)庫(kù)操作失敗了，那么就找可靠消息服務(wù)刪除那條消息。

?此時(shí)如果是確認(rèn)消息，那么可靠消息服務(wù)就把數(shù)據(jù)庫(kù)里的消息狀態(tài)更新為“已發(fā)送”，同時(shí)將消息發(fā)送給MQ。

這里有一個(gè)很關(guān)鍵的點(diǎn)，就是更新數(shù)據(jù)庫(kù)里的消息狀態(tài)和投遞消息到MQ。這倆操作?，你得放在一個(gè)方法里，而且得開(kāi)啟本地事務(wù)。

啥意思呢？

• 如果數(shù)據(jù)庫(kù)里更新消息的狀態(tài)失敗了，那么就拋異常退出了，就別投遞到MQ；
• 如果投遞MQ失敗報(bào)錯(cuò)了，那么就要拋異常讓本地?cái)?shù)據(jù)庫(kù)事務(wù)回滾。
• 這倆操作必須得一起成功，或者一起失敗。

如果上游服務(wù)是通知?jiǎng)h除消息，那么可靠消息服務(wù)就得刪除這條消息。

2、下游服務(wù)接收消息

下游服務(wù)就一直等著從MQ消費(fèi)消息好了，如果消費(fèi)到了消息，那么就操作自己本地?cái)?shù)據(jù)庫(kù)。

如果操作成功了，就反過(guò)來(lái)通知可靠消息服務(wù)，說(shuō)自己處理成功了，然后可靠消息服務(wù)就會(huì)把消息的狀態(tài)設(shè)置為“已完成”。

3、如何上游服務(wù)對(duì)消息的100%可靠投遞？

上面的核心流程大家都看完：一個(gè)很大的問(wèn)題就是，如果在上述投遞消息的過(guò)程中各個(gè)環(huán)節(jié)出現(xiàn)了問(wèn)題該怎么辦？

我?們?nèi)绾伪ＷC消息100%的可靠投遞，一定會(huì)從上游服務(wù)投遞到下游服務(wù)？別著急，下面我們來(lái)逐一分析。

如果上游服務(wù)給可靠消息服務(wù)發(fā)送待確認(rèn)消息的過(guò)程出錯(cuò)了，那沒(méi)關(guān)系，上游服務(wù)可以感知到調(diào)用異常的，就不用執(zhí)行下面的流程了，這是沒(méi)問(wèn)題的。

如果上游服務(wù)操作完本地?cái)?shù)據(jù)庫(kù)之后，通知可靠消息服務(wù)確認(rèn)消息或者刪除消息的時(shí)候，出現(xiàn)了問(wèn)題。

比如：沒(méi)通知成功，或者沒(méi)執(zhí)行成功，或者是可靠消息服務(wù)沒(méi)成功的投遞消息到MQ。這一系列步驟出了問(wèn)題怎么辦？

其實(shí)也沒(méi)關(guān)系，因?yàn)樵谶@些情況下，那條消息在可靠消息服務(wù)的數(shù)據(jù)庫(kù)里的狀態(tài)會(huì)一直是“待確認(rèn)”。

此時(shí)，我們?cè)诳煽肯⒎?wù)里開(kāi)發(fā)一個(gè)后臺(tái)定時(shí)運(yùn)行的線程，不停的檢查各個(gè)消息的狀態(tài)。

如果一直是“待確認(rèn)”狀態(tài)，就認(rèn)為這個(gè)消息出了點(diǎn)什么問(wèn)題。

此時(shí)的話，就可以回調(diào)上游服務(wù)提供的一個(gè)接口，問(wèn)問(wèn)說(shuō)，兄弟，這個(gè)消息對(duì)應(yīng)的數(shù)據(jù)庫(kù)操作，你執(zhí)行成功了沒(méi)啊？

如果上游服務(wù)答復(fù)說(shuō)，我執(zhí)行成功了，那么可靠消息服務(wù)將消息狀態(tài)修改為“已發(fā)送”，同時(shí)投遞消息到MQ。

如果上游服務(wù)答復(fù)說(shuō)，沒(méi)執(zhí)行成功，那么可靠消息服務(wù)將數(shù)據(jù)庫(kù)中的消息刪除即可。

通過(guò)這套機(jī)制，就可以保證，可靠消息服務(wù)一定會(huì)嘗試完成消息到MQ的投遞。?

4、如何保證下游服務(wù)對(duì)消息的100%可靠接收？

?那如果下游服務(wù)消費(fèi)消息出了問(wèn)題，沒(méi)消費(fèi)到？或者是下游服務(wù)對(duì)消息的處理失敗了，怎么辦？

其實(shí)也沒(méi)關(guān)系，在可靠消息服務(wù)里開(kāi)發(fā)一個(gè)后臺(tái)線程，不斷的檢查消息狀態(tài)。

如果消息狀態(tài)一直是“已發(fā)送”，始終沒(méi)有變成“已完成”，那么就說(shuō)明下游服務(wù)始終沒(méi)有處理成功。

此時(shí)可靠消息服務(wù)就可以再次嘗試重新投遞消息到MQ，讓下游服務(wù)來(lái)再次處理。

只要下游服務(wù)的接口邏輯實(shí)現(xiàn)冪等性，保證多次處理一個(gè)消息，不會(huì)插入重復(fù)數(shù)據(jù)即可。?

5、如何基于RocketMQ來(lái)實(shí)現(xiàn)可靠消息最終一致性方案？

在上面的通用方案設(shè)計(jì)里，完全依賴可靠消息服務(wù)的各種自檢機(jī)制來(lái)確保：

• 如果上游服務(wù)的數(shù)據(jù)庫(kù)操作沒(méi)成功，下游服務(wù)是不會(huì)收到任何通知。
• 如果上游服務(wù)的數(shù)據(jù)庫(kù)操作成功了，可靠消息服務(wù)死活都會(huì)確保將一個(gè)調(diào)用消息投遞給下游服務(wù)，而且一定會(huì)確保下游服務(wù)務(wù)必成功處理這條消息。

通過(guò)這套機(jī)制，保證了基于MQ的異步調(diào)用/通知的服務(wù)間的分布式事務(wù)保障。

其實(shí)阿里開(kāi)源的RocketMQ，就實(shí)現(xiàn)了可靠消息服務(wù)的所有功能，核心思想跟上面類似。

只不過(guò)RocketMQ為了保證高并發(fā)、高可用、高性能，做了較為復(fù)雜的架構(gòu)實(shí)現(xiàn)，非常的優(yōu)秀。

有興趣的同學(xué)，自己可以去查閱RocketMQ對(duì)分布式事務(wù)的支持。

三、可靠消息最終一致性方案的高可用保障生產(chǎn)實(shí)踐

1、背景引入

?其實(shí)上面那套方案和思想，很多同學(xué)應(yīng)該都知道是怎么回事兒，我們也主要就是鋪墊一下這套理論思想。

在實(shí)際落地生產(chǎn)的時(shí)候，如果沒(méi)有高并發(fā)場(chǎng)景的，完全可以參照上面的思路自己基于某個(gè)MQ中間件開(kāi)發(fā)一個(gè)可靠消息服務(wù)。

如果有高并發(fā)場(chǎng)景的，可以用RocketMQ的分布式事務(wù)支持，上面的那套流程都可以實(shí)現(xiàn)。

今天給大家分享的一個(gè)核心主題，就是這套方案如何保證99.99%的高可用。

其實(shí)大家應(yīng)該發(fā)現(xiàn)了這套方案里保障高可用性最大的一個(gè)依賴點(diǎn)，就是MQ的高可用性。

任何一種MQ中間件都有一整套的高可用保障機(jī)制，無(wú)論是RabbitMQ、RocketMQ還是Kafka。

所以在大公司里使用可靠消息最終一致性方案的時(shí)候，我們通常對(duì)可用性的保障都是依賴于公司基礎(chǔ)架構(gòu)團(tuán)隊(duì)對(duì)MQ的高可用保障。

也就是說(shuō)，大家應(yīng)該相信兄弟團(tuán)隊(duì)，99.99%可以保障MQ的高可用，絕對(duì)不會(huì)因?yàn)镸Q集群整體宕機(jī)，而導(dǎo)致公司業(yè)務(wù)系統(tǒng)的分布式事務(wù)全部無(wú)法運(yùn)行。

但是現(xiàn)實(shí)是很殘酷的，很多中小型的公司，甚至是一些中大型公司，或多或少都遇到過(guò)MQ集群整體故障的場(chǎng)景。

MQ一旦完全不可用，就會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)的各個(gè)服務(wù)之間無(wú)法通過(guò)MQ來(lái)投遞消息，導(dǎo)致業(yè)務(wù)流程中斷。

比如最近就有一個(gè)朋友的公司，也是做電商業(yè)務(wù)的，就遇到了MQ中間件在自己公司機(jī)器上部署的集群整體故障不可用，導(dǎo)致依賴MQ的分布式事務(wù)全部無(wú)法跑通，業(yè)務(wù)流程大量中斷的情況。?

這種情況，就需要針對(duì)這套分布式事務(wù)方案實(shí)現(xiàn)一套高可用保障機(jī)制。

2、基于KV存儲(chǔ)的隊(duì)列支持的高可用降級(jí)方案

大家來(lái)看看下面這張圖，這是我曾經(jīng)指導(dǎo)過(guò)朋友的一個(gè)公司針對(duì)可靠消息最終一致性方案設(shè)計(jì)的一套高可用保障降級(jí)機(jī)制。

這套機(jī)制不算太復(fù)雜，可以非常簡(jiǎn)單有效的保證那位朋友公司的高可用保障場(chǎng)景，一旦MQ中間件出現(xiàn)故障，立馬自動(dòng)降級(jí)為備用方案。

（1）自行封裝MQ客戶端組件與故障感知

首先第一點(diǎn)，你要做到自動(dòng)感知MQ的故障接著自動(dòng)完成降級(jí)，那么必須動(dòng)手對(duì)MQ客戶端進(jìn)行封裝，發(fā)布到公司Nexus私服上去。

然后公司需要支持MQ降級(jí)的業(yè)務(wù)服務(wù)都使用這個(gè)自己封裝的組件來(lái)發(fā)送消息到MQ，以及從MQ消費(fèi)消息。

在你自己封裝的MQ客戶端組件里，你可以根據(jù)寫(xiě)入MQ的情況來(lái)判斷MQ是否故障。

比如說(shuō)，如果連續(xù)10次重試嘗試投遞消息到MQ都發(fā)現(xiàn)異常報(bào)錯(cuò)，網(wǎng)絡(luò)無(wú)法聯(lián)通等問(wèn)題，說(shuō)明MQ故障，此時(shí)就可以自動(dòng)感知以及自動(dòng)觸發(fā)降級(jí)開(kāi)關(guān)。

（2）基于kv存儲(chǔ)中隊(duì)列的降級(jí)方案

如果MQ掛掉之后，要是希望繼續(xù)投遞消息，那么就必須得找一個(gè)MQ的替代品。

舉個(gè)例子，比如我那位朋友的公司是沒(méi)有高并發(fā)場(chǎng)景的，消息的量很少，只不過(guò)可用性要求高。此時(shí)就可以類似redis的kv存儲(chǔ)中的隊(duì)列來(lái)進(jìn)行替代。

由于redis本身就支持隊(duì)列的功能，還有類似隊(duì)列的各種數(shù)據(jù)結(jié)構(gòu)，所以你可以將消息寫(xiě)入kv存儲(chǔ)格式的隊(duì)列數(shù)據(jù)結(jié)構(gòu)中去。

ps：關(guān)于redis的數(shù)據(jù)存儲(chǔ)格式、支持的數(shù)據(jù)結(jié)構(gòu)等基礎(chǔ)知識(shí)，請(qǐng)大家自行查閱了，網(wǎng)上一大堆

但是，這里有幾個(gè)大坑，一定要注意一下。

第一個(gè)，任何kv存儲(chǔ)的集合類數(shù)據(jù)結(jié)構(gòu)，建議不要往里面寫(xiě)入數(shù)據(jù)量過(guò)大，否則會(huì)導(dǎo)致大value的情況發(fā)生，引發(fā)嚴(yán)重的后果。

因此絕不能在redis里搞一個(gè)key，就拼命往這個(gè)數(shù)據(jù)結(jié)構(gòu)中一直寫(xiě)入消息，這是肯定不行的。

第二個(gè)，絕對(duì)不能往少數(shù)key對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中持續(xù)寫(xiě)入數(shù)據(jù)，那樣會(huì)導(dǎo)致熱key的產(chǎn)生，也就是某幾個(gè)key特別熱。

大家要知道，一般kv集群，都是根據(jù)key來(lái)hash分配到各個(gè)機(jī)器上的，你要是老寫(xiě)少數(shù)幾個(gè)key，會(huì)導(dǎo)致kv集群中的某臺(tái)機(jī)器訪問(wèn)過(guò)高，負(fù)載過(guò)大。

基于以上考慮，下面是筆者當(dāng)時(shí)設(shè)計(jì)的方案：

• 根據(jù)他們每天的消息量，在kv存儲(chǔ)中固定劃分上百個(gè)隊(duì)列，有上百個(gè)key對(duì)應(yīng)。
• 這樣保證每個(gè)key對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中不會(huì)寫(xiě)入過(guò)多的消息，而且不會(huì)頻繁的寫(xiě)少數(shù)幾個(gè)key。
• 一旦發(fā)生了MQ故障，可靠消息服務(wù)可以對(duì)每個(gè)消息通過(guò)hash算法，均勻的寫(xiě)入固定好的上百個(gè)key對(duì)應(yīng)的kv存儲(chǔ)的隊(duì)列中。

同時(shí)此時(shí)需要通過(guò)zk觸發(fā)一個(gè)降級(jí)開(kāi)關(guān)，整個(gè)系統(tǒng)在MQ這塊的讀和寫(xiě)全部立馬降級(jí)。

（3）下游服務(wù)消費(fèi)MQ的降級(jí)感知

下游服務(wù)消費(fèi)MQ也是通過(guò)自行封裝的組件來(lái)做的，此時(shí)那個(gè)組件如果從zk感知到降級(jí)開(kāi)關(guān)打開(kāi)了，首先會(huì)判斷自己是否還能繼續(xù)從MQ消費(fèi)到數(shù)據(jù)？

如果不能了，就開(kāi)啟多個(gè)線程，并發(fā)的從kv存儲(chǔ)的各個(gè)預(yù)設(shè)好的上百個(gè)隊(duì)列中不斷的獲取數(shù)據(jù)。

每次獲取到一條數(shù)據(jù)，就交給下游服務(wù)的業(yè)務(wù)邏輯來(lái)執(zhí)行。

通過(guò)這套機(jī)制，就實(shí)現(xiàn)了MQ故障時(shí)候的自動(dòng)故障感知，以及自動(dòng)降級(jí)。如果系統(tǒng)的負(fù)載和并發(fā)不是很高的話，用這套方案大致是沒(méi)沒(méi)問(wèn)題的。

因?yàn)樵谏a(chǎn)落地的過(guò)程中，包括大量的容災(zāi)演練以及生產(chǎn)實(shí)際故障發(fā)生時(shí)的表現(xiàn)來(lái)看，都是可以有效的保證MQ故障時(shí)，業(yè)務(wù)流程繼續(xù)自動(dòng)運(yùn)行的。

（4）故障的自動(dòng)恢復(fù)

如果降級(jí)開(kāi)關(guān)打開(kāi)之后，自行封裝的組件需要開(kāi)啟一個(gè)線程，每隔一段時(shí)間嘗試給MQ投遞一個(gè)消息看看是否恢復(fù)了。

如果MQ已經(jīng)恢復(fù)可以正常投遞消息了，此時(shí)就可以通過(guò)zk關(guān)閉降級(jí)開(kāi)關(guān)，然后可靠消息服務(wù)繼續(xù)投遞消息到MQ，下游服務(wù)在確認(rèn)kv存儲(chǔ)的各個(gè)隊(duì)列中已經(jīng)沒(méi)有數(shù)據(jù)之后，就可以重新切換為從MQ消費(fèi)消息。

（5）更多的業(yè)務(wù)細(xì)節(jié)

其實(shí)上面說(shuō)的那套方案主要是一套通用的降級(jí)方案，但是具體的落地是要結(jié)合各個(gè)公司不同的業(yè)務(wù)細(xì)節(jié)來(lái)決定的，很多細(xì)節(jié)多沒(méi)法在文章里體現(xiàn)。

比如說(shuō)你們要不要保證消息的順序性？是不是涉及到需要根據(jù)業(yè)務(wù)動(dòng)態(tài)，生成大量的key？等等。

此外，這套方案實(shí)現(xiàn)起來(lái)還是有一定的成本的，所以建議大家盡可能還是push公司的基礎(chǔ)架構(gòu)團(tuán)隊(duì)，保證MQ的99.99%可用性，不要宕機(jī)。

其次就是根據(jù)大家公司的實(shí)際對(duì)高可用需求來(lái)決定，如果感覺(jué)MQ偶爾宕機(jī)也沒(méi)事，可以容忍的話，那么也不用實(shí)現(xiàn)這種降級(jí)方案。

但是如果公司領(lǐng)導(dǎo)認(rèn)為MQ中間件宕機(jī)后，一定要保證業(yè)務(wù)系統(tǒng)流程繼續(xù)運(yùn)行，那么還是要考慮一些高可用的降級(jí)方案，比如本文提到的這種。

最后再說(shuō)一句，真要是一些公司涉及到每秒幾萬(wàn)幾十萬(wàn)的高并發(fā)請(qǐng)求，那么對(duì)MQ的降級(jí)方案會(huì)設(shè)計(jì)的更加的復(fù)雜，那就遠(yuǎn)遠(yuǎn)不是這么簡(jiǎn)單可以做到的。