一 序
本文屬於奈學教育rocketmq學習筆記。主講老師陳東。
這節課聽了半截，後來的pdf也找不到了。
業務場景
1、用戶下單
1）創建訂單+減庫存
2、發佈或更新商品信息
1）寫商品庫+更新外置索引
二 事務消息實現原理
2.1分佈式事務
1、強一致
1）一致性協議
2、兩階段提交2PC
3、三階段提交3PC
4、落地方案 => XA規範
1）資源管理器=> 事務參與者
2）事務管理器=> 事務協調者
5、柔性事務
1）最終一致性方案
2）TCC(Try-Confirm-Cancel)
3）SAGA 模型
a:一個分佈式事務拆分爲多個本地事務
b:本地事務都有相應的執行模塊和補償模塊
c:事務管理器負責在事務失敗時調度執行補償邏輯
上面的網上很多文章，就不展開了。
6、事務消息
1）簡化了分佈式事務模型
2）對業務友好
相當於=RPC+事務消息
三 事務消息機制
兩階段提交
a: 發送半消息
b:執行本地事務
c:發送Commit/Rollback
d:提供回查接口
四、事務消息原理
1、半消息主題
1）HALF 消息：RMQ_SYS_TRANS_HALF_TOPIC(臨時存放消息信息)
a: 事務消息替換主題，保存原主題和隊列信息
b:半消息對Consumer不可見,不會被投遞
2）OP 消息：RMQ_SYS_TRANS_OP_HALF_TOPIC(記錄二階段操作)
a:Rollback:只做記錄
b:Commit:根據備份信息重新構造消息並投遞
3）回查
a:對比HALF消息和OP消息進行回查
RocketMq事務消息是保證事務的最終一致性，從上面的介紹可以看到，半消息標記爲“暫時不能投遞”的狀態，是特殊的隊列。
消息回查，由於某些特殊原因，如網絡抖動，生產者應用重啓，可能導致某條消息的二次確認丟失，而broker會不定時的掃描某條長期處於半消息狀態的消息，此時會主動向生產者發送詢問該條消息的最終狀態，(commit或者rollBack)，即對該消息進行回查，這個是broker自動爲我們做的，默認時間間隔是1分鐘。
4） 缺點
需要業務方提供回查接口,對業務侵入較大。
這裏老師講了一個實現方式：
1）通過客戶端實現
2）事務消息表記錄發消息事件
3）本地事務保證業務數據與寫消息表原子性
4）事務管理器維護事務消息表
掃庫發送、清理。