RabbitMQ消息丢失是生产者发不出、Broker存不住、消费者没认领三个环节的系统性风险：需启用Confirm模式与Return Callback、交换机队列消息均设持久化、关闭autoAck并手动ack。
RabbitMQ消息丢失不是偶发故障，而是三个确定环节的系统性风险：生产者发不出、Broker存不住、消费者没认领。每个环节都必须单独加固，缺一不可。
生产者发送失败：网络抖动或Broker不可用时消息静默丢弃
现象是日志里没报错，但下游完全收不到消息；本质是 basicPublish 调用成功只代表写入了 TCP 缓冲区，并不保证抵达 Broker。
- 禁用事务（
channel.txSelect），它会让吞吐量跌 50% 以上，线上基本不可用 - 强制开启 Confirm 模式：
channel.confirmSelect()，配合异步回调处理ack/nack - 必须同时启用 Return Callback：
mandatory=true+publisher-returns=true，捕获“到达Broker但无队列匹配”的情况 - 给每条消息绑定唯一
CorrelationData，失败时能精准重发，避免全量重试放大压力
Broker 存储丢失：重启、宕机或断电后队列消息清空
默认创建的交换机、队列、消息全是内存型，rabbitmqctl stop_app && rabbitmqctl start_app 后数据归零——这不是 bug，是默认行为。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 声明交换机时必须设
durable=true，否则重启后交换机不存在，新消息直接被拒绝 - 声明队列时必须设
durable=true，且消费者首次连接时不能用临时队列名（如自动生成的amq.gen-xxx） - 发送消息时
MessageProperties必须显式设置deliveryMode=2（即持久化消息），仅队列持久化不够 - 注意：持久化会写磁盘，单机吞吐下降约 20%，但这是可用性的底线，无法妥协
消费者未正确确认：处理中崩溃导致消息永久消失
默认 autoAck=true 时，消息一投递就自动标记为已消费；此时消费者进程 kill -9，消息就彻底丢了。
- 必须关闭 autoAck：
channel.basicConsume(queue, false, ...)，把 ack 控制权拿回来 - 业务逻辑完成后再调用
channel.basicAck(deliveryTag, false)，且确保在 try-finally 块里执行 - 不要在 catch 块里直接
basicNack(..., requeue=true)，高频重入可能压垮队列；应先落库+告警，再人工介入 - 消费者启动时检查队列长度，若积压突增，优先排查是否因异常导致 ack 被跳过
最易被忽略的是三者之间的依赖关系：比如开了 Confirm 却没设 deliveryMode=2，消息仍会因 Broker 重启丢失；或者队列持久化了，但交换机没持久化，重启后路由失效。每个开关都要对齐，少一个，整条链路就断在那个点上。
