一、業(yè)務(wù)場景介紹

咱們先來看看業(yè)務(wù)場景，假設(shè)你現(xiàn)在有一個電商系統(tǒng)，里面有一個支付訂單的場景。

那對一個訂單支付之后，我們需要做下面的步驟：

更改訂單的狀態(tài)為“已支付”

扣減商品庫存

給會員增加積分

創(chuàng)建銷售出庫單通知倉庫發(fā)貨

好，業(yè)務(wù)場景有了，現(xiàn)在我們要更進(jìn)一步，實(shí)現(xiàn)一個 TCC 分布式事務(wù)的效果。

訂單服務(wù)-修改訂單狀態(tài)

庫存服務(wù)-扣減庫存

積分服務(wù)-增加積分

倉儲服務(wù)-創(chuàng)建銷售出庫單。

上述這幾個步驟，要么一起成功，要么一起失敗，必須是一個整體性的事務(wù)。

舉個例子，現(xiàn)在訂單的狀態(tài)都修改為“已支付”了，結(jié)果庫存服務(wù)扣減庫存失敗。那個商品的庫存原來是 100 件，現(xiàn)在賣掉了 2 件，本來應(yīng)該是 98 件了。

結(jié)果呢？由于庫存服務(wù)操作數(shù)據(jù)庫異常，導(dǎo)致庫存數(shù)量還是 100。這不是在坑人么，當(dāng)然不能允許這種情況發(fā)生了！

但是如果你不用 TCC 分布式事務(wù)方案的話，就用個 Spring Cloud 開發(fā)這么一個微服務(wù)系統(tǒng)，很有可能會干出這種事兒來。

我們來看看下面的這個圖，直觀的表達(dá)了上述的過程：

二、如何實(shí)現(xiàn)TCC分布式事務(wù)

那么現(xiàn)在到底要如何來實(shí)現(xiàn)一個 TCC 分布式事務(wù)，使得各個服務(wù)，要么一起成功？要么一起失敗呢？我們這就來一步一步的分析一下。

2.1、TCC 實(shí)現(xiàn)階段一：Try

2.2、TCC 實(shí)現(xiàn)階段二：Confirm

2.3、TCC 實(shí)現(xiàn)階段三：Cancel

2.4、總結(jié)與思考

總結(jié)一下，你要玩兒 TCC 分布式事務(wù)的話：首先需要選擇某種 TCC 分布式事務(wù)框架，各個服務(wù)里就會有這個 TCC 分布式事務(wù)框架在運(yùn)行。

然后你原本的一個接口，要改造為 3 個邏輯，Try-Confirm-Cancel：

先是服務(wù)調(diào)用鏈路依次執(zhí)行 Try 邏輯。

如果都正常的話，TCC 分布式事務(wù)框架推進(jìn)執(zhí)行 Confirm 邏輯，完成整個事務(wù)。

如果某個服務(wù)的 Try 邏輯有問題，TCC 分布式事務(wù)框架感知到之后就會推進(jìn)執(zhí)行各個服務(wù)的 Cancel 邏輯，撤銷之前執(zhí)行的各種操作。

這就是所謂的 TCC 分布式事務(wù)。TCC 分布式事務(wù)的核心思想，說白了，就是當(dāng)遇到下面這些情況時：

某個服務(wù)的數(shù)據(jù)庫宕機(jī)了。

某個服務(wù)自己掛了。

那個服務(wù)的 Redis、Elasticsearch、MQ 等基礎(chǔ)設(shè)施故障了。

某些資源不足了，比如說庫存不夠這些。

先來 Try 一下，不要把業(yè)務(wù)邏輯完成，先試試看，看各個服務(wù)能不能基本正常運(yùn)轉(zhuǎn)，能不能先凍結(jié)我需要的資源。

如果 Try 都 OK，也就是說，底層的數(shù)據(jù)庫、Redis、Elasticsearch、MQ 都是可以寫入數(shù)據(jù)的，并且你保留好了需要使用的一些資源（比如凍結(jié)了一部分庫存）。

接著，再執(zhí)行各個服務(wù)的 Confirm 邏輯，基本上 Confirm 就可以很大概率保證一個分布式事務(wù)的完成了。

