這篇說說分布式事務的問題。企業現在的架構都由傳統的架構轉向了微服務架構，如下圖所示:
那麼，都不可避免的會遇到跨資料庫呼叫的，分布式事務問題！
目前，業內解決分布式事務問題，都基本不用jta這種強一致性的解決方案，基本是採用如下兩套方案
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為主鍵，如下圖所示
如果一旦出現重複消費，則在事務裡直接報出主鍵衝突錯誤，從而保證了冪等性！
面試官:"你們用了微服務架構麼？"
求職者:"用了，用了"
面試官:"怎麼解決分布式事務的啊？"
求職者:"我們的服務剛好是非同步的場景，所以用訊息佇列！"
面試官:"怎麼保證一致性和冪等性啊？"
求職者:"嗯，聽我細細說來....."
這篇文章說了微服務架構下，非同步服務之間的分布式事務是如何保證的。至於同步服務，博主盡量抓緊寫！
基於訊息佇列和訊息應用狀態處理分布式事務
由於資料量的巨大，大部分web應用都需要部署很多個資料庫例項。這樣，有些使用者操作就可能需要去修改多個資料庫例項中的資料。傳統的解決方法是使用分布式事務保證資料的全域性一致性，經典的方法是使用兩階段提交協議。長期以來，分布式事務提供的優雅的全域性acid保證麻醉了應用開發者的心靈，很多人都不敢越雷池...
用訊息佇列和訊息應用狀態表來消除分布式事務
由於資料量的巨大，大部分web應用都需要部署很多個資料庫例項。這樣，有些使用者操作就可能需要去修改多個資料庫例項中的資料。傳統的解決方法是使用分布式事務保證資料的全域性一致性，經典的方法是使用兩階段提交協議。長期以來，分布式事務提供的優雅的全域性acid保證麻醉了應用開發者的心靈，很多人都不敢越雷池...
用訊息佇列和訊息應用狀態表來消除分布式事務
由於資料量的巨大，大部分web應用都需要部署很多個資料庫例項。這樣，有些使用者操作就可能需要去修改多個資料庫例項中的資料。傳統的解決方法是使用分布式事務保證資料的全域性一致性，經典的方法是使用兩階段提交協議。長期以來，分布式事務提供的優雅的全域性acid保證麻醉了應用開發者的心靈，很多人都不敢越雷池...