- 訊息詳解 -
在 《柔性事務之tcc詳解》 和《柔性事務之saga詳解》兩文中我們詳細剖析了柔性事務的第乙個分支補償型事務。在《剛性事務總結和柔性事務概述》中我們介紹過的柔性事務包含補償型事務和通知型事務。
通知型事務主要包含事務訊息和最大努力通知型分布式事務兩個組成。通知型事務的核心思想是通過mq來通知其他事務參與者自己事務的執行狀態。mq元件的引入有效的將事務參與者解耦開，各個參與者都可以非同步執行，所以通知型事務又稱為非同步事務。
事務訊息的難度在於服務本地事務和投遞訊息的一致性保障。目前業界解決這個一致性的方案有兩個分支：
- 基於mq自身的事務訊息方案 -
1、事務發起方首先傳送prepare訊息到mq；
2、在傳送prepare訊息成功後執行本地事務；
3、根據本地事務執行結果返回commit或者是rollback；
4、如果訊息是rollback, mq將刪除該prepare訊息不進行下發，如果是commit訊息，mq將會訊息傳送給consumer端；
5、如果執行本地事務過程中，執行端掛掉，或者超時，mq伺服器端將不停的詢問producer來獲取事務狀態；
6、consumer端的消費成功機制有mq保證
mq事務訊息方案因為使用了半訊息機制，對業務頁具有比較大侵入性，有以下注意點：
1、 業務方呼叫半訊息，並提供對應的回查方法；
2、 mq提要提供半訊息機制，並定期掃瞄長期半訊息，對訊息生產者進行回查確認事務。
3、 消費方需要進行冪等消費。
- 基於bd的本地訊息表方案 -
有時候我們目前的mq元件並不支援事務訊息，或者我們想盡量少的侵入業務方。這時我們需要另外一種方案「基於db本地訊息表「，流程圖如下：
1、 業務方：直接利用本地事務，將業務資料和事務訊息直接寫入資料庫。
2、 投遞執行緒：使用專門的投遞工作執行緒進行事務訊息投遞到mq，根據投遞ack去刪除事務訊息表記錄
本地事務訊息表的優勢在於方案的通用性，無需提供回查方法，進一步減少的業務的侵入。在某些場景下，還可以進一步利用註解等形式進行解耦，有可能實現無業務**侵入式的實現。我們上面說了本地事務訊息表的基本理論，那麼如果要設計乙個高可用的企業級本地事務訊息表方案，就要考慮更多的事情，在效能上做更大的優化，降低更多的重複投遞率。以下是乙個企業級事務訊息的設計流程圖：
1、 事務訊息服務：提供通用投遞介面，用於保證事務訊息的本地寫入，並將事務訊息寫入事務記憶體佇列。
2、 使用投遞執行緒池，繼續事務記憶體佇列投遞派發分配。投遞工作執行緒只投遞本例項擁有的事務訊息，投遞失敗執行緒列入時間輪佇列；重試機制使用失敗擋位區分，預設提供6檔：5s、10s、15s、20s、25s、30s。
3、 時間輪執行緒進行60秒轉動，將到期的失敗事務訊息重入事務記憶體佇列.
4、 因為我們的事務訊息服務是無狀態化的多例項存在，所以需要乙個持鎖線程進行主節點競爭強鎖，處理一些額外的工作。
5、 因為我們的事務記憶體佇列是記憶體級，不可避免面臨重啟等情況下的資料丟失。這時需要事務訊息服務主節點進行定期掃表，將長期未投遞的事務訊息取出放入事務訊息服務。
6、 事務訊息服務主節點還有乙個清理執行緒，專門用於將已處理成功的歷史事務訊息進行歸檔清理，降低db的資料量。
- 總結 -
咱們上面介紹了mq事務訊息方案和db本地訊息表方案，這兩個方案有什麼區別呢？
1、 mq事務訊息方案
a) 需要mq支援半訊息機制或者類似特性，在重複投遞上具有比較好的去重處理
b) 需要業務方進行改造，提供對應的本地操作成功回查功能。具有比較大的業務侵入性。
2、 db本地事務訊息表方案
a) 使用了資料庫來儲存事務訊息，降低了對mq的需求，但是增加了儲存成本。
b) 事務訊息使用了非同步投遞，增大了訊息重複投遞的可能性。
我們說了兩種事務訊息的特性和優劣性，我們在總結下事務訊息的共性。
1、 事務訊息都依賴mq進行事務通知，所以都是非同步的。
2、 事務訊息在投遞方都是存在重複投遞的可能，需要有配套的機制去降低重複投遞率，實現更友好的訊息投遞去重。
3、 事務訊息的消費方，因為投遞重複的無法避免，因此需要進行消費去重設計或者服務冪等設計。
事務 分布式事務
事務 邏輯上的一組操作，要麼都成功要麼都失敗 事務的四個特性 acid 原子性，一致性，隔離性，永續性 事務的隔離級別 讀未提交 產生髒讀 讀已提交 不可重複讀 可重複讀 幻讀 mysql預設 序列化讀 效能最低 傳播行為 7個 七種傳播行為 required 支援當前事務，如果不存在，就新建乙個 ...
分布式事務（二）訊息事務方案
步驟1 2是在本地事務執行之前，服務a負責生成乙個全域性唯一的事務id，並在訊息管理服務上註冊乙個訊息。這一步如果失敗，整個事務被判定失敗，不會出現資料不一致問題。這兩個步驟主要是為了容錯，後續當步驟4如果沒有執行，訊息管理服務會定時撈出未提交的事務，反查服務a的介面，確認事務是提交還是取消。提交則...
分布式事務一致性，事務補償實戰
一 事務記錄補償表設計 三 業務補償函式 override public void compensation bidpaymentdetailconfirmrecord confirmrecord,providerusersession usersession throws exception bi...