淺談業務流程中的mq使用方式

假設有個場景：

下單成功需要給使用者發送消息通知，發送消息通知通過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查詢），驗證業務是否執行成功。消息服務需新增一個定時任務，對于狀态為待發送狀态的消息做補償處理，檢查一下業務是否處理成功，進而确定消息是投遞還是取消發送。