一、背景
事務消息的定義：
- 在RabbitMQ中的事務消息是指多條消息的事務原子性
- 分佈式事務，本地事務和消息中間件的一致性
本篇主要說的是本地事務和消息中間件的一致性，即分佈式事務中的可靠性消息解決方案
二、分佈式事務的理論
- CAP
- 一致性（Consistency）
- 可用性（Availability）
- 分區容錯性（Partition tolerance）
- BASE
- Basically Available（基本可用）
- Soft state（軟狀態）
- Eventually consistent（最終一致性）
分佈式事務解決思路都是BASE柔性事務，使用重試策略保證數據的最終一致性，在同一時間片內數據可能不一致，強一致性場景需要考慮一致性讀
三、事務消息的實現
市面已經存在事務消息開源的實現方案：
- QMQ基於Spring平臺事務管理器的JDBC事務方案 通過代理客戶端，保存事務消息信息到DB，與本地事務一起提交，異步和補償定時任務發送消息中間件中，保證原子性，犧牲性能保證消息可靠性，場景在於可靠性要求高的交易業務。
如果業務對於消息丟失率容忍，可以優化爲Redis存儲，在發送失敗時才異步放入redis重試隊列中，這樣性能可以大大提高
- RocketMQ兩段消息事務消息方案
通過改寫Topic和Queue將消息發送事務消息halfQueue中，確認後修改OpQueue提交，定時任務發送回生產者回查提交狀態Commit或者Rollback，保證事務消息在消費者的可見性
缺點：
- 生產者業務有侵入，需要自己實現回查方法
- 對性能有一定影響，需要發送兩次消息，多一個queue
不侵入方案，可以提供模板方案統一保存在
Rds或者NoSql中消息Id的Commit狀態，回查方法直接查看狀態
第二種方案只有RocketMQ提供了實現，RabbitMQ如果沒有中間件團隊應該選擇第一種方案
四、平臺化
消息平臺化後應該事務消息跟消息中間件無關化，可以參考RocketMQ的二段提交，轉發到事務消息隊列，事務消息模塊消費，然後註冊一個回查延遲消息，回調生產者事務提交檢查方法，完成事務