詳解Java TCC分佈式事務實現原理

概述

之前網上看到很多寫分佈式事務的文章，不過大多都是將分佈式事務各種技術方案簡單介紹一下。很多朋友看瞭還是不知道分佈式事務到底怎麼回事，在項目裡到底如何使用。

所以這篇文章，就用大白話+手工繪圖，並結合一個電商系統的案例實踐，來給大傢講清楚到底什麼是 TCC 分佈式事務。

業務場景介紹

咱們先來看看業務場景，假設你現在有一個電商系統，裡面有一個支付訂單的場景。

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

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

這是一系列比較真實的步驟，無論大傢有沒有做過電商系統，應該都能理解。

進一步思考

好，業務場景有瞭，現在我們要更進一步，實現一個 TCC 分佈式事務的效果。

什麼意思呢？也就是說，[1] 訂單服務-修改訂單狀態，[2] 庫存服務-扣減庫存，[3] 積分服務-增加積分，[4] 倉儲服務-創建銷售出庫單。

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

舉個例子，現在訂單的狀態都修改為“已支付”瞭，結果庫存服務扣減庫存失敗。那個商品的庫存原來是 100 件，現在賣掉瞭 2 件，本來應該是 98 件瞭。

結果呢？由於庫存服務操作數據庫異常，導致庫存數量還是 100。這不是在坑人麼，當然不能允許這種情況發生瞭！

但是如果你不用 TCC 分佈式事務方案的話，就用個 Spring Cloud 開發這麼一個微服務系統，很有可能會幹出這種事兒來。

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

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

上面那幾個步驟，要麼全部成功，如果任何一個服務的操作失敗瞭，就全部一起回滾，撤銷已經完成的操作。

比如說庫存服務要是扣減庫存失敗瞭，那麼訂單服務就得撤銷那個修改訂單狀態的操作，然後得停止執行增加積分和通知出庫兩個操作。

說瞭那麼多，老規矩，給大傢上一張圖，大夥兒順著圖來直觀的感受一下：

落地實現 TCC 分佈式事務

那麼現在到底要如何來實現一個 TCC 分佈式事務，使得各個服務，要麼一起成功？要麼一起失敗呢？

大傢稍安勿躁，我們這就來一步一步的分析一下。咱們就以一個 Spring Cloud 開發系統作為背景來解釋。

TCC 實現階段一：Try

首先，訂單服務那兒，它的代碼大致來說應該是這樣子的：

public class OrderService {

    // 庫存服務
    @Autowired
    private InventoryService inventoryService;

    // 積分服務
    @Autowired
    private CreditService creditService;

    // 倉儲服務
    @Autowired
    private WmsService wmsService;

    // 對這個訂單完成支付
    public void pay(){
        //對本地的的訂單數據庫修改訂單狀態為"已支付"
        orderDAO.updateStatus(OrderStatus.PAYED);

        //調用庫存服務扣減庫存
        inventoryService.reduceStock();

        //調用積分服務增加積分
        creditService.addCredit();

        //調用倉儲服務通知發貨
        wmsService.saleDelivery();
    }
}

如果你之前看過 Spring Cloud 架構原理那篇文章，同時對 Spring Cloud 有一定的瞭解的話，應該是可以理解上面那段代碼的。

其實就是訂單服務完成本地數據庫操作之後，通過 Spring Cloud 的 Feign 來調用其他的各個服務罷瞭。

但是光是憑借這段代碼，是不足以實現 TCC 分佈式事務的啊？！兄弟們，別著急，我們對這個訂單服務修改點兒代碼好不好。

首先，上面那個訂單服務先把自己的狀態修改為：OrderStatus.UPDATING。

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

這個狀態是個沒有任何含義的這麼一個狀態，代表有人正在修改這個狀態罷瞭。

然後呢，庫存服務直接提供的那個 reduceStock() 接口裡，也別直接扣減庫存啊，你可以是凍結掉庫存。

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

你可以把可銷售的庫存：100 – 2 = 98，設置為 98 沒問題，然後在一個單獨的凍結庫存的字段裡，設置一個 2。也就是說，有 2 個庫存是給凍結瞭。

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

