概述

之前網(wǎng)上看到很多寫分布式事務(wù)的文章，不過大多都是將分布式事務(wù)各種技術(shù)方案簡單介紹一下。很多朋友看了還是不知道分布式事務(wù)到底怎么回事，在項(xiàng)目里到底如何使用。

所以這篇文章，就用大白話+手工繪圖，并結(jié)合一個(gè)電商系統(tǒng)的案例實(shí)踐，來給大家講清楚到底什么是 TCC 分布式事務(wù)。

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

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

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

更改訂單的狀態(tài)為“已支付” 扣減商品庫存 給會(huì)員增加積分 創(chuàng)建銷售出庫單通知倉庫發(fā)貨

這是一系列比較真實(shí)的步驟，無論大家有沒有做過電商系統(tǒng)，應(yīng)該都能理解。

進(jìn)一步思考

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

什么意思呢？也就是說，[1] 訂單服務(wù)-修改訂單狀態(tài)，[2] 庫存服務(wù)-扣減庫存，[3] 積分服務(wù)-增加積分，[4] 倉儲服務(wù)-創(chuàng)建銷售出庫單。

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

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

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

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

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

所以說，我們有必要使用 TCC 分布式事務(wù)機(jī)制來保證各個(gè)服務(wù)形成一個(gè)整體性的事務(wù)。

上面那幾個(gè)步驟，要么全部成功，如果任何一個(gè)服務(wù)的操作失敗了，就全部一起回滾，撤銷已經(jīng)完成的操作。

比如說庫存服務(wù)要是扣減庫存失敗了，那么訂單服務(wù)就得撤銷那個(gè)修改訂單狀態(tài)的操作，然后得停止執(zhí)行增加積分和通知出庫兩個(gè)操作。

說了那么多，老規(guī)矩，給大家上一張圖，大伙兒順著圖來直觀的感受一下：

落地實(shí)現(xiàn) TCC 分布式事務(wù)

那么現(xiàn)在到底要如何來實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)，使得各個(gè)服務(wù)，要么一起成功？要么一起失敗呢？

大家稍安勿躁，我們這就來一步一步的分析一下。咱們就以一個(gè) Spring Cloud 開發(fā)系統(tǒng)作為背景來解釋。

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

首先，訂單服務(wù)那兒，它的代碼大致來說應(yīng)該是這樣子的：

public class OrderService { // 庫存服務(wù) @Autowired private InventoryService inventoryService; // 積分服務(wù) @Autowired private CreditService creditService; // 倉儲服務(wù) @Autowired private WmsService wmsService; // 對這個(gè)訂單完成支付 public void pay(){//對本地的的訂單數(shù)據(jù)庫修改訂單狀態(tài)為'已支付'orderDAO.updateStatus(OrderStatus.PAYED);//調(diào)用庫存服務(wù)扣減庫存inventoryService.reduceStock();//調(diào)用積分服務(wù)增加積分creditService.addCredit();//調(diào)用倉儲服務(wù)通知發(fā)貨wmsService.saleDelivery(); }}

如果你之前看過 Spring Cloud 架構(gòu)原理那篇文章，同時(shí)對 Spring Cloud 有一定的了解的話，應(yīng)該是可以理解上面那段代碼的。

其實(shí)就是訂單服務(wù)完成本地?cái)?shù)據(jù)庫操作之后，通過 Spring Cloud 的 Feign 來調(diào)用其他的各個(gè)服務(wù)罷了。

但是光是憑借這段代碼，是不足以實(shí)現(xiàn) TCC 分布式事務(wù)的啊？！兄弟們，別著急，我們對這個(gè)訂單服務(wù)修改點(diǎn)兒代碼好不好。

首先，上面那個(gè)訂單服務(wù)先把自己的狀態(tài)修改為：OrderStatus.UPDATING。

這是啥意思呢？也就是說，在 pay() 那個(gè)方法里，你別直接把訂單狀態(tài)修改為已支付啊！你先把訂單狀態(tài)修改為 UPDATING，也就是修改中的意思。

這個(gè)狀態(tài)是個(gè)沒有任何含義的這么一個(gè)狀態(tài)，代表有人正在修改這個(gè)狀態(tài)罷了。

然后呢，庫存服務(wù)直接提供的那個(gè) reduceStock() 接口里，也別直接扣減庫存啊，你可以是凍結(jié)掉庫存。

舉個(gè)例子，本來你的庫存數(shù)量是 100，你別直接 100 - 2 = 98，扣減這個(gè)庫存！