那如果 Try 階段某個服務(wù)就失敗了，比如說底層的數(shù)據(jù)庫掛了，或者 Redis 掛了，等等。

此時就自動執(zhí)行各個服務(wù)的 Cancel 邏輯，把之前的 Try 邏輯都回滾，所有服務(wù)都不要執(zhí)行任何設(shè)計的業(yè)務(wù)邏輯。保證大家要么一起成功，要么一起失敗。

等一等，你有沒有想到一個問題？如果有一些意外的情況發(fā)生了，比如說訂單服務(wù)突然掛了，然后再次重啟，TCC 分布式事務(wù)框架是如何保證之前沒執(zhí)行完的分布式事務(wù)繼續(xù)執(zhí)行的呢？

所以，TCC 事務(wù)框架都是要記錄一些分布式事務(wù)的活動日志的，可以在磁盤上的日志文件里記錄，也可以在數(shù)據(jù)庫里記錄。保存下來分布式事務(wù)運(yùn)行的各個階段和狀態(tài)。

問題還沒完，萬一某個服務(wù)的 Cancel 或者 Confirm 邏輯執(zhí)行一直失敗怎么辦呢？

那也很簡單，TCC 事務(wù)框架會通過活動日志記錄各個服務(wù)的狀態(tài)。舉個例子，比如發(fā)現(xiàn)某個服務(wù)的 Cancel 或者 Confirm 一直沒成功，會不停的重試調(diào)用它的 Cancel 或者 Confirm 邏輯，務(wù)必要它成功！

最后，再給大家來一張圖，來看看給我們的業(yè)務(wù)，加上分布式事務(wù)之后的整個執(zhí)行流程：

三、可靠消息最終一致性方案

上面咱們聊了聊 TCC 分布式事務(wù)，對于常見的微服務(wù)系統(tǒng)，大部分接口調(diào)用是同步的，也就是一個服務(wù)直接調(diào)用另外一個服務(wù)的接口。這個時候，用 TCC 分布式事務(wù)方案來保證各個接口的調(diào)用，要么一起成功，要么一起回滾，是比較合適的。

但是在實(shí)際系統(tǒng)的開發(fā)過程中，可能服務(wù)間的調(diào)用是異步的。也就是說，一個服務(wù)發(fā)送一個消息給 MQ，即消息中間件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。然后另外一個服務(wù)從 MQ 消費(fèi)到一條消息后進(jìn)行處理。這就成了基于 MQ 的異步調(diào)用了。

那么針對這種基于 MQ 的異步調(diào)用，如何保證各個服務(wù)間的分布式事務(wù)呢？也就是說，我希望的是基于 MQ 實(shí)現(xiàn)異步調(diào)用的多個服務(wù)的業(yè)務(wù)邏輯，要么一起成功，要么一起失敗。

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

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

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

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

? ? ? ?首先，上游服務(wù)需要發(fā)送一條消息給可靠消息服務(wù)。這條消息說白了，你可以認(rèn)為是對下游服務(wù)一個接口的調(diào)用，里面包含了對應(yīng)的一些請求參數(shù)。
? ? ? ?然后，可靠消息服務(wù)就得把這條消息存儲到自己的數(shù)據(jù)庫里去，狀態(tài)為“待確認(rèn)”。
? ? ? ?接著，上游服務(wù)就可以執(zhí)行自己本地的數(shù)據(jù)庫操作，根據(jù)自己的執(zhí)行結(jié)果，再次調(diào)用可靠消息服務(wù)的接口。
? ? ? ?如果本地數(shù)據(jù)庫操作執(zhí)行成功了，那么就找可靠消息服務(wù)確認(rèn)那條消息。如果本地數(shù)據(jù)庫操作失敗了，那么就找可靠消息服務(wù)刪除那條消息。
? ? ? ?此時如果是確認(rèn)消息，那么可靠消息服務(wù)就把數(shù)據(jù)庫里的消息狀態(tài)更新為“已發(fā)送”，同時將消息發(fā)送給 MQ。
? ? ? ?這里有一個很關(guān)鍵的點(diǎn)，就是更新數(shù)據(jù)庫里的消息狀態(tài)和投遞消息到 MQ。這倆操作，你得放在一個方法里，而且得開啟本地事務(wù)。
? ? ? ?啥意思呢？如果數(shù)據(jù)庫里更新消息的狀態(tài)失敗了，那么就拋異常退出了，就別投遞到 MQ；如果投遞 MQ ? ? ? ?失敗報錯了，那么就要拋異常讓本地數(shù)據(jù)庫事務(wù)回滾。這倆操作必須得一起成功，或者一起失敗。
? ? ? ?如果上游服務(wù)是通知刪除消息，那么可靠消息服務(wù)就得刪除這條消息。

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