比如：用戶積分原本是 1190，現在要增加 10 個積分，別直接 1190 + 10 = 1200 個積分啊！

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

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

也就是說，剛剛創建這個銷售出庫單，此時還不確定它的狀態是什麼呢！

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

總結上述過程，如果你要實現一個 TCC 分佈式事務，首先你的業務的主流程以及各個接口提供的業務含義，不是說直接完成那個業務操作，而是完成一個 Try 的操作。

這個操作，一般都是鎖定某個資源，設置一個預備類的狀態，凍結部分數據，等等，大概都是這類操作。

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

TCC 實現階段二：Confirm

然後就分成兩種情況瞭，第一種情況是比較理想的，那就是各個服務執行自己的那個 Try 操作，都執行成功瞭，Bingo！

這個時候，就需要依靠 TCC 分佈式事務框架來推動後續的執行瞭。這裡簡單提一句，如果你要玩兒 TCC 分佈式事務，必須引入一款 TCC 分佈式事務框架，比如國內開源的 ByteTCC、Himly、TCC-transaction。

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

如果你在各個服務裡引入瞭一個 TCC 分佈式事務的框架，訂單服務裡內嵌的那個 TCC 分佈式事務框架可以感知到，各個服務的 Try 操作都成功瞭。

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

為瞭實現這個階段，你需要在各個服務裡再加入一些代碼。比如說，訂單服務裡，你可以加入一個 Confirm 的邏輯，就是正式把訂單的狀態設置為“已支付”瞭，大概是類似下面這樣子：