你可以把可銷售的庫存：100 - 2 = 98，設(shè)置為 98 沒問題，然后在一個(gè)單獨(dú)的凍結(jié)庫存的字段里，設(shè)置一個(gè) 2。也就是說，有 2 個(gè)庫存是給凍結(jié)了。

積分服務(wù)的 addCredit() 接口也是同理，別直接給用戶增加會(huì)員積分。你可以先在積分表里的一個(gè)預(yù)增加積分字段加入積分。

比如：用戶積分原本是 1190，現(xiàn)在要增加 10 個(gè)積分，別直接 1190 + 10 = 1200 個(gè)積分啊！

你可以保持積分為 1190 不變，在一個(gè)預(yù)增加字段里，比如說 prepare_add_credit 字段，設(shè)置一個(gè) 10，表示有 10 個(gè)積分準(zhǔn)備增加。

倉儲服務(wù)的 saleDelivery() 接口也是同理啊，你可以先創(chuàng)建一個(gè)銷售出庫單，但是這個(gè)銷售出庫單的狀態(tài)是“UNKNOWN”。

也就是說，剛剛創(chuàng)建這個(gè)銷售出庫單，此時(shí)還不確定它的狀態(tài)是什么呢！

上面這套改造接口的過程，其實(shí)就是所謂的 TCC 分布式事務(wù)中的第一個(gè) T 字母代表的階段，也就是 Try 階段。

總結(jié)上述過程，如果你要實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)，首先你的業(yè)務(wù)的主流程以及各個(gè)接口提供的業(yè)務(wù)含義，不是說直接完成那個(gè)業(yè)務(wù)操作，而是完成一個(gè) Try 的操作。

這個(gè)操作，一般都是鎖定某個(gè)資源，設(shè)置一個(gè)預(yù)備類的狀態(tài)，凍結(jié)部分?jǐn)?shù)據(jù)，等等，大概都是這類操作。

咱們來一起看看下面這張圖，結(jié)合上面的文字，再來捋一捋整個(gè)過程：

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

然后就分成兩種情況了，第一種情況是比較理想的，那就是各個(gè)服務(wù)執(zhí)行自己的那個(gè) Try 操作，都執(zhí)行成功了，Bingo！

這個(gè)時(shí)候，就需要依靠 TCC 分布式事務(wù)框架來推動(dòng)后續(xù)的執(zhí)行了。這里簡單提一句，如果你要玩兒 TCC 分布式事務(wù)，必須引入一款 TCC 分布式事務(wù)框架，比如國內(nèi)開源的 ByteTCC、Himly、TCC-transaction。

否則的話，感知各個(gè)階段的執(zhí)行情況以及推進(jìn)執(zhí)行下一個(gè)階段的這些事情，不太可能自己手寫實(shí)現(xiàn)，太復(fù)雜了。

如果你在各個(gè)服務(wù)里引入了一個(gè) TCC 分布式事務(wù)的框架，訂單服務(wù)里內(nèi)嵌的那個(gè) TCC 分布式事務(wù)框架可以感知到，各個(gè)服務(wù)的 Try 操作都成功了。

此時(shí)，TCC 分布式事務(wù)框架會(huì)控制進(jìn)入 TCC 下一個(gè)階段，第一個(gè) C 階段，也就是 Confirm 階段。

為了實(shí)現(xiàn)這個(gè)階段，你需要在各個(gè)服務(wù)里再加入一些代碼。比如說，訂單服務(wù)里，你可以加入一個(gè) Confirm 的邏輯，就是正式把訂單的狀態(tài)設(shè)置為“已支付”了，大概是類似下面這樣子：

public class OrderServiceConfirm { public void pay(){orderDao.updateStatus(OrderStatus.PAYED); }}

庫存服務(wù)也是類似的，你可以有一個(gè) InventoryServiceConfirm 類，里面提供一個(gè) reduceStock() 接口的 Confirm 邏輯，這里就是將之前凍結(jié)庫存字段的 2 個(gè)庫存扣掉變?yōu)?0。

這樣的話，可銷售庫存之前就已經(jīng)變?yōu)?98 了，現(xiàn)在凍結(jié)的 2 個(gè)庫存也沒了，那就正式完成了庫存的扣減。

積分服務(wù)也是類似的，可以在積分服務(wù)里提供一個(gè) CreditServiceConfirm 類，里面有一個(gè) addCredit() 接口的 Confirm 邏輯，就是將預(yù)增加字段的 10 個(gè)積分扣掉，然后加入實(shí)際的會(huì)員積分字段中，從 1190 變?yōu)?1120。

