Confirm机制仅保障MQ层接收确认，不感知业务DB状态；本地消息表通过事务内落库“发送意图”与业务状态绑定，配合定时任务精准补偿，解决JVM崩溃等中间态丢失问题。
网络抖动时，仅靠 RabbitMQ 自身的 Confirm 机制无法保证消息不丢——因为生产者可能在发消息前就宕机，或 DB 提交成功但 MQ 还没来得及发。本地消息表是唯一能跨系统状态、应对这种“中间态失败”的兜底方案。
为什么 Confirm + 重试还不够用？
Confirm 回调只管“MQ 是否收到了”，但它完全不感知业务数据库状态。典型断点场景：
- 事务已提交到 DB（比如订单状态变“已创建”），但
rabbitTemplate.convertAndSend()还没执行完，JVM 崩溃 - Confirm 回调收到
ack=false，触发重试，但此时 DB 已有同 ID 订单，重复插入失败或引发幂等问题 - 网络恢复后，重试消息和原始消息同时到达消费者，造成重复消费
这些都不是 MQ 层能解决的，必须把“消息发送意图”和“业务状态”绑在一起落库。
本地消息表结构与写入时机
关键不是“有没有表”，而是“什么时候写”和“写什么”。必须在业务事务内完成，且包含可重试上下文：
立即学习“Java免费学习笔记（深入）”；
- 表字段至少含：
id（主键）、message_id（全局唯一，如 UUID）、exchange、routing_key、payload（JSON 字符串）、status（枚举：sending / sent / failed / discarded）、created_at、next_retry_at - 写入必须在业务事务 commit 前完成，例如 Spring 中用
@Transactional包裹 DB 插入 + 消息表插入 - 不要在事务里调用
convertAndSend()——它可能抛异常中断事务，导致 DB 和消息表状态不一致
定时任务如何安全补偿？
补偿不是“扫全表重发”，而是带条件、带幂等、带退避的精准驱动：
- 查询条件应为：
status = 'sending' AND next_retry_at ，避免锁全表 - 更新语句必须原子：
UPDATE msg_table SET status='sending', next_retry_at=DATE_ADD(NOW(), INTERVAL 30 SECOND) WHERE id=? AND status='sending'，防止多实例重复取同一消息 - 重发失败后，更新
next_retry_at为指数退避时间（如 1s → 2s → 4s → 8s），并限制最大重试次数（建议 ≤5） - 若重试超限，将
status改为failed，转入人工核查队列，而不是丢弃或无限循环
和 RocketMQ 事务消息比，本地消息表难在哪？
本地消息表没有中间件级的二阶段协调能力，所有一致性逻辑都压在应用层：
- 你得自己实现“半消息”效果：DB 写入成功 ≠ 消息已发，只是“承诺要发”
- 补偿任务必须独立部署、高可用，不能和业务服务共用 JVM，否则服务挂了补偿也停了
- 消息体
payload要尽量小，避免大字段拖慢定时扫描；敏感字段（如用户手机号）不应明文存表，而应存脱敏 ID 或加密后值
真正容易被忽略的，是补偿任务的“可见性延迟”——从 DB 写入到定时任务捞到这条记录，中间存在秒级 gap。如果你的业务要求“100ms 级最终一致性”，本地消息表就不适合，该换用支持事务消息的 MQ。