public class OrderServiceConfirm {

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

庫存服務也是類似的，你可以有一個 InventoryServiceConfirm 類，裡面提供一個 reduceStock() 接口的 Confirm 邏輯，這裡就是將之前凍結庫存字段的 2 個庫存扣掉變為 0。

這樣的話，可銷售庫存之前就已經變為 98 瞭，現在凍結的 2 個庫存也沒瞭，那就正式完成瞭庫存的扣減。

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

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

好瞭，上面各種服務的 Confirm 的邏輯都實現好瞭，一旦訂單服務裡面的 TCC 分佈式事務框架感知到各個服務的 Try 階段都成功瞭以後，就會執行各個服務的 Confirm 邏輯。

訂單服務內的 TCC 事務框架會負責跟其他各個服務內的 TCC 事務框架進行通信，依次調用各個服務的 Confirm 邏輯。然後，正式完成各個服務的所有業務邏輯的執行。

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

TCC 實現階段三：Cancel

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

舉個例子：在 Try 階段，比如積分服務吧，它執行出錯瞭，此時會怎麼樣？

那訂單服務內的 TCC 事務框架是可以感知到的，然後它會決定對整個 TCC 分佈式事務進行回滾。

也就是說，會執行各個服務的第二個 C 階段，Cancel 階段。同樣，為瞭實現這個 Cancel 階段，各個服務還得加一些代碼。

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

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

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

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

然後這個時候，訂單服務的 TCC 分佈式事務框架隻要感知到瞭任何一個服務的 Try 邏輯失敗瞭，就會跟各個服務內的 TCC 分佈式事務框架進行通信，然後調用各個服務的 Cancel 邏輯。

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

總結與思考

好瞭，兄弟們，聊到這兒，基本上大傢應該都知道 TCC 分佈式事務具體是怎麼回事瞭！

總結一下，你要玩兒 TCC 分佈式事務的話：首先需要選擇某種 TCC 分佈式事務框架，各個服務裡就會有這個 TCC 分佈式事務框架在運行。

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

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

這就是所謂的 TCC 分佈式事務。TCC 分佈式事務的核心思想，說白瞭，就是當遇到下面這些情況時：

• 某個服務的數據庫宕機瞭。
• 某個服務自己掛瞭。
• 那個服務的 Redis、Elasticsearch、MQ 等基礎設施故障瞭。
• 某些資源不足瞭，比如說庫存不夠這些。

先來 Try 一下，不要把業務邏輯完成，先試試看，看各個服務能不能基本正常運轉，能不能先凍結我需要的資源。

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

接著，再執行各個服務的 Confirm 邏輯，基本上 Confirm 就可以很大概率保證一個分佈式事務的完成瞭。

那如果 Try 階段某個服務就失敗瞭，比如說底層的數據庫掛瞭，或者 Redis 掛瞭，等等。

此時就自動執行各個服務的 Cancel 邏輯，把之前的 Try 邏輯都回滾，所有服務都不要執行任何設計的業務邏輯。保證大傢要麼一起成功，要麼一起失敗。

等一等，你有沒有想到一個問題？如果有一些意外的情況發生瞭，比如說訂單服務突然掛瞭，然後再次重啟，TCC 分佈式事務框架是如何保證之前沒執行完的分佈式事務繼續執行的呢？

所以，TCC 事務框架都是要記錄一些分佈式事務的活動日志的，可以在磁盤上的日志文件裡記錄，也可以在數據庫裡記錄。保存下來分佈式事務運行的各個階段和狀態。

問題還沒完，萬一某個服務的 Cancel 或者 Confirm 邏輯執行一直失敗怎麼辦呢？

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

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

最後，再給大傢來一張圖，來看看給我們的業務，加上分佈式事務之後的整個執行流程：

不少大公司裡，其實都是自己研發 TCC 分佈式事務框架的，專門在公司內部使用，比如我們就是這樣。

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

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

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

隻要把那些框架整合到你的系統裡，很容易就可以實現上面那種奇妙的 TCC 分佈式事務的效果瞭。

下面，我們來講講可靠消息最終一致性方案實現的分佈式事務，同時聊聊在實際生產中遇到的運用該方案的高可用保障架構。

最終一致性分佈式事務如何保障實際生產中 99.99% 高可用

上面咱們聊瞭聊 TCC 分佈式事務，對於常見的微服務系統，大部分接口調用是同步的，也就是一個服務直接調用另外一個服務的接口。

這個時候，用 TCC 分佈式事務方案來保證各個接口的調用，要麼一起成功，要麼一起回滾，是比較合適的。

但是在實際系統的開發過程中，可能服務間的調用是異步的。也就是說，一個服務發送一個消息給 MQ，即消息中間件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。

然後，另外一個服務從 MQ 消費到一條消息後進行處理。這就成瞭基於 MQ 的異步調用瞭。

那麼針對這種基於 MQ 的異步調用，如何保證各個服務間的分佈式事務呢？也就是說，我希望的是基於 MQ 實現異步調用的多個服務的業務邏輯，要麼一起成功，要麼一起失敗。

這個時候，就要用上可靠消息最終一致性方案，來實現分佈式事務。

大傢看上圖，如果不考慮各種高並發、高可用等技術挑戰的話，單從“可靠消息”以及“最終一致性”兩個角度來考慮，這種分佈式事務方案還是比較簡單的。

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

①上遊服務投遞消息

如果要實現可靠消息最終一致性方案，一般你可以自己寫一個可靠消息服務，實現一些業務邏輯。

首先，上遊服務需要發送一條消息給可靠消息服務。這條消息說白瞭，你可以認為是對下遊服務一個接口的調用，裡面包含瞭對應的一些請求參數。

然後，可靠消息服務就得把這條消息存儲到自己的數據庫裡去，狀態為“待確認”。

接著，上遊服務就可以執行自己本地的數據庫操作，根據自己的執行結果，再次調用可靠消息服務的接口。

如果本地數據庫操作執行成功瞭，那麼就找可靠消息服務確認那條消息。如果本地數據庫操作失敗瞭，那麼就找可靠消息服務刪除那條消息。

此時如果是確認消息，那麼可靠消息服務就把數據庫裡的消息狀態更新為“已發送”，同時將消息發送給 MQ。

這裡有一個很關鍵的點，就是更新數據庫裡的消息狀態和投遞消息到 MQ。這倆操作，你得放在一個方法裡，而且得開啟本地事務。

啥意思呢？如果數據庫裡更新消息的狀態失敗瞭，那麼就拋異常退出瞭，就別投遞到 MQ；如果投遞 MQ 失敗報錯瞭，那麼就要拋異常讓本地數據庫事務回滾。這倆操作必須得一起成功，或者一起失敗。

如果上遊服務是通知刪除消息，那麼可靠消息服務就得刪除這條消息。

②下遊服務接收消息

下遊服務就一直等著從 MQ 消費消息好瞭，如果消費到瞭消息，那麼就操作自己本地數據庫。

如果操作成功瞭，就反過來通知可靠消息服務，說自己處理成功瞭，然後可靠消息服務就會把消息的狀態設置為“已完成”。

③如何保證上遊服務對消息的 100% 可靠投遞？

上面的核心流程大傢都看完：一個很大的問題就是，如果在上述投遞消息的過程中各個環節出現瞭問題該怎麼辦？

我們如何保證消息 100% 的可靠投遞，一定會從上遊服務投遞到下遊服務？別著急，下面我們來逐一分析。

如果上遊服務給可靠消息服務發送待確認消息的過程出錯瞭，那沒關系，上遊服務可以感知到調用異常的，就不用執行下面的流程瞭，這是沒問題的。

如果上遊服務操作完本地數據庫之後，通知可靠消息服務確認消息或者刪除消息的時候，出現瞭問題。

比如：沒通知成功，或者沒執行成功，或者是可靠消息服務沒成功的投遞消息到 MQ。這一系列步驟出瞭問題怎麼辦？

其實也沒關系，因為在這些情況下，那條消息在可靠消息服務的數據庫裡的狀態會一直是“待確認”。

此時，我們在可靠消息服務裡開發一個後臺定時運行的線程，不停的檢查各個消息的狀態。

如果一直是“待確認”狀態，就認為這個消息出瞭點什麼問題。此時的話，就可以回調上遊服務提供的一個接口，問問說，兄弟，這個消息對應的數據庫操作，你執行成功瞭沒啊？

如果上遊服務答復說，我執行成功瞭，那麼可靠消息服務將消息狀態修改為“已發送”，同時投遞消息到 MQ。

如果上遊服務答復說，沒執行成功，那麼可靠消息服務將數據庫中的消息刪除即可。

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

④如何保證下遊服務對消息的 100% 可靠接收？

那如果下遊服務消費消息出瞭問題，沒消費到？或者是下遊服務對消息的處理失敗瞭，怎麼辦？

其實也沒關系，在可靠消息服務裡開發一個後臺線程，不斷的檢查消息狀態。

如果消息狀態一直是“已發送”，始終沒有變成“已完成”，那麼就說明下遊服務始終沒有處理成功。

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

隻要下遊服務的接口邏輯實現冪等性，保證多次處理一個消息，不會插入重復數據即可。

⑤如何基於 RocketMQ 來實現可靠消息最終一致性方案？

在上面的通用方案設計裡，完全依賴可靠消息服務的各種自檢機制來確保：

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

通過這套機制，保證瞭基於 MQ 的異步調用/通知的服務間的分佈式事務保障。其實阿裡開源的 RocketMQ，就實現瞭可靠消息服務的所有功能，核心思想跟上面類似。

隻不過 RocketMQ 為瞭保證高並發、高可用、高性能，做瞭較為復雜的架構實現，非常的優秀。有興趣的同學，自己可以去查閱 RocketMQ 對分佈式事務的支持。

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

背景引入

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

在實際落地生產的時候，如果沒有高並發場景的，完全可以參照上面的思路自己基於某個 MQ 中間件開發一個可靠消息服務。

如果有高並發場景的，可以用 RocketMQ 的分佈式事務支持上面的那套流程都可以實現。

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

大傢應該發現瞭這套方案裡保障高可用性最大的一個依賴點，就是 MQ 的高可用性。

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

所以在大公司裡使用可靠消息最終一致性方案的時候，我們通常對可用性的保障都是依賴於公司基礎架構團隊對 MQ 的高可用保障。

也就是說，大傢應該相信兄弟團隊，99.99% 可以保障 MQ 的高可用，絕對不會因為 MQ 集群整體宕機，而導致公司業務系統的分佈式事務全部無法運行。

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

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

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

這種情況，就需要針對這套分佈式事務方案實現一套高可用保障機制。

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

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

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

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

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

然後公司需要支持 MQ 降級的業務服務都使用這個自己封裝的組件來發送消息到 MQ，以及從 MQ 消費消息。

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

比如說，如果連續 10 次重新嘗試投遞消息到 MQ 都發現異常報錯，網絡無法聯通等問題，說明 MQ 故障，此時就可以自動感知以及自動觸發降級開關。

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

如果 MQ 掛掉之後，要是希望繼續投遞消息，那麼就必須得找一個 MQ 的替代品。

舉個例子，比如我那位朋友的公司是沒有高並發場景的，消息的量很少，隻不過可用性要求高。此時就可以使用類似 Redis 的 KV 存儲中的隊列來進行替代。

由於 Redis 本身就支持隊列的功能，還有類似隊列的各種數據結構，所以你可以將消息寫入 KV 存儲格式的隊列數據結構中去。

PS：關於 Redis 的數據存儲格式、支持的數據結構等基礎知識，請大傢自行查閱瞭，網上一大堆。

但是，這裡有幾個大坑，一定要註意一下：

第一個，任何 KV 存儲的集合類數據結構，建議不要往裡面寫入數據量過大，否則會導致大 Value 的情況發生，引發嚴重的後果。

因此絕不能在 Redis 裡搞一個 Key，就拼命往這個數據結構中一直寫入消息，這是肯定不行的。

第二個，絕對不能往少數 Key 對應的數據結構中持續寫入數據，那樣會導致熱 Key 的產生，也就是某幾個 Key 特別熱。

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

基於以上考慮，下面是筆者當時設計的方案：

根據它們每天的消息量，在 KV 存儲中固定劃分上百個隊列，有上百個 Key 對應。這樣保證每個 Key 對應的數據結構中不會寫入過多的消息，而且不會頻繁的寫少數幾個 Key。一旦發生瞭 MQ 故障，可靠消息服務可以對每個消息通過 Hash 算法，均勻的寫入固定好的上百個 Key 對應的 KV 存儲的隊列中。

同時需要通過 ZK 觸發一個降級開關，整個系統在 MQ 這塊的讀和寫全部立馬降級。

③下遊服務消費 MQ 的降級感知

下遊服務消費 MQ 也是通過自行封裝的組件來做的，此時那個組件如果從 ZK 感知到降級開關打開瞭，首先會判斷自己是否還能繼續從 MQ 消費到數據？

如果不能瞭，就開啟多個線程，並發的從 KV 存儲的各個預設好的上百個隊列中不斷的獲取數據。

每次獲取到一條數據，就交給下遊服務的業務邏輯來執行。通過這套機制，就實現瞭 MQ 故障時候的自動故障感知，以及自動降級。如果系統的負載和並發不是很高的話，用這套方案大致是沒問題的。

因為在生產落地的過程中，包括大量的容災演練以及生產實際故障發生時的表現來看，都是可以有效的保證 MQ 故障時，業務流程繼續自動運行的。

④故障的自動恢復

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

如果 MQ 已經恢復可以正常投遞消息瞭，此時就可以通過 ZK 關閉降級開關，然後可靠消息服務繼續投遞消息到 MQ，下遊服務在確認 KV 存儲的各個隊列中已經沒有數據之後，就可以重新切換為從 MQ 消費消息。

⑤更多的業務細節

上面說的那套方案是一套通用的降級方案，但是具體的落地是要結合各個公司不同的業務細節來決定的，很多細節多沒法在文章裡體現。

比如說你們要不要保證消息的順序性？是不是涉及到需要根據業務動態，生成大量的 Key？等等。

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

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

但是如果公司領導認為 MQ 中間件宕機後，一定要保證業務系統流程繼續運行，那麼還是要考慮一些高可用的降級方案，比如本文提到的這種。

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

以上就是詳解Java TCC分佈式事務實現原理的詳細內容，更多關於Java TCC分佈式事務的資料請關註WalkonNet其它相關文章！

推薦閱讀：

None Found