RabbitMQ消息可靠性保障需覆盖生产者、Broker、消费者三环节：生产者启用Confirm模式和publisher-returns并重试；Broker端队列、消息、Exchange均需持久化，集群配镜像队列；消费者强制manual ack、prefetch=1、加死信队列。
RabbitMQ消息丢失不是“会不会发生”的问题，而是“在哪个环节可能出问题”以及“怎么堵住缺口”的问题。核心就三点：生产者发得稳、Broker存得住、消费者吃得准。下面从实战角度，分环节讲清楚怎么做、为什么这么做、容易踩什么坑。
✅ 生产者端：确保消息真正进到 RabbitMQ
网络抖动、Exchange 不存在、路由失败、Broker 拒绝接收……这些都可能导致消息发出却石沉大海。
-
开启 Confirm 模式（必须）：比事务性能高得多，异步确认不阻塞。发送后监听 ack/nack 回调，失败时重试 + 日志告警。
-
配置 publisher-returns（推荐）：当消息无法路由到任何队列（比如 routingKey 错、队列被删），RabbitMQ 会通过 return callback 把消息原路退回，避免静默丢弃。
-
加生产者重试（Spring Boot 场景）：在 application.yml 中启用 template.retry，设置合理重试次数（如 3 次）和退避策略，应对临时性连接失败。
-
不要依赖事务（除非极低吞吐场景）：channel.txSelect 会同步阻塞，压测下 TPS 可能跌 90% 以上，确认模式完全可替代。
✅ Broker 端：防止 MQ 自身宕机导致消息蒸发
默认情况下，RabbitMQ 把消息存在内存里——服务一挂，未消费的消息全丢。必须让关键消息“落盘”。
-
队列声明必须 durable = true：这是消息持久化的前提。没它，哪怕消息标了持久化，重启后队列没了，消息照样消失。
-
消息发布时设 deliveryMode = 2：AMQP.BasicProperties.builder().deliveryMode(2)，仅当队列也持久化时才生效。
-
Exchange 也要 durable = true：虽然 Exchange 本身不存消息，但若它不持久，重启后交换器不存在，新消息连路由第一步都过不去。
-
集群环境建议配镜像队列：比如 x-ha-policy: all，避免单节点故障导致整个队列不可用（注意：镜像队列不解决磁盘损坏，但防节点宕机）。
✅ 消费者端：避免“以为消费了，其实没处理完”
默认 autoAck=true 是最大隐患：消息一推过来就自动确认，消费者进程崩溃或处理中途异常，消息就永远消失了。
-
强制 manual ack（必须）：关闭 autoAck，只在业务逻辑真正执行成功后，再调用 channel.basicAck()。失败时 basicNack(requeue=false) 进死信，或 requeue=true 重入队（慎用，防无限循环）。
-
配合 prefetch = 1（按需）：限制消费者同一时间最多处理 1 条未确认消息，避免大量消息堆积在消费者内存中，宕机即丢。
-
消费逻辑加 try-catch + finally：确保无论成功失败，ack/nack 都被执行。别把确认逻辑写在 if 里，漏掉 else 就等于丢消息。
-
引入死信队列（DLX）兜底：对反复 nack 或超时未确认的消息，自动转到 DLX 做人工干预或补偿，而不是直接丢弃。
✅ 补充：监控与兜底意识
再完善的机制也需要可观测性支撑：
- 用 RabbitMQ Management UI 或 Prometheus + Grafana 监控 unacked、ready、delivering 数量突变；
- 给关键消息加唯一 message-id 和时间戳，日志打全链路 trace，便于丢消息后快速定位
环节；
- 定期做故障演练：kill -9 RabbitMQ 进程、断网、模拟消费者 crash，验证整套机制是否真起作用。
基本上就这些。不复杂，但每个环节都容易忽略一两个细节——比如只设了消息持久化却忘了队列持久化，或者开了 confirm 却没写 nack 处理逻辑。可靠性不是加一个开关就万事大吉，而是环环相扣的工程实践。
