一、阶段 1生产者发送消息防止消息丢在网络 / 发送环节生产者发送后MQ 没收到消息直接消失。提供 4 种可靠机制推荐确认机制 本地消息表组合。1. 开启 Publisher Confirms发布确认核心原理生产者发送消息后RabbitMQ 异步回调通知生产者消息投递结果ack消息成功抵达交换机nack消息投递失败交换机不存在、路由失败等配置spring.rabbitmq.publisher-confirm-typecorrelated失败处理收到 nack 时本地重试发送重试多次失败存入本地消息表定时补偿。2. 开启 Publisher Returns消息回退场景消息成功到达交换机但没有匹配到任何队列路由键错误、队列不存在消息会被丢弃。 开启 return 机制后这种消息会退回生产者手动处理记录日志、重试、告警。 配置spring.rabbitmq.publisher-returnstrue3. 持久化发送事务不推荐RabbitMQ 支持 AMQP 事务 channel.txSelect ()发送消息后提交事务失败则回滚。缺点同步阻塞吞吐量暴跌高并发业务几乎不用优先 Confirms。4. 兜底本地消息表最终一致性业务库新增一张消息记录表本地事务执行业务 SQL 插入待发送消息记录原子执行 独立定时任务轮询消息表读取未发送消息投递 MQ投递成功更新状态为已发送投递失败不断重试。 解决极端场景生产者发送中途宕机Confirms 回调没收到消息不会丢失。二、阶段 2RabbitMQ 服务端防止 MQ 宕机丢失消息消息已经到达 MQ但 MQ 重启、磁盘故障导致消息丢失。核心方案队列持久化 消息持久化队列持久化durabletrue 创建交换机、队列时设置 durabletrue队列元数据队列名称、绑定关系持久化到磁盘MQ 重启队列不会消失。 注意仅队列持久化没用消息依然存在内存重启丢失。消息持久化deliveryMode2 发送消息时设置消息持久化消息写入磁盘而不是只存在内存。 deliveryMode1非持久化内存消息重启全部清空 deliveryMode2持久化落盘保存。补充优化关闭自动刷盘MQ 默认批量刷盘极端断电可能丢失少量缓存消息追求极致可靠可调整刷盘策略性能损耗集群镜像队列单机磁盘损坏会丢数据生产搭建 RabbitMQ 集群配置镜像队列消息同步复制到多个节点单节点故障数据不丢失。三、阶段 3消费者消费阶段防止消息消费中途丢失MQ 已经保存消息消费者拿到消息还没处理完就宕机MQ 会认为消息消费完成直接删除消息丢失。核心解决方案关闭自动 ACK手动 ACK 确认自动 ACK默认模式不可靠 消费者一收到消息RabbitMQ 立刻删除队列中的消息。如果业务处理中途宕机、报错消息永久丢失。手动 ACK生产强制使用 配置spring.rabbitmq.listener.simple.acknowledge-modemanual 执行逻辑消费者获取消息MQ 不会删除消息消息处于未确认状态业务逻辑完整执行成功后手动调用 basic.ack ()告知 MQ 消费完成MQ 删除消息业务异常、宕机、处理失败调用 basic.nack ()参数设置 requeuetrue消息重新放回队列等待重新消费重复消费问题业务基于消息唯一 ID 做幂等处理避免重试重复执行业务。死信队列兜底 消息多次重试消费全部失败数据异常、逻辑报错无限重入会阻塞队列。 配置死信交换机 死信队列消费失败 n 次后消息路由到死信队列人工排查处理不会丢失也不会堵塞正常消息。四、完整落地总结三端配套缺一不可生产者端开启 Publisher-ConfirmReturn 机制 本地消息表定时补偿MQ 服务端交换机 / 队列持久化 消息持久化 集群镜像队列消费者端关闭自动 ACK使用手动 ACK消费失败消息重新入队配置死信队列处理异常消息业务实现幂等防止重复消费。精简口述总结RabbitMQ 消息丢失分生产者、MQ 服务、消费者三个场景。生产者通过发布确认、消息回退、本地消息表保证投递不丢失MQ 端开启队列和消息持久化集群镜像防止宕机丢数据消费者关闭自动确认采用手动 ACK处理成功才告知 MQ 删除消息失败消息重新入队搭配死信队列处理异常消息三端配合才能完全杜绝消息丢失。