事務訊息本質上解決的問題是業務系統與訊息系統之間的事務問題（跨系統分布式事務），其基本原理即兩階段提交以及最終一致性保障。最近看了下阿里雲mns事務訊息的實現原理，介紹的蠻簡潔透徹的，對了解分布式事務實現原理挺有幫助，在閱讀本文前推薦大家先仔細閱讀下阿里雲"mns事務訊息"一文。
有時候我們需要實現本地操作和訊息傳送的事務一致性功能。即：訊息傳送成功，則本地操作成功；反之，如果訊息傳送失敗，本地操作失敗（成功也需要rollback）。保證不出現操作成功但訊息傳送失敗；或者操作失敗但訊息傳送成功的情況；另外，消費端，我們也希望訊息一定被成功處理一次，不會因為訊息端程式崩潰而導致訊息沒有成功處理，進而需要人工重置消費進度。
利用訊息服務mns的延遲訊息功能來實現。
a.讀取操作日誌佇列超時未確認日誌這個過程需要注意到，我們務必保證在presendmessage沒得到最終確認之前不被消費者獲取到，因此需要將傳送的lifetime小於delaytime。b.檢查事務結果
c.如果檢查得到事務已經成功，則提交訊息（重複提交無***，同一控制代碼的訊息只能成功提交一次）
d.確認操作日誌
訊息服務提供至少保證消費一次的特性，只要步驟8不成功，訊息在一段時間後可以繼續可見，被當前消費者或者其他消費者處理。
訊息傳送和接收處理狀態以及操作日誌都在訊息服務端，訊息服務本身具備高可靠和高可用的特點，所以只要網路恢復，事務可以繼續，能保證只要生產者：操作成功，則消費者一定能夠拿到訊息並處理成功；或操作失敗, 則消費者收不到訊息的最終一致性。
看到這裡也許你有疑問，為什麼要將過程切分成兩階段提交？我們先假設如果採用一次提交的策略，很顯然這次提交的切入點只能存在於①本地事務開始之前②本地事務中③本地事務結束之後，那麼先看這三個切入點各自存在什麼問題。
」單次提交「遇到的主要問題是：無法保障本地事務與訊息被接受到的時序問題（或者說兩個分布式事務的時序）以及資料的一致性問題。再回到」兩階段提交「，兩階段提交能解決這兩個問題嗎？兩階段提交的確認操作是在本地事務完成之後（這個類似於③），因此其能夠解決時序問題，但是如果這個確認操作執行的過程中發生了宕機等情況導致確認操作失敗，依然會導致資料不一致問題。
mns通過延遲訊息機制實現了兩階段提交，其如何保證資料一致性問題呢？一般我們的策略都是通過操作流水來進行補償以達到資料的最終一致性，同樣的mns也是基於這個原理實現。
通過建立對oplog的監聽，我們能夠確保事務的最終一致性嗎？回答這個問題前，我們先看這個問題的本質：最終、一致性。
最終一致性問題的產生是由於發生了一些不可預期的問題，導致乙個事務被提交（回滾），但訊息沒被commit（rollback）。我們通過oplog來追溯那些沒有得到最終確認的訊息並進行補償（最終），並且通過檢查本地事務的狀態來確認這次補償是commit或者是rollback（一致性）。正是基於這個補償的策略，mns事務訊息解決了"兩階段提交"所遺留的一致性問題，但這個過程中我們需要注意幾個細節：
上面囉嗦的寫了一堆，看到這我們不妨對思考下mns事務訊息解決的是業務系統(本地事務)與訊息中介軟體之間的事務協同問題，如果是兩個業務系統之間的分布式事務如何實現？
好吧，如果堅持看到這，你可能覺得我標題黨了...那麼我建議你再讀一下」mns事務訊息「一文。
訊息佇列實現分布式事務
訊息佇列中的 事務 主要解決的是訊息生產者和訊息消費者的資料一致性問題。電商下單步驟 1 生成訂單 2 刪除購物車 在分布式系統中，任何乙個步驟都有可能失敗，可能出現訂單資料與購物車資料不一致的情況，比如說 1 建立了訂單，沒有清理購物車 2 訂單沒建立成功，購物車裡面的商品卻被清掉了。訂單系統給訊...
分布式事務（二）訊息事務方案
步驟1 2是在本地事務執行之前，服務a負責生成乙個全域性唯一的事務id，並在訊息管理服務上註冊乙個訊息。這一步如果失敗，整個事務被判定失敗，不會出現資料不一致問題。這兩個步驟主要是為了容錯，後續當步驟4如果沒有執行，訊息管理服務會定時撈出未提交的事務，反查服務a的介面，確認事務是提交還是取消。提交則...
分布式柔性事務之事務訊息詳解
訊息詳解 在 柔性事務之tcc詳解 和 柔性事務之saga詳解 兩文中我們詳細剖析了柔性事務的第乙個分支補償型事務。在 剛性事務總結和柔性事務概述 中我們介紹過的柔性事務包含補償型事務和通知型事務。通知型事務主要包含事務訊息和最大努力通知型分布式事務兩個組成。通知型事務的核心思想是通過mq來通知其他...