TCC分布式实现原理及分布式应用如何保证高可用
一、業務場景介紹
咱們先來看看業務場景，假設你現在有一個電商系統，里面有一個支付訂單的場景。
那對一個訂單支付之后，我們需要做下面的步驟：
好，業務場景有了，現在我們要更進一步，實現一個 TCC 分布式事務的效果。
上述這幾個步驟，要么一起成功，要么一起失敗，必須是一個整體性的事務。
舉個例子，現在訂單的狀態都修改為“已支付”了，結果庫存服務扣減庫存失敗。那個商品的庫存原來是 100 件，現在賣掉了 2 件，本來應該是 98 件了。
結果呢？由于庫存服務操作數據庫異常，導致庫存數量還是 100。這不是在坑人么，當然不能允許這種情況發生了！
但是如果你不用 TCC 分布式事務方案的話，就用個 Spring Cloud 開發這么一個微服務系統，很有可能會干出這種事兒來。
我們來看看下面的這個圖，直觀的表達了上述的過程：
二、如何實現TCC分布式事務
那么現在到底要如何來實現一個 TCC 分布式事務，使得各個服務，要么一起成功？要么一起失敗呢？我們這就來一步一步的分析一下。
2.1、TCC 實現階段一：Try
2.2、TCC 實現階段二：Confirm
2.3、TCC 實現階段三：Cancel
2.4、總結與思考
總結一下，你要玩兒 TCC 分布式事務的話：首先需要選擇某種 TCC 分布式事務框架，各個服務里就會有這個 TCC 分布式事務框架在運行。
然后你原本的一個接口，要改造為 3 個邏輯，Try-Confirm-Cancel：
這就是所謂的 TCC 分布式事務。TCC 分布式事務的核心思想，說白了，就是當遇到下面這些情況時：
先來 Try 一下，不要把業務邏輯完成，先試試看，看各個服務能不能基本正常運轉，能不能先凍結我需要的資源。
如果 Try 都 OK，也就是說，底層的數據庫、Redis、Elasticsearch、MQ 都是可以寫入數據的，并且你保留好了需要使用的一些資源（比如凍結了一部分庫存）。
接著，再執行各個服務的 Confirm 邏輯，基本上 Confirm 就可以很大概率保證一個分布式事務的完成了。
那如果 Try 階段某個服務就失敗了，比如說底層的數據庫掛了，或者 Redis 掛了，等等。
此時就自動執行各個服務的 Cancel 邏輯，把之前的 Try 邏輯都回滾，所有服務都不要執行任何設計的業務邏輯。保證大家要么一起成功，要么一起失敗。
等一等，你有沒有想到一個問題？如果有一些意外的情況發生了，比如說訂單服務突然掛了，然后再次重啟，TCC 分布式事務框架是如何保證之前沒執行完的分布式事務繼續執行的呢？
所以，TCC 事務框架都是要記錄一些分布式事務的活動日志的，可以在磁盤上的日志文件里記錄，也可以在數據庫里記錄。保存下來分布式事務運行的各個階段和狀態。
問題還沒完，萬一某個服務的 Cancel 或者 Confirm 邏輯執行一直失敗怎么辦呢？
那也很簡單，TCC 事務框架會通過活動日志記錄各個服務的狀態。舉個例子，比如發現某個服務的 Cancel 或者 Confirm 一直沒成功，會不停的重試調用它的 Cancel 或者 Confirm 邏輯，務必要它成功！
最后，再給大家來一張圖，來看看給我們的業務，加上分布式事務之后的整個執行流程：
三、可靠消息最終一致性方案
上面咱們聊了聊 TCC 分布式事務，對于常見的微服務系統，大部分接口調用是同步的，也就是一個服務直接調用另外一個服務的接口。這個時候，用 TCC 分布式事務方案來保證各個接口的調用，要么一起成功，要么一起回滾，是比較合適的。
但是在實際系統的開發過程中，可能服務間的調用是異步的。也就是說，一個服務發送一個消息給 MQ，即消息中間件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。然后另外一個服務從 MQ 消費到一條消息后進行處理。這就成了基于 MQ 的異步調用了。
那么針對這種基于 MQ 的異步調用，如何保證各個服務間的分布式事務呢？也就是說，我希望的是基于 MQ 實現異步調用的多個服務的業務邏輯，要么一起成功，要么一起失敗。
這個時候，就要用上可靠消息最終一致性方案，來實現分布式事務。
大家看上圖，如果不考慮各種高并發、高可用等技術挑戰的話，單從“可靠消息”以及“最終一致性”兩個角度來考慮，這種分布式事務方案還是比較簡單的。
3.1、可靠消息最終一致性方案的核心流程
①上游服務投遞消息
如果要實現可靠消息最終一致性方案，一般你可以自己寫一個可靠消息服務，實現一些業務邏輯。
? ? ? ?首先，上游服務需要發送一條消息給可靠消息服務。這條消息說白了，你可以認為是對下游服務一個接口的調用，里面包含了對應的一些請求參數。
? ? ? ?然后，可靠消息服務就得把這條消息存儲到自己的數據庫里去，狀態為“待確認”。
? ? ? ?接著，上游服務就可以執行自己本地的數據庫操作，根據自己的執行結果，再次調用可靠消息服務的接口。
? ? ? ?如果本地數據庫操作執行成功了，那么就找可靠消息服務確認那條消息。如果本地數據庫操作失敗了，那么就找可靠消息服務刪除那條消息。
? ? ? ?此時如果是確認消息，那么可靠消息服務就把數據庫里的消息狀態更新為“已發送”，同時將消息發送給 MQ。
? ? ? ?這里有一個很關鍵的點，就是更新數據庫里的消息狀態和投遞消息到 MQ。這倆操作，你得放在一個方法里，而且得開啟本地事務。
? ? ? ?啥意思呢？如果數據庫里更新消息的狀態失敗了，那么就拋異常退出了，就別投遞到 MQ；如果投遞 MQ ? ? ? ?失敗報錯了，那么就要拋異常讓本地數據庫事務回滾。這倆操作必須得一起成功，或者一起失敗。
? ? ? ?如果上游服務是通知刪除消息，那么可靠消息服務就得刪除這條消息。
②下游服務接收消息
? ? ? ?下游服務就一直等著從 MQ 消費消息好了，如果消費到了消息，那么就操作自己本地數據庫。
? ? ? ?如果操作成功了，就反過來通知可靠消息服務，說自己處理成功了，然后可靠消息服務就會把消息的狀態設置為“已完成”。
③如何保證上游服務對消息的 100% 可靠投遞？
上面的核心流程大家都看完：一個很大的問題就是，如果在上述投遞消息的過程中各個環節出現了問題該怎么辦？
? ? ? ?我們如何保證消息 100% 的可靠投遞，一定會從上游服務投遞到下游服務？別著急，下面我們來逐一分析。
? ? ? ?如果上游服務給可靠消息服務發送待確認消息的過程出錯了，那沒關系，上游服務可以感知到調用異常的，就不用執行下面的流程了，這是沒問題的。
? ? ? ?如果上游服務操作完本地數據庫之后，通知可靠消息服務確認消息或者刪除消息的時候，出現了問題。
? ? ? ?比如：沒通知成功，或者沒執行成功，或者是可靠消息服務沒成功的投遞消息到 MQ。這一系列步驟出了問題怎么辦？
? ? ? ?其實也沒關系，因為在這些情況下，那條消息在可靠消息服務的數據庫里的狀態會一直是“待確認”。
? ? ? ?此時，我們在可靠消息服務里開發一個后臺定時運行的線程，不停的檢查各個消息的狀態。
? ? ? ?如果一直是“待確認”狀態，就認為這個消息出了點什么問題。此時的話，就可以回調上游服務提供的一個接口，問問說，兄弟，這個消息對應的數據庫操作，你執 ? ? ? 行成功了沒啊？
? ? ? ?如果上游服務答復說，我執行成功了，那么可靠消息服務將消息狀態修改為“已發送”，同時投遞消息到 MQ。
? ? ? ?如果上游服務答復說，沒執行成功，那么可靠消息服務將數據庫中的消息刪除即可。
通過這套機制，就可以保證，可靠消息服務一定會嘗試完成消息到 MQ 的投遞。
④如何保證下游服務對消息的 100% 可靠接收？
那如果下游服務消費消息出了問題，沒消費到？或者是下游服務對消息的處理失敗了，怎么辦？
? ? ? ?其實也沒關系，在可靠消息服務里開發一個后臺線程，不斷的檢查消息狀態。
? ? ? ?如果消息狀態一直是“已發送”，始終沒有變成“已完成”，那么就說明下游服務始終沒有處理成功。
? ? ? ?此時可靠消息服務就可以再次嘗試重新投遞消息到 MQ，讓下游服務來再次處理。
只要下游服務的接口邏輯實現冪等性，保證多次處理一個消息，不會插入重復數據即可。
⑤如何基于 RocketMQ 來實現可靠消息最終一致性方案？
在上面的通用方案設計里，完全依賴可靠消息服務的各種自檢機制來確保：
? ? ? ?如果上游服務的數據庫操作沒成功，下游服務是不會收到任何通知。
? ? ? ?如果上游服務的數據庫操作成功了，可靠消息服務死活都會確保將一個調用消息投遞給下游服務，而且一定會確保下游服務務必成功處理這條消息。
通過這套機制，保證了基于 MQ 的異步調用/通知的服務間的分布式事務保障。其實阿里開源的 RocketMQ，就實現了可靠消息服務的所有功能，核心思想跟上面類似。
只不過 RocketMQ 為了保證高并發、高可用、高性能，做了較為復雜的架構實現，非常的優秀。有興趣的同學，自己可以去查閱 RocketMQ 對分布式事務的支持。
3.2、可靠消息最終一致性方案的高可用保障生產實踐
上面那套方案和思想，很多同學應該都知道是怎么回事兒，我們也主要就是鋪墊一下這套理論思想。
如果有高并發場景的，可以用 RocketMQ 的分布式事務支持上面的那套流程都可以實現。大家應該發現了這套方案里保障高可用性最大的一個依賴點，就是 MQ 的高可用性。那如果MQ發生故障時，如何保證 99.99% 的高可用？
任何一種 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 的降級方案會設計的更加的復雜，那就遠遠不是這么簡單可以做到的。
參考地址：
https://www.cnblogs.com/jajian/p/10014145.html
https://www.cnblogs.com/linjiqin/p/9561641.html
總結
以上是生活随笔為你收集整理的TCC分布式实现原理及分布式应用如何保证高可用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 论文浅尝 | AAAI2020 - 基于
- 下一篇： mikechen谈技术人成长的三大原则