【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？

往期文章

1、 ofollow,noindex">拜託！面試請不要再問我Spring Cloud底層原理

2、 【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

3、 【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰

4、 微服務架構如何保障雙11狂歡下的99.99%高可用

5、 兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

6、 大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問

7、【 效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍

8、 拜託，面試請不要再問我TCC分散式事務的實現原理！

上一篇文章咱們聊了聊 TCC分散式事務 ，對於常見的微服務系統，大部分介面呼叫是同步的，也就是一個服務直接呼叫另外一個服務的介面。

這個時候，用TCC分散式事務方案來保證各個介面的呼叫，要麼一起成功，要麼一起回滾，是比較合適的。

但是在實際系統的開發過程中，可能服務間的呼叫是非同步的。

也就是說，一個服務傳送一個訊息給MQ，即訊息中介軟體，比如RocketMQ、RabbitMQ、Kafka、ActiveMQ等等。

然後，另外一個服務從MQ消費到一條訊息後進行處理。這就成了基於MQ的非同步呼叫了。

那麼針對這種基於MQ的非同步呼叫，如何保證各個服務間的分散式事務呢？

也就是說，我希望的是基於MQ實現非同步呼叫的多個服務的業務邏輯，要麼一起成功，要麼一起失敗。

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

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

二、可靠訊息最終一致性方案的核心流程

（1）上游服務投遞訊息

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

首先，上游服務需要傳送一條訊息給可靠訊息服務。

這條訊息說白了，你可以認為是對下游服務一個介面的呼叫，裡面包含了對應的一些請求引數。

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

接著，上游服務就可以執行自己本地的資料庫操作，根據自己的執行結果，再次呼叫可靠訊息服務的介面。

如果本地資料庫操作執行成功了，那麼就找可靠訊息服務確認那條訊息。如果本地資料庫操作失敗了，那麼就找可靠訊息服務刪除那條訊息。

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

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

啥意思呢？

• 如果資料庫裡更新訊息的狀態失敗了，那麼就拋異常退出了，就別投遞到MQ；

• 如果投遞MQ失敗報錯了，那麼就要拋異常讓本地資料庫事務回滾。

• 這倆操作必須得一起成功，或者一起失敗。

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

（2）下游服務接收訊息

下游服務就一直等著從MQ消費訊息好了，如果消費到了訊息，那麼就操作自己本地資料庫。

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

（3）如何上游服務對訊息的100%可靠投遞？

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

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

如果上游服務給可靠訊息服務傳送待確認訊息的過程出錯了，那沒關係，上游服務可以感知到呼叫異常的，就不用執行下面的流程了，這是沒問題的。

如果上游服務操作完本地資料庫之後，通知可靠訊息服務確認訊息或者刪除訊息的時候，出現了問題。

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

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

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

如果一直是“待確認”狀態，就認為這個訊息出了點什麼問題。

此時的話，就可以回撥上游服務提供的一個介面，問問說，兄弟，這個訊息對應的資料庫操作，你執行成功了沒啊？

如果上游服務答覆說，我執行成功了，那麼可靠訊息服務將訊息狀態修改為“已傳送”，同時投遞訊息到MQ。

如果上游服務答覆說，沒執行成功，那麼可靠訊息服務將資料庫中的訊息刪除即可。

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

（4）如何保證下游服務對訊息的100%可靠接收？

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

其實也沒關係， 在可靠訊息服務裡開發一個後臺執行緒，不斷的檢查訊息狀態。

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

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

只要下游服務的介面邏輯 實現冪等性 ，保證多次處理一個訊息，不會插入重複資料即可。

（5）如何基於RocketMQ來實現可靠訊息最終一致性方案？

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

• 如果上游服務的資料庫操作沒成功，下游服務是不會收到任何通知

• 如果上游服務的資料庫操作成功了，可靠訊息服務死活都會確保將一個呼叫訊息投遞給下游服務，而且一定會確保下游服務務必成功處理這條訊息。

通過這套機制，保證了基於MQ的非同步呼叫/通知的服務間的分散式事務保障。

其實阿里開源的RocketMQ，就實現了可靠訊息服務的所有功能，核心思想跟上面類似。

只不過RocketMQ為了保證高併發、高可用、高效能，做了較為複雜的架構實現，非常的優秀。

有興趣的同學，自己可以去查閱RocketMQ對分散式事務的支援。

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

（1）背景引入

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

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

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

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

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

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

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

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

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

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

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

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

（2）基於KV儲存的佇列支援的高可用降級方案

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

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

（1）自行封裝MQ客戶端元件與故障感知

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

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

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

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

（2）基於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這塊的讀和寫全部立馬降級。

（3）下游服務消費MQ的降級感知

下游服務消費MQ也是通過自行封裝的元件來做的，此時那個元件如果從zk感知到降級開關打開了，首先會判斷自己是否還能繼續從MQ消費到資料？

如果不能了，就開啟多個執行緒，併發的從kv儲存的各個預設好的上百個佇列中不斷的獲取資料。

每次獲取到一條資料，就交給下游服務的業務邏輯來執行。

通過這套機制，就實現了MQ故障時候的自動故障感知，以及自動降級。如果系統的負載和併發不是很高的話，用這套方案大致是沒沒問題的。

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

（4）故障的自動恢復

如果降級開關開啟之後，自行封裝的元件需要開啟一個執行緒，每隔一段時間嘗試給MQ投遞一個訊息看看是否恢復了。

如果MQ已經恢復可以正常投遞訊息了，此時就可以通過zk關閉降級開關，然後可靠訊息服務繼續投遞訊息到MQ，下游服務在確認kv儲存的各個佇列中已經沒有資料之後，就可以重新切換為從MQ消費訊息。

（5）更多的業務細節

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

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

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

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

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

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

END