什麼是分布式事務
傳統的事務是基於單資料庫的本地事務，簡單的來說，分布式事務就是實現跨資料庫的事務支援
cap理論
cap理論表面在分布式系統中，最多只能滿足c，a，p中的兩個
既然最多只能選擇兩個，那選擇哪兩個比較合適呢？對於乙個分布式系統來說，可用性和分割槽容錯性是必須要滿足的。對於可用性，如果乙個系統可用性都打不到，那麼這個系統是沒有意義的；分布式系統設計的目的就是提供多個子系統防止單個系統出現故障的情況，所以分割槽容錯性是分布式系統的跟本，如果分割槽容錯性都不滿足，那麼分布式系統將失去意義
base理論
在cap理論中我們犧牲了一致性來換取可用性和分割槽容錯性；但是犧牲一致性不是指完全放棄資料一致性，而是使用弱一致替換強一致；下面介紹一下base理論：
酸鹼平衡
在單資料庫事務中，我們使用acid來保證資料的強一致性，在分布式系統中只要遵循base理論即可；但是在不同的場景下對一致性的要求是不一樣的，例如交易場景就要求強一致性，遵循acid理論；對於註冊成功後傳送簡訊驗證碼這樣的業務場景不需要強一致性，遵循base理論即可。所以我們要根據不同的業務場景在acid和base之間尋求平衡
在我的專案中order模組用來處理訂單，下完訂單後，在product模組中執行相應的扣庫存的操作；為了方便描述，我們把order模組稱為系統a，下訂單操作為任務a；product模組為系統b，扣庫存操作為任務b
系統設計
如果任務a處理失敗
如果任務a處理失敗，那麼需要進入回滾流程
新的問題
上面所介紹的commit和rollback都屬於理想情況，但在實際系統中，commit和rollback指令都有可能在傳輸途中丟失。那麼當出現這種情況的時候，訊息中介軟體是如何保證資料一致性呢？——答案就是超時詢問機制。
系統a除了實現正常的業務流程外，還需提供乙個事務詢問的介面，供訊息中介軟體呼叫。當訊息中介軟體收到一條事務型訊息後便開始計時，如果到了超時時間也沒收到系統a發來的commit或rollback指令的話，就會主動呼叫系統a提供的事務詢問介面詢問該系統目前的狀態。該介面會返回三種結果：
投遞過程的可靠性保證
我們知道當上游系統a發出commit請求之後認為事務已經完成，便可以處理其他的任務了；那麼訊息中介軟體是怎麼保證訊息一定會被下游系統b成功消費呢？這是使用訊息中介軟體投遞過程的可靠性來保證的
訊息中介軟體向系統b投遞完訊息後便進入阻塞等待狀態，如果訊息在傳遞過程中丟失或者訊息的確認應答在返回途中丟失，那麼訊息中介軟體在等待超時後會重新投遞直到訊息被系統b成功消費為止
為什麼是重新投遞而不是回滾
這就涉及到整套分布式事務系統的實現成本問題。如果回滾的話，系統a就要提供回滾介面，這增加了開發成本，業務系統的複雜度也會隨之提高
非同步與同步
上游系統a向訊息中介軟體提交完訊息後便可以去做別的事情。然而訊息中介軟體將訊息投遞給下游系統b後，它會阻塞等待直到下游系統返回b確認應答。為什麼要這麼設計呢？
首先，上游系統和訊息中介軟體之間採用非同步通訊是為了提高系統併發度。業務系統直接和使用者打交道，使用者體驗尤為重要，因此這種非同步通訊方式能夠極大程度地降低使用者等待時間；
下游系統與訊息中介軟體採用同步雖然降低系統併發度，但實現成本較低。在對併發度要求不是很高或者伺服器資源較為充裕的情況下，我們可以選擇使用同步來降低系統的複雜度
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式事務六 常規MQ佇列
分布式事務二 分布式事務處理三 分布式事務四 基於可靠訊息的最終一致性 分布式事務五 基於可靠訊息的最終一致性 異常流程 分布式事務六 常規mq佇列 分布式事務七 冪等性設計 分布式事務八 可靠訊息最終一致性方案 分布式事務九 基於可靠訊息的最終一致性 分布式事務10 最大努力通知形勢 柔性事務解決...
MQ 分布式事務 微服務應用
以支付 電商下單為例子。乙個電商系統包含了好幾大類模組，就比如有使用者模組 商品模組 庫存模組 訂單模組 支付模組 物流模組，活動模組等，以下就先列舉幾個最基礎常見的模組 使用者模組 商品模組 庫存模組 訂單模組 支付模組 使用者流程如下 如果系統規模較小，資料表都在乙個資料庫例項上，專案服務端也都...