分布式事務解決方案—事務消息
普通消息難以保證生產者的事務操作與消息發送的原子性，所以可能會導致數據不一致；RocketMQ提供了一種在普通消息基礎上支持二階段的提交能力事務消息，事務消息可以支持在分布式場景下保障消息生產和本地事務的最終一致性。
1、事務消息基本概念
（1）半消息
生產者發送的消息首先作為“半消息”存儲在Broker中，對消費者不可見。Broker 等待生產者確認消息狀態（提交或回滾），事務消息有3種狀態如下所示：
狀態 | 狀態的描述 |
TransactionStatus.CommitTransaction | 提交事務，表示允許消費者消費（使用）這條消息 |
TransactionStatus.RollbackTransaction | 回滾事務，表示消息將被刪除，不允許使用 |
TransactionStatus.Unknown | 中間狀態，表示需要MQ向消息發送方進行檢查以確定狀態 |
（2）事務狀態檢查
如果生產者未及時確認，Broker會定時回查生產者的事務的最終狀態，通過回查的最終狀態決定半消息是提交還是回滾操作。
（3）接口API
RocketMQ提供了兩大重要的接口，分別是TransactionMQProducer 和TransactionListener，這個兩個接口主要用于發送事務消息并處理本地事務邏輯。
（4）存儲與可靠性
事務消息存儲在Broker的專門的隊列中，通過記錄事務狀態日志來確保高可用性和一致性。相對于普通消息，事務消息增加了半消息階段和狀態檢查機制，然后通過狀態檢查機制來保證分布式下數據的最終一致性。
2、事務消息的實現
RocketMQ事務消息的實現原理圖如下所示：
圖片
第一階段
A服務中生產者發送半消息至RocketMQ的服務端，RocketMQ服務端將消息持久化后，向生產者返回ACK確認消息，表示消息已經發送成功，此時消息會持久化在RocketMQ的隊列中，這個消息對于消費者暫不能消費。
A服務執行本地的業務邏輯，然后根據A服務本地事務執行結果確定第二階段的提交/回滾操作。
第二階段
（1）A服務的本地事務執行成功，此時消息的確認結果為提交，那么RocketMQ服務端將半消息事務標記為可消費的完整消息，如下圖所示：
圖片
消息變成完整消息后就可以被消費者消費了。
（2）A服務的本地事務執行失敗，此時消息的確認結果為回滾，那么RocketMQ將半事務消息刪除，這樣就不會投遞給消費者消費。
（3）為了保證第二階段的數據一致性，RocketMQ提供了針對半消息的消息狀態回查機制，即就是如果RocketMQ服務端未收到生產者提交的二次確認結果或者收到的確認結果為未知狀態(Unknow)，RocketMQ服務端會定期對消息生產者發起回查機制。
當A服務接收到回查任務的時候，會檢查本地事務執行的最終結果，然后提交事務執行的最終結果給RocketMQ服務端，RocketMQ服務端根據最終的執行結果決定這個半消息是提交還是回滾。
總結
（1）RocketMQ的事務消息保證了本地事務與事務消息發送的一致性，本地事務執行成功，事務消息方可投遞到消費者端處理。
（2）未收到生產者提交的二次確認結果或者收到的確認結果為未知狀態的半消息，RocketMQ提供了消息狀態回查機制，通過回查生產者端的本地事務的執行結果來判斷半消息的最終狀態。
（3）RocketMQ事務消息提供了超時機制，即半事務消息被生產者發送到Broker后，如果在指定時間內（默認4小時）服務端無法確認提交或者回滾狀態，則消息默認會被回滾。
（4）RocketMQ事務消息無法實現嚴格的實時一致性，只能保證最終一致性，所以針對那些實時性要求高的場景下RocketMQ事務消息是不適合的。
（5）事務執行時間過長會影響系統整體吞吐量，同時在消費者端需要消費者自行的實現消息的冪等處理。
