概述

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

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

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

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

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

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

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

進一步思考

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

public class OrderService {

    // 庫存服務(wù)
    @Autowired
    private InventoryService inventoryService;

    // 積分服務(wù)
    @Autowired
    private CreditService creditService;

    // 倉儲服務(wù)
    @Autowired
    private WmsService wmsService;

    // 對這個訂單完成支付
    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)原理那篇文章，同時對 Spring Cloud 有一定的了解的話，應(yīng)該是可以理解上面那段代碼的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

public class OrderServiceConfirm {

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)與思考

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

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

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

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

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

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

先來 Try 一下，不要把業(yè)務(wù)邏輯完成，先試試看，看各個服務(wù)能不能基本正常運轉(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ù)運行的各個階段和狀態(tài)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

背景引入

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在你自己封裝的 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 存儲中的隊列來進行替代。

由于 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ù)量過大，否則會導致大 Value 的情況發(fā)生，引發(fā)嚴重的后果。

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

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

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

基于以上考慮，下面是筆者當時設(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ù)消費 MQ 的降級感知

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

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

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

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

④故障的自動恢復

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

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

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

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

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

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

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

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

最后再說一句，真要是一些公司涉及到每秒幾萬幾十萬的高并發(fā)請求，那么對 MQ 的降級方案會設(shè)計的更加的復雜，那就遠遠不是這么簡單可以做到的。

以上就是詳解Java TCC分布式事務(wù)實現(xiàn)原理的詳細內(nèi)容，更多關(guān)于Java TCC分布式事務(wù)的資料請關(guān)注腳本之家其它相關(guān)文章！