? ? ? ?下游服務(wù)就一直等著從 MQ 消費(fèi)消息好了，如果消費(fèi)到了消息，那么就操作自己本地數(shù)據(jù)庫。
? ? ? ?如果操作成功了，就反過來通知可靠消息服務(wù)，說自己處理成功了，然后可靠消息服務(wù)就會把消息的狀態(tài)設(shè)置為“已完成”。

③如何保證上游服務(wù)對消息的 100% 可靠投遞？
上面的核心流程大家都看完：一個很大的問題就是，如果在上述投遞消息的過程中各個環(huán)節(jié)出現(xiàn)了問題該怎么辦？

? ? ? ?我們?nèi)绾伪ＷC消息 100% 的可靠投遞，一定會從上游服務(wù)投遞到下游服務(wù)？別著急，下面我們來逐一分析。
? ? ? ?如果上游服務(wù)給可靠消息服務(wù)發(fā)送待確認(rèn)消息的過程出錯了，那沒關(guān)系，上游服務(wù)可以感知到調(diào)用異常的，就不用執(zhí)行下面的流程了，這是沒問題的。
? ? ? ?如果上游服務(wù)操作完本地數(shù)據(jù)庫之后，通知可靠消息服務(wù)確認(rèn)消息或者刪除消息的時候，出現(xiàn)了問題。
? ? ? ?比如：沒通知成功，或者沒執(zhí)行成功，或者是可靠消息服務(wù)沒成功的投遞消息到 MQ。這一系列步驟出了問題怎么辦？
? ? ? ?其實(shí)也沒關(guān)系，因?yàn)樵谶@些情況下，那條消息在可靠消息服務(wù)的數(shù)據(jù)庫里的狀態(tài)會一直是“待確認(rèn)”。
? ? ? ?此時，我們在可靠消息服務(wù)里開發(fā)一個后臺定時運(yùn)行的線程，不停的檢查各個消息的狀態(tài)。
? ? ? ?如果一直是“待確認(rèn)”狀態(tài)，就認(rèn)為這個消息出了點(diǎn)什么問題。此時的話，就可以回調(diào)上游服務(wù)提供的一個接口，問問說，兄弟，這個消息對應(yīng)的數(shù)據(jù)庫操作，你執(zhí) ? ? ? 行成功了沒啊？
? ? ? ?如果上游服務(wù)答復(fù)說，我執(zhí)行成功了，那么可靠消息服務(wù)將消息狀態(tài)修改為“已發(fā)送”，同時投遞消息到 MQ。
? ? ? ?如果上游服務(wù)答復(fù)說，沒執(zhí)行成功，那么可靠消息服務(wù)將數(shù)據(jù)庫中的消息刪除即可。

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

④如何保證下游服務(wù)對消息的 100% 可靠接收？
那如果下游服務(wù)消費(fèi)消息出了問題，沒消費(fèi)到？或者是下游服務(wù)對消息的處理失敗了，怎么辦？

? ? ? ?其實(shí)也沒關(guān)系，在可靠消息服務(wù)里開發(fā)一個后臺線程，不斷的檢查消息狀態(tài)。
? ? ? ?如果消息狀態(tài)一直是“已發(fā)送”，始終沒有變成“已完成”，那么就說明下游服務(wù)始終沒有處理成功。
? ? ? ?此時可靠消息服務(wù)就可以再次嘗試重新投遞消息到 MQ，讓下游服務(wù)來再次處理。

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

