关于极端场景下，数据库更新与 MQ 消息一致性保障方案的详细总结
目录
一、核心问题场景
二、RocketMQ 事务消息方案
1. 核心机制
2. 执行流程
3. 关键优势
4. 局限性
三、消息表方案
1. 核心机制
2. 执行流程
3. 关键优势
4. 局限性
四、方案对比与选择
五、实施建议
六、总结
一、核心问题场景
当数据库更新后，若 MQ 消息未成功发送或机器异常重启，可能导致数据状态与消息通知不一致。需解决以下问题：
- 原子性：确保数据库操作与消息发送要么全成功，要么全失败
- 最终一致性：即使出现异常，也能通过补偿机制达成一致
二、RocketMQ 事务消息方案
1. 核心机制
- 半消息阶段：生产者先发送 prepare 消息（半消息）到 Broker
- 本地事务执行：执行数据库更新操作
- 事务状态回查：Broker 通过定时任务回查本地事务状态，决定消息是否提交 / 回滚
2. 执行流程
3. 关键优势
- 强一致性：通过事务状态回查保证最终消息投递
- 异步解耦：不阻塞业务流程，适合高并发场景