倉儲服務(wù)也是類似，可以在倉儲服務(wù)中提供一個(gè) WmsServiceConfirm 類，提供一個(gè) saleDelivery() 接口的 Confirm 邏輯，將銷售出庫單的狀態(tài)正式修改為“已創(chuàng)建”，可以供倉儲管理人員查看和使用，而不是停留在之前的中間狀態(tài)“UNKNOWN”了。

好了，上面各種服務(wù)的 Confirm 的邏輯都實(shí)現(xiàn)好了，一旦訂單服務(wù)里面的 TCC 分布式事務(wù)框架感知到各個(gè)服務(wù)的 Try 階段都成功了以后，就會(huì)執(zhí)行各個(gè)服務(wù)的 Confirm 邏輯。

訂單服務(wù)內(nèi)的 TCC 事務(wù)框架會(huì)負(fù)責(zé)跟其他各個(gè)服務(wù)內(nèi)的 TCC 事務(wù)框架進(jìn)行通信，依次調(diào)用各個(gè)服務(wù)的 Confirm 邏輯。然后，正式完成各個(gè)服務(wù)的所有業(yè)務(wù)邏輯的執(zhí)行。

同樣，給大家來一張圖，順著圖一起來看看整個(gè)過程：

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

好，這是比較正常的一種情況，那如果是異常的一種情況呢？

舉個(gè)例子：在 Try 階段，比如積分服務(wù)吧，它執(zhí)行出錯(cuò)了，此時(shí)會(huì)怎么樣？

那訂單服務(wù)內(nèi)的 TCC 事務(wù)框架是可以感知到的，然后它會(huì)決定對整個(gè) TCC 分布式事務(wù)進(jìn)行回滾。

也就是說，會(huì)執(zhí)行各個(gè)服務(wù)的第二個(gè) C 階段，Cancel 階段。同樣，為了實(shí)現(xiàn)這個(gè) Cancel 階段，各個(gè)服務(wù)還得加一些代碼。

首先訂單服務(wù)，它得提供一個(gè) OrderServiceCancel 的類，在里面有一個(gè) pay() 接口的 Cancel 邏輯，就是可以將訂單的狀態(tài)設(shè)置為“CANCELED”，也就是這個(gè)訂單的狀態(tài)是已取消。

庫存服務(wù)也是同理，可以提供 reduceStock() 的 Cancel 邏輯，就是將凍結(jié)庫存扣減掉 2，加回到可銷售庫存里去，98 + 2 = 100。

積分服務(wù)也需要提供 addCredit() 接口的 Cancel 邏輯，將預(yù)增加積分字段的 10 個(gè)積分扣減掉。

倉儲服務(wù)也需要提供一個(gè) saleDelivery() 接口的 Cancel 邏輯，將銷售出庫單的狀態(tài)修改為“CANCELED”設(shè)置為已取消。

然后這個(gè)時(shí)候，訂單服務(wù)的 TCC 分布式事務(wù)框架只要感知到了任何一個(gè)服務(wù)的 Try 邏輯失敗了，就會(huì)跟各個(gè)服務(wù)內(nèi)的 TCC 分布式事務(wù)框架進(jìn)行通信，然后調(diào)用各個(gè)服務(wù)的 Cancel 邏輯。

大家看看下面的圖，直觀的感受一下：

總結(jié)與思考

好了，兄弟們，聊到這兒，基本上大家應(yīng)該都知道 TCC 分布式事務(wù)具體是怎么回事了！

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

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

先是服務(wù)調(diào)用鏈路依次執(zhí)行 Try 邏輯。 如果都正常的話，TCC 分布式事務(wù)框架推進(jìn)執(zhí)行 Confirm 邏輯，完成整個(gè)事務(wù)。 如果某個(gè)服務(wù)的 Try 邏輯有問題，TCC 分布式事務(wù)框架感知到之后就會(huì)推進(jìn)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯，撤銷之前執(zhí)行的各種操作。

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

某個(gè)服務(wù)的數(shù)據(jù)庫宕機(jī)了。 某個(gè)服務(wù)自己掛了。 那個(gè)服務(wù)的 Redis、Elasticsearch、MQ 等基礎(chǔ)設(shè)施故障了。 某些資源不足了，比如說庫存不夠這些。

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

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

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

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

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

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

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

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

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

當(dāng)然了，如果你的代碼沒有寫什么 Bug，有充足的測試，而且 Try 階段都基本嘗試了一下，那么其實(shí)一般 Confirm、Cancel 都是可以成功的！

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