⑤如何基于 RocketMQ 來實(shí)現(xiàn)可靠消息最終一致性方案？
在上面的通用方案設(shè)計里，完全依賴可靠消息服務(wù)的各種自檢機(jī)制來確保：

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

通過這套機(jī)制，保證了基于 MQ 的異步調(diào)用/通知的服務(wù)間的分布式事務(wù)保障。其實(shí)阿里開源的 RocketMQ，就實(shí)現(xiàn)了可靠消息服務(wù)的所有功能，核心思想跟上面類似。

只不過 RocketMQ 為了保證高并發(fā)、高可用、高性能，做了較為復(fù)雜的架構(gòu)實(shí)現(xiàn)，非常的優(yōu)秀。有興趣的同學(xué)，自己可以去查閱 RocketMQ 對分布式事務(wù)的支持。

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

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

如果有高并發(fā)場景的，可以用 RocketMQ 的分布式事務(wù)支持上面的那套流程都可以實(shí)現(xiàn)。大家應(yīng)該發(fā)現(xiàn)了這套方案里保障高可用性最大的一個依賴點(diǎn)，就是 MQ 的高可用性。那如果MQ發(fā)生故障時，如何保證 99.99% 的高可用？

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

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

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

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

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

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

這種情況，就需要針對這套分布式事務(wù)方案實(shí)現(xiàn)一套高可用保障機(jī)制：基于 KV 存儲的隊列支持的高可用降級方案
大家來看看下面這張圖，這是我曾經(jīng)指導(dǎo)過朋友的一個公司針對可靠消息最終一致性方案設(shè)計的一套高可用保障降級機(jī)制。

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

①自行封裝 MQ 客戶端組件與故障感知

? ? ? ?首先第一點(diǎn)，你要做到自動感知 MQ 的故障接著自動完成降級，那么必須動手對 MQ 客戶端進(jìn)行封裝，發(fā)布到公司 Nexus 私服上去。
? ? ? ?然后公司需要支持 MQ 降級的業(yè)務(wù)服務(wù)都使用這個自己封裝的組件來發(fā)送消息到 MQ，以及從 MQ 消費(fèi)消息。
? ? ? ?在你自己封裝的 MQ 客戶端組件里，你可以根據(jù)寫入 MQ 的情況來判斷 MQ 是否故障。
? ? ? ?比如說，如果連續(xù) 10 次重新嘗試投遞消息到 MQ 都發(fā)現(xiàn)異常報錯，網(wǎng)絡(luò)無法聯(lián)通等問題，說明 MQ 故障，此時就可以自動感知以及自動觸發(fā)降級開關(guān)。

②基于 KV 存儲中隊列的降級方案

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

? ? ? ?舉個例子，比如我那位朋友的公司是沒有高并發(fā)場景的，消息的量很少，只不過可用性要求高。此時就可以使用類似 Redis 的 KV 存儲中的隊列來進(jìn)行替代。
? ? ? ?由于 Redis 本身就支持隊列的功能，還有類似隊列的各種數(shù)據(jù)結(jié)構(gòu)，所以你可以將消息寫入 KV 存儲格式的隊列數(shù)據(jù)結(jié)構(gòu)中去。
PS：關(guān)于 Redis 的數(shù)據(jù)存儲格式、支持的數(shù)據(jù)結(jié)構(gòu)等基礎(chǔ)知識，請大家自行查閱了，網(wǎng)上一大堆。

但是，這里有幾個大坑，一定要注意一下：

? ? ? ?第一個，任何 KV 存儲的集合類數(shù)據(jù)結(jié)構(gòu)，建議不要往里面寫入數(shù)據(jù)量過大，否則會導(dǎo)致大 Value 的情況發(fā)生，引發(fā)嚴(yán)重的后果。因此絕不能在 Redis 里搞一個 Key，就拼命往這個數(shù)據(jù)結(jié)構(gòu)中一直寫入消息，這是肯定不行的。
? ? ? ?第二個，絕對不能往少數(shù) Key 對應(yīng)的數(shù)據(jù)結(jié)構(gòu)中持續(xù)寫入數(shù)據(jù)，那樣會導(dǎo)致熱 Key 的產(chǎn)生，也就是某幾個 Key 特別熱。大家要知道，一般 KV 集群，都是根據(jù) Key 來 Hash 分配到各個機(jī)器上的，你要是老寫少數(shù)幾個 Key，會導(dǎo)致 KV 集群中的某臺機(jī)器訪問過高，負(fù)載過大。

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

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

