【原創】老生常談——利用訊息佇列處理分散式事務
引言
這篇說說分散式事務的問題。企業現在的架構都由傳統的架構轉向了微服務架構，如下圖所示:
那麼，都不可避免的會遇到跨資料庫呼叫的，分散式事務問題！
目前，業內解決分散式事務問題，都基本不用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為主鍵，如下圖所示
如果一旦出現重複消費，則在事務裡直接報出主鍵衝突錯誤，從而保證了冪等性！
面試連環炮
面試官:"你們用了微服務架構麼？"
求職者:"用了，用了"
面試官:"怎麼解決分散式事務的啊？"
求職者:"我們的服務剛好是非同步的場景，所以用訊息佇列！"
面試官:"怎麼保證一致性和冪等性啊？"
求職者:"嗯，聽我細細說來....."
總結
這篇文章說了微服務架構下，非同步服務之間的分散式事務是如何保證的。至於同步服務，博主儘量抓緊寫！
作者：孤獨煙 出處： http://rjzheng.cnblogs.com/