終於有人把「TCC分散式事務」實現原理講明白了！

終於有人把「TCC分散式事務」實現原理講明白了！

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

作者：中華石杉來源：石杉的架構筆記|2018-11-23 09:25

收藏

分享

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

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

首先說一下，這裡可能會牽扯到一些 Spring Cloud 的原理，如果有不太清楚的同學，可以參考之前的文章：《拜託，面試請不要再問我Spring Cloud底層原理！》。

業務場景介紹

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

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

• 更改訂單的狀態為「已支付」

• 扣減商品庫存

• 給會員增加積分

• 創建銷售出庫單通知倉庫發貨

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

進一步思考

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

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

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

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

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

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

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

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

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

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

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

落地實現 TCC 分散式事務

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

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

TCC 實現階段一：Try

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

如果你之前看過 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 的邏輯，就是正式把訂單的狀態設置為「已支付」了，大概是類似下面這樣子：

庫存服務也是類似的，你可以有一個 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 的降級方案會設計的更加的複雜，那就遠遠不是這麼簡單可以做到的。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！