不少大公司里，其實(shí)都是自己研發(fā) TCC 分布式事務(wù)框架的，專門在公司內(nèi)部使用，比如我們就是這樣。

不過如果自己公司沒有研發(fā) TCC 分布式事務(wù)框架的話，那一般就會(huì)選用開源的框架。

這里筆者給大家推薦幾個(gè)比較不錯(cuò)的框架，都是咱們國內(nèi)自己開源出去的：ByteTCC，TCC-transaction，Himly。

大家有興趣的可以去它們的 GitHub 地址，學(xué)習(xí)一下如何使用，以及如何跟 Spring Cloud、Dubbo 等服務(wù)框架整合使用。

只要把那些框架整合到你的系統(tǒng)里，很容易就可以實(shí)現(xiàn)上面那種奇妙的 TCC 分布式事務(wù)的效果了。

下面，我們來講講可靠消息最終一致性方案實(shí)現(xiàn)的分布式事務(wù)，同時(shí)聊聊在實(shí)際生產(chǎn)中遇到的運(yùn)用該方案的高可用保障架構(gòu)。

最終一致性分布式事務(wù)如何保障實(shí)際生產(chǎn)中 99.99% 高可用

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

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

但是在實(shí)際系統(tǒng)的開發(fā)過程中，可能服務(wù)間的調(diào)用是異步的。也就是說，一個(gè)服務(wù)發(fā)送一個(gè)消息給 MQ，即消息中間件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。

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

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

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

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

可靠消息最終一致性方案的核心流程①上游服務(wù)投遞消息

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

首先，上游服務(wù)需要發(fā)送一條消息給可靠消息服務(wù)。這條消息說白了，你可以認(rèn)為是對下游服務(wù)一個(gè)接口的調(diào)用，里面包含了對應(yīng)的一些請求參數(shù)。

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

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

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

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

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

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

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

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

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

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

③如何保證上游服務(wù)對消息的 100% 可靠投遞？

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

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

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

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

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

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

此時(shí)，我們在可靠消息服務(wù)里開發(fā)一個(gè)后臺定時(shí)運(yùn)行的線程，不停的檢查各個(gè)消息的狀態(tài)。

如果一直是“待確認(rèn)”狀態(tài)，就認(rèn)為這個(gè)消息出了點(diǎn)什么問題。此時(shí)的話，就可以回調(diào)上游服務(wù)提供的一個(gè)接口，問問說，兄弟，這個(gè)消息對應(yīng)的數(shù)據(jù)庫操作，你執(zhí)行成功了沒啊？

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

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

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

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

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

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

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

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

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

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

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

如果上游服務(wù)的數(shù)據(jù)庫操作沒成功，下游服務(wù)是不會(huì)收到任何通知。 如果上游服務(wù)的數(shù)據(jù)庫操作成功了，可靠消息服務(wù)死活都會(huì)確保將一個(gè)調(diào)用消息投遞給下游服務(wù)，而且一定會(huì)確保下游服務(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ù)的支持。

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

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

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

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

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

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

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

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

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

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

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

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

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

基于 KV 存儲的隊(duì)列支持的高可用降級方案

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

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

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

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

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

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

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

②基于 KV 存儲中隊(duì)列的降級方案

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

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

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

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

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

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

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

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

大家要知道，一般 KV 集群，都是根據(jù) Key 來 Hash 分配到各個(gè)機(jī)器上的，你要是老寫少數(shù)幾個(gè) Key，會(huì)導(dǎo)致 KV 集群中的某臺機(jī)器訪問過高，負(fù)載過大。

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

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

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

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

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

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

每次獲取到一條數(shù)據(jù)，就交給下游服務(wù)的業(yè)務(wù)邏輯來執(zhí)行。通過這套機(jī)制，就實(shí)現(xiàn)了 MQ 故障時(shí)候的自動(dòng)故障感知，以及自動(dòng)降級。如果系統(tǒng)的負(fù)載和并發(fā)不是很高的話，用這套方案大致是沒問題的。

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

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

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

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

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

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

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

此外，這套方案實(shí)現(xiàn)起來還是有一定的成本的，所以建議大家盡可能還是 Push 公司的基礎(chǔ)架構(gòu)團(tuán)隊(duì)，保證 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 的降級方案會(huì)設(shè)計(jì)的更加的復(fù)雜，那就遠(yuǎn)遠(yuǎn)不是這么簡單可以做到的。

以上就是詳解Java TCC分布式事務(wù)實(shí)現(xiàn)原理的詳細(xì)內(nèi)容，更多關(guān)于Java TCC分布式事務(wù)的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！