rabbitmq在java中实现消息不丢失需覆盖生产者、broker、消费者全链路可靠性控制：生产者启用发布确认与退回回调并落库重试；broker端队列、交换机及消息均需持久化；消费者必须手动ack并配合死信队列。
RabbitMQ 在 Java 中实现消息不丢失，关键在于覆盖“生产者→Broker→消费者”全链路的可靠性控制。不是加一个配置就能解决，而是每个环节都要有对应机制，缺一不可。
生产者侧：发得稳，确认到位
只调用 basicPublish 不代表消息已安全抵达。必须启用发布确认（Publisher Confirm）并配合路由失败回调（Return Callback）：
- 在
application.yml中开启：spring.rabbitmq.publisher-confirm-type: correlatedspring.rabbitmq.publisher-returns: truespring.rabbitmq.template.mandatory: true - 配置
RabbitTemplate的 ConfirmCallback 和 ReturnCallback，分别处理“消息是否被 Broker 接收”和“是否成功路由到队列”两种失败场景； - 确认失败时，不能静默丢弃——应记录日志、落库待重试，或推入延迟重发队列（如 Redis + 定时任务）；
- 避免使用事务（
channel.txSelect()），性能差且已不推荐，Confirm 机制更轻量高效。
Broker 侧：存得住，重启不丢
消息进了 RabbitMQ，不代表就安全了。默认队列和消息都是内存型，宕机即失：
- 声明队列时设
durable = true（Spring 中@Queue(durable = "true")或queueDeclare("q1", true, ...)）； - 声明交换机时同样设
durable = true； - 发送消息时指定持久化属性：
Spring AMQP：用MessageProperties.PERSISTENT_TEXT_PLAIN；
原生客户端：设置AMQP.BasicProperties.builder().deliveryMode(2)； - 注意：持久化会略微降低吞吐，但对订单、支付等核心业务必须开启。
消费者侧：处理完，再确认
自动 ACK（autoAck=true）是最大隐患——消息刚取到手、还没处理完，进程就崩了，消息直接消失：
- 强制设为手动 ACK：
配置中spring.rabbitmq.listener.simple.acknowledge-mode: manual； - 消费逻辑必须包裹在
try-catch中，成功才调channel.basicAck(deliveryTag, false)； - 失败时，用
basicNack(deliveryTag, false, requeue)控制是否重试：
瞬时异常（如 DB 连接超时）可设requeue=true让其重入队；
业务逻辑错误（如参数非法）应设requeue=false，避免死循环； - 配合死信队列（DLQ）：给原队列设置
x-dead-letter-exchange，把多次重试失败的消息导出分析。
额外加固点：连接与重试容错
网络抖动或 Broker 临时不可用时，不能让整个服务卡住：
- 启用自动重连：
spring.rabbitmq.listener.simple.retry.enabled: true
并合理配置max-attempts、initial-interval和multiplier； - 消费者端限流防雪崩：
spring.rabbitmq.listener.simple.prefetch: 1（每次只取 1 条，处理完再拿下一条）； - 连接池配置别忽略：
如cache.channel.size和connection-timeout，避免高并发下连接耗尽或阻塞。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
