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

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

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

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

業務場景介紹

我們先來看看業務場景，假設你如今有一個電商系統，裏面有一個支付訂單的場景。

那對一個訂單支付以後，咱們須要作下面的步驟：

• 更改訂單的狀態爲「已支付」
• 扣減商品庫存
• 給會員增長積分
• 建立銷售出庫單通知倉庫發貨

這是一系列比較真實的步驟，不管你們有沒有作過電商系統，應該都能理解。

進一步思考

好，業務場景有了，如今咱們要更進一步，實現一個 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 的降級方案會設計的更加的複雜，那就遠遠不是這麼簡單能夠作到的。

來源：【微信公衆號】石杉的架構筆記