同時需要通過 ZK 觸發(fā)一個降級開關(guān)，整個系統(tǒng)在 MQ 這塊的讀和寫全部立馬降級。

③下游服務(wù)消費(fèi) MQ 的降級感知

? ? ? ?下游服務(wù)消費(fèi) MQ 也是通過自行封裝的組件來做的，此時那個組件如果從 ZK 感知到降級開關(guān)打開了，首先會判斷自己是否還能繼續(xù)從 MQ 消費(fèi)到數(shù)據(jù)？
? ? ? ?如果不能了，就開啟多個線程，并發(fā)的從 KV 存儲的各個預(yù)設(shè)好的上百個隊列中不斷的獲取數(shù)據(jù)。
? ? ? ?每次獲取到一條數(shù)據(jù)，就交給下游服務(wù)的業(yè)務(wù)邏輯來執(zhí)行。通過這套機(jī)制，就實(shí)現(xiàn)了 MQ ? ? ? ?故障時候的自動故障感知，以及自動降級。如果系統(tǒng)的負(fù)載和并發(fā)不是很高的話，用這套方案大致是沒問題的。
? ? ? ?因?yàn)樵谏a(chǎn)落地的過程中，包括大量的容災(zāi)演練以及生產(chǎn)實(shí)際故障發(fā)生時的表現(xiàn)來看，都是可以有效的保證 MQ 故障時，業(yè)務(wù)流程繼續(xù)自動運(yùn)行的。

④故障的自動恢復(fù)

? ? ? ?如果降級開關(guān)打開之后，自行封裝的組件需要開啟一個線程，每隔一段時間嘗試給 MQ 投遞一個消息看看是否恢復(fù)了。
? ? ? ?如果 MQ 已經(jīng)恢復(fù)可以正常投遞消息了，此時就可以通過 ZK 關(guān)閉降級開關(guān)，然后可靠消息服務(wù)繼續(xù)投遞消息到 MQ，下游服務(wù)在確認(rèn) KV 存儲的各個隊列中已經(jīng)沒有數(shù)據(jù)之后，就可以重新切換為從 MQ 消費(fèi)消息。

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

? ? ? ?上面說的那套方案是一套通用的降級方案，但是具體的落地是要結(jié)合各個公司不同的業(yè)務(wù)細(xì)節(jié)來決定的，很多細(xì)節(jié)多沒法在文章里體現(xiàn)。
? ? ? ?比如說你們要不要保證消息的順序性？是不是涉及到需要根據(jù)業(yè)務(wù)動態(tài)，生成大量的 Key？等等。
? ? ? ?此外，這套方案實(shí)現(xiàn)起來還是有一定的成本的，所以建議大家盡可能還是 Push 公司的基礎(chǔ)架構(gòu)團(tuán)隊，保證 MQ 的 99.99% 可用性，不要宕機(jī)。
? ? ? ?其次就是根據(jù)大家公司實(shí)際對高可用的需求來決定，如果感覺 MQ 偶爾宕機(jī)也沒事，可以容忍的話，那么也不用實(shí)現(xiàn)這種降級方案。
? ? ? ?但是如果公司領(lǐng)導(dǎo)認(rèn)為 MQ 中間件宕機(jī)后，一定要保證業(yè)務(wù)系統(tǒng)流程繼續(xù)運(yùn)行，那么還是要考慮一些高可用的降級方案，比如本文提到的這種。
? ? ? ?最后再說一句，真要是一些公司涉及到每秒幾萬幾十萬的高并發(fā)請求，那么對 MQ 的降級方案會設(shè)計的更加的復(fù)雜，那就遠(yuǎn)遠(yuǎn)不是這么簡單可以做到的。

參考地址：

https://www.cnblogs.com/jajian/p/10014145.html

https://www.cnblogs.com/linjiqin/p/9561641.html

總結(jié)

以上是生活随笔為你收集整理的TCC分布式实现原理及分布式应用如何保证高可用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。