40、瞭解分散式事務方案嗎？你們都咋做的？有啥坑？
1、面試題
分散式事務瞭解嗎？你們如何解決分散式事務問題的？
2、面試官心裡分析
只要聊到你做了分散式系統，必問分散式事務，你對分散式事務一無所知的話，確實會很坑，你起碼得知道有哪些方案，一般怎麼來做，每個方案的優缺點是什麼。
現在面試，分散式系統成了標配，而分散式系統帶來的分散式事務也成了標配了。因為你做系統肯定要用事務吧，那你用事務的話，分散式系統之後肯定要用分散式事務吧。呵呵。先不說你搞過沒有，起碼你得明白有哪幾種方案，每種方案可能有啥坑？比如TCC方案的網路問題、XA方案的一致性問題。
3、面試題剖析
（1）兩階段提交方案/XA方案
也叫做兩階段提交事務方案，這個舉個例子，比如說咱們公司裡經常tb是吧（就是團建），然後一般會有個tb主席（就是負責組織團建的那個人）。
tb，team building，團建
第一個階段，一般tb主席會提前一週問一下團隊裡的每個人，說，大傢伙，下週六我們去滑雪+燒烤，去嗎？這個時候tb主席開始等待每個人的回答，如果所有人都說ok，那麼就可以決定一起去這次tb。如果這個階段裡，任何一個人回答說，我有事不去了，那麼tb主席就會取消這次活動。
第二個階段，那下週六大家就一起去滑雪+燒烤了
所以這個就是所謂的XA事務，兩階段提交，有一個事務管理器的概念，負責協調多個數據庫（資源管理器）的事務，事務管理器先問問各個資料庫你準備好了嗎？如果每個資料庫都回復ok，那麼就正式提交事務，在各個資料庫上執行操作；如果任何一個數據庫回答不ok，那麼就回滾事務。
這種分散式事務方案，比較適合單塊應用裡，跨多個庫的分散式事務，而且因為嚴重依賴於資料庫層面來搞定複雜的事務，效率很低，絕對不適合高併發的場景。如果要玩兒，那麼基於spring + JTA就可以搞定，自己隨便搜個demo看看就知道了。
這個方案，我們很少用，一般來說某個系統內部如果出現跨多個庫的這麼一個操作，是不合規的。我可以給大家介紹一下， 現在微服務，一個大的系統分成幾百個服務，幾十個服務。一般來說，我們的規定和規範，是要求說每個服務只能操作自己對應的一個數據庫。
如果你要操作別的服務對應的庫，不允許直連別的服務的庫，違反微服務架構的規範，你隨便交叉胡亂訪問，幾百個服務的話，全體亂套，這樣的一套服務是沒法管理的，沒法治理的，經常資料被別人改錯，自己的庫被別人寫掛。
如果你要操作別人的服務的庫，你必須是通過呼叫別的服務的介面來實現，絕對不允許你交叉訪問別人的資料庫！
兩階段提交方案.png
（2）TCC方案
TCC的全程是：Try、Confirm、Cancel。
這個其實是用到了補償的概念，分為了三個階段：
1）Try階段：這個階段說的是對各個服務的資源做檢測以及對資源進行鎖定或者預留；
2）Confirm階段：這個階段說的是在各個服務中執行實際的操作；
3）Cancel階段：如果任何一個服務的業務方法執行出錯，那麼這裡就需要進行補償，就是執行已經執行成功的業務邏輯的回滾操作。
給大家舉個例子吧，比如說跨銀行轉賬的時候，要涉及到兩個銀行的分散式事務，如果用TCC方案來實現，思路是這樣的：
1）Try階段：先把兩個銀行賬戶中的資金給它凍結住就不讓操作了；
2）Confirm階段：執行實際的轉賬操作，A銀行賬戶的資金扣減，B銀行賬戶的資金增加；
3）Cancel階段：如果任何一個銀行的操作執行失敗，那麼就需要回滾進行補償，就是比如A銀行賬戶如果已經扣減了，但是B銀行賬戶資金增加失敗了，那麼就得把A銀行賬戶資金給加回去。
這種方案說實話幾乎很少用人使用，我們用的也比較少，但是也有使用的場景。因為這個事務回滾實際上是嚴重依賴於你自己寫程式碼來回滾和補償了，會造成補償程式碼巨大，非常之噁心。
比如說我們，一般來說跟錢相關的，跟錢打交道的，支付、交易相關的場景，我們會用TCC，嚴格嚴格保證分散式事務要麼全部成功，要麼全部自動回滾，嚴格保證資金的正確性，在資金上出現問題
比較適合的場景：這個就是除非你是真的一致性要求太高，是你係統中核心之核心的場景，比如常見的就是資金類的場景，那你可以用TCC方案了，自己編寫大量的業務邏輯，自己判斷一個事務中的各個環節是否ok，不ok就執行補償/回滾程式碼。
而且最好是你的各個業務執行的時間都比較短。
但是說實話，一般儘量別這麼搞，自己手寫回滾邏輯，或者是補償邏輯，實在太噁心了，那個業務程式碼很難維護。
TCC方案.png
（3）本地訊息表
國外的ebay搞出來的這麼一套思想
這個大概意思是這樣的：
1）A系統在自己本地一個事務裡操作同時，插入一條資料到訊息表；
2）接著A系統將這個訊息傳送到MQ中去；
3）B系統接收到訊息之後，在一個事務裡，往自己本地訊息表裡插入一條資料，同時執行其他的業務操作，如果這個訊息已經被處理過了，那麼此時這個事務會回滾，這樣保證不會重複處理訊息；
4）B系統執行成功之後，就會更新自己本地訊息表的狀態以及A系統訊息表的狀態；
5）如果B系統處理失敗了，那麼就不會更新訊息表狀態，那麼此時A系統會定時掃描自己的訊息表，如果有沒處理的訊息，會再次傳送到MQ中去，讓B再次處理；
6）這個方案保證了最終一致性，哪怕B事務失敗了，但是A會不斷重發訊息，直到B那邊成功為止。
這個方案說實話最大的問題就在於嚴重依賴於資料庫的訊息表來管理事務啥的？這個會導致如果是高併發場景咋辦呢？咋擴充套件呢？所以一般確實很少用。
本地訊息表方案.png
（4）可靠訊息最終一致性方案
這個的意思，就是乾脆不要用本地的訊息表了，直接基於MQ來實現事務。比如阿里的RocketMQ就支援訊息事務。
大概的意思就是：
1）A系統先發送一個prepared訊息到mq，如果這個prepared訊息傳送失敗那麼就直接取消操作別執行了；
2）如果這個訊息傳送成功過了，那麼接著執行本地事務，如果成功就告訴mq傳送確認訊息，如果失敗就告訴mq回滾訊息；
3）如果傳送了確認訊息，那麼此時B系統會接收到確認訊息，然後執行本地的事務；
4）mq會自動定時輪詢所有prepared訊息回撥你的介面，問你，這個訊息是不是本地事務處理失敗了，所有沒傳送確認訊息？那是繼續重試還是回滾？一般來說這裡你就可以查下資料庫看之前本地事務是否執行，如果回滾了，那麼這裡也回滾吧。這個就是避免可能本地事務執行成功了，別確認訊息傳送失敗了。
5）這個方案裡，要是系統B的事務失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要麼就是針對重要的資金類業務進行回滾，比如B系統本地回滾後，想辦法通知系統A也回滾；或者是傳送報警由人工來手工回滾和補償。
這個還是比較合適的，目前國內網際網路公司大都是這麼玩兒的，要不你舉用RocketMQ支援的，要不你就自己基於類似ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。
可靠訊息最終一致性方案.png
（5）最大努力通知方案
這個方案的大致意思就是：
1）系統A本地事務執行完之後，傳送個訊息到MQ；
2）這裡會有個專門消費MQ的最大努力通知服務，這個服務會消費MQ然後寫入資料庫中記錄下來，或者是放入個記憶體佇列也可以，接著呼叫系統B的介面；
3）要是系統B執行成功就ok了；要是系統B執行失敗了，那麼最大努力通知服務就定時嘗試重新呼叫系統B，反覆N次，最後還是不行就放棄；
最大努力通知方案.png
（6）你們公司是如何處理分散式事務的？
這個，說真的，確實我們這個課程沒法帶著大家來實戰，因為定位不是這個。但是如果你真的被問到，你可以這麼說，我們某某特別嚴格的場景，用的是TCC來保證強一致性；然後其他的一些場景基於了阿里的RocketMQ來實現了分散式事務。
你找一個嚴格資金要求絕對不能錯的場景，你可以說你是用的TCC方案；如果是一般的分散式事務場景，訂單插入之後要呼叫庫存服務更新庫存，庫存資料沒有資金那麼的敏感，可以用可靠訊息最終一致性方案
友情提示一下，rocketmq 3.2.6之前的版本，是可以按照上面的思路來的，但是之後介面做了一些改變，我這裡不再贅述了。
當然如果你願意，你可以參考可靠訊息最終一致性方案來自己實現一套分散式事務，比如基於rabbitmq來玩兒。
4、昨天學員給我提的一個問題
老師，我們現在想保證我們的某個系統非常的可靠，任何一個數據都不能錯，我們用的是微服務架構，幾十個服務。結果我們一盤點，發現，如果到處都要搞的話，一個系統要做幾十個分散式事務出來。
我們的經驗，我帶幾十人的team，最大的一個專案，起碼幾百個服務，複雜的分散式大型系統，裡面其實也沒幾個分散式事務。
你其實用任何一個分散式事務的這麼一個方案，都會導致你那塊兒程式碼會複雜10倍。很多情況下，系統A呼叫系統B、系統C、系統D，我們可能根本就不做分散式事務。如果呼叫報錯會列印異常日誌。
每個月也就那麼幾個bug，很多bug是功能性的，體驗性的，真的是涉及到資料層面的一些bug，一個月就幾個，兩三個？如果你為了確保系統自動保證資料100%不能錯，上了幾十個分散式事務，程式碼太複雜；效能太差，系統吞吐量、效能大幅度下跌。
99%的分散式介面呼叫，不要做分散式事務，直接就是監控（發郵件、發簡訊）、記錄日誌（一旦出錯，完整的日誌）、事後快速的定位、排查和出解決方案、修復資料。
每個月，每隔幾個月，都會對少量的因為程式碼bug，導致出錯的資料，進行人工的修復資料，自己臨時動手寫個程式，可能要補一些資料，可能要刪除一些資料，可能要修改一些欄位的值。
比你做50個分散式事務，成本要來的低上百倍，低幾十倍
trade off，權衡，要用分散式事務的時候，一定是有成本，程式碼會很複雜，開發很長時間，效能和吞吐量下跌，系統更加複雜更加脆弱反而更加容易出bug；好處，如果做好了，TCC、可靠訊息最終一致性方案，一定可以100%保證你那快資料不會出錯。
1%，0.1%，0.01%的業務，資金、交易、訂單，我們會用分散式事務方案來保證，會員積分、優惠券、商品資訊，其實不要這麼搞了。