這篇說說分布式事務的問題。企業現在的架構都由傳統的架構轉向了微服務架構，如下圖所示:
那麼，都不可避免的會遇到跨資料庫呼叫的，分布式事務問題！
目前，業內解決分布式事務問題，都基本不用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為主鍵，如下圖所示
如果一旦出現重複消費，則在事務裡直接報出主鍵衝突錯誤，從而保證了冪等性！
面試官:"你們用了微服務架構麼？"
求職者:"用了，用了"
面試官:"怎麼解決分布式事務的啊？"
求職者:"我們的服務剛好是非同步的場景，所以用訊息佇列！"
面試官:"怎麼保證一致性和冪等性啊？"
求職者:"嗯，聽我細細說來....."
分布式一致性 冪等
關於分布式系統的資料一致性問題 一 最近寫了乙個關於 鐵道部購票系統的若干文章 鐵道部新客票系統的設計 一 鐵道部新客票系統的設計 二 鐵道部新客票系統的設計 三 正好遇到乙個博友，諮詢了乙個問題，這個問題正好可以作為分布式系統的資料一致性的簡單例子，當然，這個只是比較簡單的情況 現在先丟擲問題，假...
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...
分布式一致性
分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...