事務消息：實現了消息生成者本地事務與消息發送的原子性，保證消息生成者本地事務處理成功與消息發送成功的最終一致性問題。
1、事務消息與普通消息的區別就在於消息生產環節，生產者首先預發送一條消息到MQ(這也被稱為發送half消息)
2、MQ接受到消息后，先進行持久化，則存儲中會新增一條狀態為待發送的消息
3、然后返回ACK給消息生產者，此時MQ不會觸發消息推送事件
4、生產者預發送消息成功后，執行本地事務
5、執行本地事務，執行完成后，發送執行結果給MQ
6、MQ會根據結果刪除或者更新消息狀態為可發送
7、如果消息狀態更新為可發送，則MQ會push消息給消費者，后面消息的消費和普通消息是一樣的
注意點：由於MQ通常都會保證消息能夠投遞成功，因此，如果業務沒有及時返回ACK結果，那么就有可能造成MQ的重復消息投遞問題。因此，對於消息最終一致性的方案，消息的消費者必須要對消息的消費支持冪等，不能造成同一條消息的重復消費的情況。
如果consumer消費失敗，是否需要producer做回滾？
答：事務消息，producer不會因為consumer消費失敗而做回滾，采用事務消息的應用，其所追求的是高可用和最終一致性，消息消費失敗的話，MQ自己會負責重推消息，直到消費成功。因此，事務消息是針對生產端而言的，而消費端，消費端的一致性是通過MQ的重試機制來完成的。
基於本地消息的最終一致性方案的最核心做法就是在執行業務操作的時候，記錄一條消息數據到DB，並且消息數據的記錄與業務數據的記錄必須在同一個事務內完成，這是該方案的前提核心保障。在記錄完成后消息數據后，后面我們就可以通過一個定時任務到DB中去輪訓狀態為待發送的消息，然后將消息投遞給MQ。這個過程中可能存在消息投遞失敗的可能，此時就依靠重試機制來保證，直到成功收到MQ的ACK確認之后，再將消息狀態更新或者消息清除；而后面消息的消費失敗的話，則依賴MQ本身的重試來完成，其最后做到兩邊系統數據的最終一致性。
問題：每個業務系統在使用該方案時，都需要在對應的業務庫創建一張消息表來存儲消息，可以將該功能單獨提取出來，做成一個消息服務來統一處理
獨立消息服務的最終一致性
過程其實就是模擬了事務消息的消息預發送過程，如果預發送消息失敗，生產者業務就不會去執行，對於生產者的業務而言，它是強依賴於該消息服務的。不過好在獨立消息服務支持水平擴容，只要部署多台，做成HA的集群模式，就能夠保證其可靠性。在消息服務中，還有一個單獨地定時任務，會定期輪訓長時間處於待發送狀態的消息，通過一個check補償機制來確認該消息對應的業務是否成功，如果對應的業務處理成功，則將消息修改為可發送，然后將其投遞給MQ；如果業務處理失敗，則將對應的消息更新或者刪除即可。因此在使用該方案時，消息生產者必須同時實現一個check服務，來供消息服務做消息的確認。對於消息的消費，該方案與上面的處理是一樣，都是通過MQ自身的重發機制來保證消息被消費。