RocketMQ的事務投遞

RocketMQ的事務投遞

這是阿里的分佈式事務圖：

• 一、A服務先發送個Half Message給Brock端，消息中攜帶 B服務 即將要+100元的信息。
• 二、當A服務知道Half Message發送成功後，那麼開始第3步執行本地事務。
• 三、執行本地事務(會有三種狀況一、執行成功。二、執行失敗。三、網絡等緣由致使沒有響應)
• 4.1)、若是本地事務成功，那麼Product像Brock服務器發送Commit,這樣B服務就能夠消費該message。
• 4.2)、若是本地事務失敗，那麼Product像Brock服務器發送Rollback,那麼就會直接刪除上面這條半消息。
• 4.3)、若是由於網絡等緣由遲遲沒有返回失敗仍是成功，那麼會執行RocketMQ的回調接口,來進行事務的回查。

若是回查，那麼必定要先查看當前事務的執行狀況，再看是否須要從新執行本地事務。 本地事務執行成功後，返回Commit進行消息二次確認的時候的服務掛了，在重啓服務那麼這個時候在brock端，它仍是個Half Message(半消息)，這也會回查。若是不先查看當前事務的執行狀況，而是直接執行事務，那麼就至關於成功執行了兩個本地事務。

基於MQ的事務處理特色

最終一致性

RocketMQ是一種最終一致性的分佈式事務，就是說它保證的是消息最終一致性，而不是像2PC、3PC、TCC那樣強一致分佈式事務，至於爲何說它是最終一致性事務下面會詳細說明。

Half Message(半消息)

是指暫不能被Consumer消費的消息。Producer 已經把消息成功發送到了 Broker 端，但此消息被標記爲暫不能投遞狀態，處於該種狀態下的消息稱爲半消息。須要 Producer

對消息的二次確認後，Consumer才能去消費它。

消息回查

因爲網絡閃段，生產者應用重啓等緣由。致使 Producer 端一直沒有對 Half Message(半消息) 進行 二次確認。這是Brock服務器會定時掃描長期處於半消息的消息，會

主動詢問 Producer端 該消息的最終狀態(Commit或者Rollback),該消息即爲 消息回查。

一個例子

如下單流程爲例：