之前總結的一些分佈式事務文章
開源項目TCC-Transaction：https://blog.csdn.net/shanchahua123456/article/details/86767156
最終一致性模型：https://blog.csdn.net/shanchahua123456/article/details/84950628
https://blog.csdn.net/shanchahua123456/article/details/84781638
本文來源：【微信公衆號】石杉的架構筆記
|0業務場景介紹
咱們先來看看業務場景，假設你現在有一個電商系統，裏面有一個支付訂單的場景。
那對一個訂單支付之後，我們需要做下面的步驟：
- 更改訂單的狀態爲“已支付”
- 扣減商品庫存
- 給會員增加積分
- 創建銷售出庫單通知倉庫發貨
這是一系列比較真實的步驟，無論大家有沒有做過電商系統，應該都能理解。
2|0進一步思考
好，業務場景有了，現在我們要更進一步，實現一個 TCC 分佈式事務的效果。
什麼意思呢？也就是說，[1] 訂單服務-修改訂單狀態，[2] 庫存服務-扣減庫存，[3] 積分服務-增加積分，[4] 倉儲服務-創建銷售出庫單。
上述這幾個步驟，要麼一起成功，要麼一起失敗，必須是一個整體性的事務。
舉個例子，現在訂單的狀態都修改爲“已支付”了，結果庫存服務扣減庫存失敗。那個商品的庫存原來是 100 件，現在賣掉了 2 件，本來應該是 98 件了。
結果呢？由於庫存服務操作數據庫異常，導致庫存數量還是 100。這不是在坑人麼，當然不能允許這種情況發生了！
但是如果你不用 TCC 分佈式事務方案的話，就用個 Spring Cloud 開發這麼一個微服務系統，很有可能會幹出這種事兒來。
我們來看看下面的這個圖，直觀的表達了上述的過程：
所以說，我們有必要使用 TCC 分佈式事務機制來保證各個服務形成一個整體性的事務。
上面那幾個步驟，要麼全部成功，如果任何一個服務的操作失敗了，就全部一起回滾，撤銷已經完成的操作。
比如說庫存服務要是扣減庫存失敗了，那麼訂單服務就得撤銷那個修改訂單狀態的操作，然後得停止執行增加積分和通知出庫兩個操作。
說了那麼多，老規矩，給大家上一張圖，大夥兒順着圖來直觀的感受一下：
3|0落地實現 TCC 分佈式事務
那麼現在到底要如何來實現一個 TCC 分佈式事務，使得各個服務，要麼一起成功？要麼一起失敗呢？
大家稍安勿躁，我們這就來一步一步的分析一下。咱們就以一個 Spring Cloud 開發系統作爲背景來解釋。
3|1TCC 實現階段一：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 的操作。
這個操作，一般都是鎖定某個資源，設置一個預備類的狀態，凍結部分數據，等等，大概都是這類操作。
咱們來一起看看下面這張圖，結合上面的文字，再來捋一捋整個過程：
3|2TCC 實現階段二：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 邏輯。然後，正式完成各個服務的所有業務邏輯的執行。
同樣，給大家來一張圖，順着圖一起來看看整個過程：
3|3TCC 實現階段三：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 邏輯。
大家看看下面的圖，直觀的感受一下：
3|4總結與思考
好了，兄弟們，聊到這兒，基本上大家應該都知道 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 分佈式事務的效果了。
下面，我們來講講可靠消息最終一致性方案實現的分佈式事務，同時聊聊在實際生產中遇到的運用該方案的高可用保障架構。
4|0最終一致性分佈式事務如何保障實際生產中 99.99% 高可用？
上面咱們聊了聊 TCC 分佈式事務，對於常見的微服務系統，大部分接口調用是同步的，也就是一個服務直接調用另外一個服務的接口。
這個時候，用 TCC 分佈式事務方案來保證各個接口的調用，要麼一起成功，要麼一起回滾，是比較合適的。
但是在實際系統的開發過程中，可能服務間的調用是異步的。也就是說，一個服務發送一個消息給 MQ，即消息中間件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。
然後，另外一個服務從 MQ 消費到一條消息後進行處理。這就成了基於 MQ 的異步調用了。
那麼針對這種基於 MQ 的異步調用，如何保證各個服務間的分佈式事務呢？也就是說，我希望的是基於 MQ 實現異步調用的多個服務的業務邏輯，要麼一起成功，要麼一起失敗。
這個時候，就要用上可靠消息最終一致性方案，來實現分佈式事務。
大家看上圖，如果不考慮各種高併發、高可用等技術挑戰的話，單從“可靠消息”以及“最終一致性”兩個角度來考慮，這種分佈式事務方案還是比較簡單的。
4|1可靠消息最終一致性方案的核心流程
①上游服務投遞消息
如果要實現可靠消息最終一致性方案，一般你可以自己寫一個可靠消息服務，實現一些業務邏輯。
首先，上游服務需要發送一條消息給可靠消息服務。這條消息說白了，你可以認爲是對下游服務一個接口的調用，裏面包含了對應的一些請求參數。
然後，可靠消息服務就得把這條消息存儲到自己的數據庫裏去，狀態爲“待確認”。
接着，上游服務就可以執行自己本地的數據庫操作，根據自己的執行結果，再次調用可靠消息服務的接口。
如果本地數據庫操作執行成功了，那麼就找可靠消息服務確認那條消息。如果本地數據庫操作失敗了，那麼就找可靠消息服務刪除那條消息。
此時如果是確認消息，那麼可靠消息服務就把數據庫裏的消息狀態更新爲“已發送”，同時將消息發送給 MQ。
這裏有一個很關鍵的點，就是更新數據庫裏的消息狀態和投遞消息到 MQ。這倆操作，你得放在一個方法裏，而且得開啓本地事務。
啥意思呢？如果數據庫裏更新消息的狀態失敗了，那麼就拋異常退出了，就別投遞到 MQ；如果投遞 MQ 失敗報錯了，那麼就要拋異常讓本地數據庫事務回滾。這倆操作必須得一起成功，或者一起失敗。
如果上游服務是通知刪除消息，那麼可靠消息服務就得刪除這條消息。
②下游服務接收消息
下游服務就一直等着從 MQ 消費消息好了，如果消費到了消息，那麼就操作自己本地數據庫。
如果操作成功了，就反過來通知可靠消息服務，說自己處理成功了，然後可靠消息服務就會把消息的狀態設置爲“已完成”。
③如何保證上游服務對消息的 100% 可靠投遞？
上面的核心流程大家都看完：一個很大的問題就是，如果在上述投遞消息的過程中各個環節出現了問題該怎麼辦？
我們如何保證消息 100% 的可靠投遞，一定會從上游服務投遞到下游服務？彆着急，下面我們來逐一分析。
如果上游服務給可靠消息服務發送待確認消息的過程出錯了，那沒關係，上游服務可以感知到調用異常的，就不用執行下面的流程了，這是沒問題的。
如果上游服務操作完本地數據庫之後，通知可靠消息服務確認消息或者刪除消息的時候，出現了問題。
比如：沒通知成功，或者沒執行成功，或者是可靠消息服務沒成功的投遞消息到 MQ。這一系列步驟出了問題怎麼辦？
其實也沒關係，因爲在這些情況下，那條消息在可靠消息服務的數據庫裏的狀態會一直是“待確認”。
此時，我們在可靠消息服務裏開發一個後臺定時運行的線程，不停的檢查各個消息的狀態。
如果一直是“待確認”狀態，就認爲這個消息出了點什麼問題。此時的話，就可以回調上游服務提供的一個接口，問問說，兄弟，這個消息對應的數據庫操作，你執行成功了沒啊？
如果上游服務答覆說，我執行成功了，那麼可靠消息服務將消息狀態修改爲“已發送”，同時投遞消息到 MQ。
如果上游服務答覆說，沒執行成功，那麼可靠消息服務將數據庫中的消息刪除即可。
通過這套機制，就可以保證，可靠消息服務一定會嘗試完成消息到 MQ 的投遞。
④如何保證下游服務對消息的 100% 可靠接收？
那如果下游服務消費消息出了問題，沒消費到？或者是下游服務對消息的處理失敗了，怎麼辦？
其實也沒關係，在可靠消息服務裏開發一個後臺線程，不斷的檢查消息狀態。
如果消息狀態一直是“已發送”，始終沒有變成“已完成”，那麼就說明下游服務始終沒有處理成功。
此時可靠消息服務就可以再次嘗試重新投遞消息到 MQ，讓下游服務來再次處理。
只要下游服務的接口邏輯實現冪等性，保證多次處理一個消息，不會插入重複數據即可。
⑤如何基於 RocketMQ 來實現可靠消息最終一致性方案？
在上面的通用方案設計裏，完全依賴可靠消息服務的各種自檢機制來確保：
- 如果上游服務的數據庫操作沒成功，下游服務是不會收到任何通知。
- 如果上游服務的數據庫操作成功了，可靠消息服務死活都會確保將一個調用消息投遞給下游服務，而且一定會確保下游服務務必成功處理這條消息。
通過這套機制，保證了基於 MQ 的異步調用/通知的服務間的分佈式事務保障。其實阿里開源的 RocketMQ，就實現了可靠消息服務的所有功能，核心思想跟上面類似。
只不過 RocketMQ 爲了保證高併發、高可用、高性能，做了較爲複雜的架構實現，非常的優秀。有興趣的同學，自己可以去查閱 RocketMQ 對分佈式事務的支持。
4|2可靠消息最終一致性方案的高可用保障生產實踐
背景引入
上面那套方案和思想，很多同學應該都知道是怎麼回事兒，我們也主要就是鋪墊一下這套理論思想。
在實際落地生產的時候，如果沒有高併發場景的，完全可以參照上面的思路自己基於某個 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 存儲中隊列的降級方案②基於 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 的降級方案會設計的更加的複雜，那就遠遠不是這麼簡單可以做到的。