在 Debian 上排查与处理 RabbitMQ 消息丢失
一、快速定位丢失环节
- 生产者到 Broker：是否开启了Publisher Confirm；未路由的消息是否开启mandatory + ReturnListener；是否因未路由却被确认而“误以为成功”。
- Broker 自身：队列/消息是否持久化；节点是否单点；是否使用了镜像队列且版本存在已知隐患；磁盘/文件系统是否异常。
- 消费者侧：是否关闭了自动 ACK；处理完成后是否手动 ACK；异常时是否拒绝并重新入队或进入死信队列；是否实现了幂等。
- 运行环境：磁盘满、OOM、网络抖动、队列溢出策略等基础设施问题。
以上环节覆盖了消息在生产者、Broker、消费者三处最常见的丢失场景与对策。
二、生产者侧防丢配置
- 开启Publisher Confirm：使用异步回调记录每条消息的 ack/nack；超时未确认进行可靠重发（需业务侧去重/幂等）。
- 处理不可路由消息：发布时将 mandatory=true，并注册 ReturnListener 接收 basic.return，对返回的消息进行重投或落库留痕。
- 避免“误确认”：当队列/节点异常导致不可达时，未设置 mandatory 的消息可能被直接丢弃但仍返回 ack，务必用 mandatory+return 捕获并重发。
- 持久化配合 Confirm：仅当消息真正落盘后 Broker 才会 ack，结合 confirm 可显著降低“已确认但未落盘”的丢失风险。
- 谨慎使用事务：事务能保证一致性但性能较差，在高吞吐场景优先 confirm。
三、Broker 侧防丢配置
- 持久化三件套：将队列 durable=true、消息 deliveryMode=2（持久化）；如需重启后仍存在，交换机也建议设为持久化。仅开启其一不足以保证不丢。
- 高可用与镜像队列：通过镜像队列提升可用性，但需认识到其并非“绝对可靠”，早期版本（如3.0.x）在磁盘/节点异常时存在队列元数据丢失的坑，建议升级到**3.4.0+**的稳定版本并充分回归测试。
- 磁盘与告警：监控磁盘空间与 I/O 错误，避免因磁盘满/损坏导致落盘失败；对关键队列设置溢出策略（如丢弃/死信）并配合监控告警。
- 版本与修复：如仍在使用老版本镜像队列，优先评估升级到包含修复的版本，降低因元数据/队列丢失带来的风险。
四、消费者侧防丢与去重
- 关闭自动 ACK，改为手动 ACK：仅在业务处理成功且可安全提交时调用 basicAck；处理中异常则 basicNack/basicReject，结合 requeue 或转入**死信队列（DLQ）**避免丢失。
- 处理语义：prefetch 合理设置（如 1），减少消息处理中因异常导致的“已取未确认”堆积；必要时使用重试与死信策略隔离故障消息。
- 幂等设计：由于网络重连/重试可能造成重复投递，消费者需实现幂等（如业务唯一键去重、状态机、去重表）。
五、Debian 上的落地检查清单与命令
- 安装与启停（示例）：
- sudo apt update && sudo apt install rabbitmq-server
- sudo systemctl start rabbitmq-server && sudo systemctl enable rabbitmq-server
- sudo rabbitmq-plugins enable rabbitmq_management（访问 http://服务器IP:15672 查看队列/连接/确认状态）
- 关键配置与运维要点：
- 在管理界面或策略中检查队列的 durable=true、消息 delivery_mode=2；确认生产者已开启 confirm 与 mandatory+return；消费者为 手动 ACK。
- 监控磁盘使用率与 RabbitMQ 日志（如磁盘告警、连接异常、镜像同步异常等），必要时扩容磁盘或调整队列/镜像策略。
- 升级到包含修复的稳定版本（如镜像队列问题在**3.4.0+**有明显改善），并在测试环境验证故障转移与恢复流程。
- 建立监控与告警（队列长度、确认延迟、未确认消息数、磁盘/内存、节点健康），并定期演练故障恢复。
