1. 分布式事務原理解析
1.1. TCC分布式事務
了解過TCC分布式事務的都知道它有三個階段：try，confirm，cancel，但很多文章就只有原理圖，和對原理圖的解釋，看一遍也留不下印象，這里用實際場景舉個例子，說明TCC分布式事務原理
- try階段：假設我們又訂單系統，它需要調用庫存和積分系統，try階段我們進行的是預處理，比如下單1個商品，在try操作中，我們在庫存表設置個凍結字段，表示凍結1個商品，商品的存量先不扣除，而積分表同樣添加個預增加積分字段，添加個預積分比如10
- confirm階段：我們為什么要經歷try階段？，為了盡可能的保證各個系統都是正常工作的，數據庫，服務都沒有掛掉，資源沒有不足，則可以最大程度上保證confirm階段能正確執行，confirm階段也就是正式的扣除庫存和增加積分
- cancel階段：若try階段執行錯誤，則會對前面已經執行的try階段的系統執行cancel操作，也就是反向SQL回滾，凍結的商品-1，預積分-10。到這里有沒有疑問？我首先想到的是若confirm或cancel操作再執行失敗怎么辦？這里就要由TCC分布式事務框架保證了，它會記錄事務活動日志，再confirm或cancel失敗后不斷嘗試調用confirm和cancel的邏輯，所以這里需要開發者自己保證，你的SQL是正確的
TCC分布式框架推薦：ByteTCC，tcc-transaction，himly
1.2. 最終一致性分布式事務
1.2.1. 原理
最終一致性方案一般都是有消息中間件來完成的，核心流程如上圖所示
- 假設上游服務為服務A，可靠消息服務為服務B，下游服務為服務C，首選A發送請求給B表示我將要發消息了，你准備下，然后B記錄下待確認的數據；
- A服務正式走完本地數據庫邏輯，在發送B確認消息，說我執行完了，你可以確認了，然后B就更新消息的狀態為已發送，並把消息發送給MQ
- 此時服務C訂閱了MQ，接收到B通過MQ發送過來的消息，並執行本地數據庫操作，在執行完畢后手動ack確認消費完畢，這就走完了全部流程
1.2.2. 問題
下面來考慮這中間會有什么問題了，為什么這樣能保證分布式事務的最終一致性？
- 首先是服務A調用B過程中若不成功或者服務B若沒保存待確認消息，那就直接返回的就是失敗，還沒有操作數據庫，所以沒有影響
- A操作數據庫和發送確認消息，我們需要放在同一個本地事務中，確保同時成功或失敗，這樣成功了當然沒問題，失敗了呢？因為B服務的數據庫已經存在待確認消息，可以在B服務開條線程定時判斷待確認消息，若發現待確認消息很久沒被確認，則主動向A發起請求，判斷該操作是否成功了？成功則改狀態為已確認，繼續執行，失敗則刪掉該記錄
- B到MQ的過程，若是失敗了，MQ掛了之類的，我們可以在B服務后台起個線程，定時判斷已確認的消息，在一定時間后是否變成已發送，沒有發送的再主動發送
- 這樣后就只剩MQ到C服務了，MQ有重試機制，所以只要業務邏輯沒問題，就可以保證最終一致性（這個過程中需要保證MQ到C服務，接口方法需要冪等性）
- 上述流程需要特別注意的一個點就是MQ，我們需要保證MQ的高可用，否則一旦全部MQ宕機，依賴MQ的分布式事務都不能完成
1.2.3. MQ掛了怎么辦
越大的公司，考慮的就越多，任何組件都可能掛掉，MQ如果就一個集群，就要考慮這個集群壓力過大到爆掉了怎么辦？資金雄厚並發壓力大的公司可以直接搞再搞一套備用的，當MQ請求不通后，立即自動切換到備用MQ集群，當然這肯定會造成資源的浪費，畢竟要再搞一套MQ不運行一直放那里，這里再給出一套參考方案（如果你們有redis集群的話）
- redis有種隊列的數據結構，它是可以用來臨時充當消息隊列的，所以這里要討論的是，如果用redis當備用方案需要考慮什么問題？
- 通知機制：當MQ掛了，我們需要將所有用到MQ事務的系統都切換到備用redis方案，所以我們要有個通知機制，本來嗎這個類似廣播模式的通知應該是MQ完成的，但沒了MQ，我們要有其它方案，比如zookeeper的watch機制，zk有監聽機制可以通知監聽它節點的系統，打開降級開關，達到通知其它系統的效果
- 消息讀取熱點問題：我們把消息放到redis的隊列會有個對應的key，我們不能把所有消息都放一個key的value中，這樣會導致這個value數據量過大；所以這里給出方案：划分上百個隊列，對消息hash后放入這些隊列，這樣盡可能的把消息分散到不同的key
- 故障的恢復：當我們把MQ恢復過來時，我們也要通知系統，該切換回來了，這個該怎么做呢？可以開啟一個線程，每隔一段時間嘗試給MQ投遞一個消息查看是否恢復，若恢復了，就可以再次通過zookeeper來關閉降級開關