引言
這篇說說分布式事務的問題。企業現在的架構都由傳統的架構轉向了微服務架構，如下圖所示:
那么，都不可避免的會遇到跨數據庫調用的，分布式事務問題！
目前，業內解決分布式事務問題，都基本不用JTA這種強一致性的解決方案，基本是采用如下兩套方案
- 基於TCC的事務框架
- 消息隊列
OK，你們先記住兩點
(1)圖中的服務A和服務B，如果是同步調用，要求一起成功，或者一起失敗，那么此時應選用TCC的事務框架，這點我改天另寫一篇，先挖坑！
(2)圖中的服務A和服務B，如果是異步調用，比如服務C先調用服務A后，服務C不用管服務B的執行結果，直接返回，那么這種情況下，應選用消息隊列！這篇文章重點講！
目前為止，大部分文章都講的太復雜了。導致很多新人看完后於是看這篇文章前，你們先忘記你們在其他文章看到的概念，跟着博主的思路走！
正文
先給大家套一個業務場景，也是很常見的一個異步調用場景:
- 支付寶往余額寶轉錢
即將服務A假設為支付寶，服務B假設為余額寶。
於是呢，我們的支付寶往余額寶轉100塊錢是怎么做的呢？
特別容易，借助消息隊列即可，如下圖所示
一致性解決
OK，上面這一版有一個致命的問題！如下所示
事務開始
(1)給支付寶賬戶zhangsan,扣100元
(2)將(給余額寶賬戶zhangsan,加100元)封裝為消息，發送給消息隊列
事務結束
敢問你，如何保證第一步和第二步是在同一個事務里完成的。換句話說，第一步操作的是數據庫，第二步操作的是一個消息隊列，你如何保證這兩步之間的一致性？
記住了，任何涉及到數據庫和中間件之間的業務邏輯操作，都需要考慮二者之間的一致性。比如，你先操作了數據庫，再操作緩存，數據庫和緩存之間一致性如何解決？好吧，如果是博主的鐵粉，應該知道怎么解決了，回到我們的場景。
改變思路，加一張事務表，如下圖所示
注意了，此時事務的內容為
事務開始
(1)給支付寶賬戶zhangsan,扣100元
(2)給事件表插入一條記錄
事務結束
此時是對同一數據庫的兩張表操作，因此可以用數據庫的事務進行保證。
另外，起一個定時程序，定時掃描事務表，發現一個狀態為'UNFINISHED'的事件，就進行封裝為消息，發送到消息中間件，然后將狀態改為'FINISHED'.
冪等性解決
注意了，這一版還存在一個冪等性問題!
仔細看，定時程序做了如下三個操作
(1)定時掃描事務表，發現一個狀態為'UNFINISHED'的事件
(2)將事件信息，封裝為消息，發送到消息中間件
(3)將事件狀態改為'FINISHED'
OK，假設在步驟(2)的時候，發送完消息體，還未執行步驟(3),定時程序陣亡了！然后重啟定時程序，發現剛那個事務的狀態依然為'UNFINISHED'，因此重新發送。這樣，就會出現重復消費問題。因此，冪等性也是需要保證的！
如果是博主的忠實讀者，應該知道，博主曾經寫過一篇《分布式之消息隊列復習精講》，里頭就提到了如何解決冪等性問題。什么？你沒看過這篇？拉出去槍斃！
借用這篇文章里的方案。在消費者端，也維護一個帶主鍵的表，可以選txid為主鍵，如下圖所示
如果一旦出現重復消費，則在事務里直接報出主鍵沖突錯誤，從而保證了冪等性！
面試連環炮
面試官:"你們用了微服務架構么？"
求職者:"用了，用了"
面試官:"怎么解決分布式事務的啊？"
求職者:"我們的服務剛好是異步的場景，所以用消息隊列！"
面試官:"怎么保證一致性和冪等性啊？"
求職者:"嗯，聽我細細說來....."
總結
這篇文章說了微服務架構下，異步服務之間的分布式事務是如何保證的。至於同步服務，博主盡量抓緊寫！