假設有個場景：

下單成功需要給用戶發送消息通知，發送消息通知通過mq實現

事務提交前發送mq消息

step1：start transaction
step2：生成訂單
step3：投遞消息到mq
step4：commit transaction

問題：

step3發生異常會導致step4失敗，下單失敗，直接影響到下單業務

step4發生異常，其他step成功。事務回滾下單失敗，但是卻發送了成功消息。

事務之后發送消息

step1：start transaction
step2：生成訂單
step3：commit transaction
step4：投遞消息到mq

問題:

step4發生異常，其他step成功。下單成功，但是發送消息失敗。

定時輪訓發送消息

step1：start transaction
step2：生成訂單
step3：本地庫中插入一條需要發送消息的記錄t_msg_record
step3：commit transaction
step5：新增一個定時器，輪詢t_msg_record，將待發送的記錄投遞到mq中

問題:

這種方式借助了數據庫的事務，業務和消息記錄作為了一個原子操作。業務成功之后，消息日志必定是存在的。

業務單一的情況下沒問題，不方便擴展。

消息服務

step1：生成一個全局唯一業務消息id，調用消息服務，將消息落地入庫，此時消息的狀態為待發送狀態，返回消息id
step2：start transaction
step3：生成訂單
step4：當前事務庫插入一條日志(將step3中的業務和bus_msg_id關聯起來)
step5：commit transaction
step6：如果上面都成功，調用消息服務，將消息投遞到mq中。如果上面有失敗的情況，則調用消息服務取消消息的發送

若step6失敗，消息將處于待發送狀態，此時業務方需要提供一個回查接口(通過業務消息id查詢)，驗證業務是否執行成功。消息服務需新增一個定時任務，對于狀態為待發送狀態的消息做補償處理，檢查一下業務是否處理成功，從而確定消息是投遞還是取消發送。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的rocket mq 监听端口_浅谈业务流程中的mq使用方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。