金融级消息零丢失需生产者确认、全链路持久化、消费者手动ack三者协同，缺一不可：生产者启用confirm/return机制并落库补偿；broker端交换机、队列、消息均需持久化；消费者禁用自动ack，配合死信队列与幂等设计。
金融级场景对消息零丢失有硬性要求，RabbitMQ 本身不默认保证可靠性，必须通过生产者确认 + 全链路持久化 + 消费者手动ACK三者协同实现。单点配置无效，缺一不可。
生产者端：异步确认 + 强制路由失败回调
仅发消息不等于消息已落地。需开启 Confirm 和 Return 机制，捕获两个关键失败点：
- 消息未到达交换机 → 触发
handleNack回调，立即重发或落库补偿 - 消息到达交换机但无法路由到队列（如 routingKey 错误、无绑定）→ 触发
ReturnListener，记录日志并告警
Spring Boot 中通过 publisher-confirm-type: correlated 和 publisher-returns: true 启用，并配合 template.mandatory: true 强制触发 return。Java 代码中可注入 RabbitTemplate 并设置回调函数，将失败消息写入本地事务表，由定时任务兜底重推。
Broker 端：交换机、队列、消息三层持久化
服务重启后消息还在，靠的是磁盘落盘，而非内存缓存。三者必须同时开启：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
-
交换机持久化：声明时设
durable=true，避免重启后交换机元数据丢失 -
队列持久化：
queueDeclare("pay_queue", true, false, false, null)，确保队列定义留存 -
消息持久化：发送时设置
deliveryMode = 2（即MessageDeliveryMode.PERSISTENT），使每条消息写入磁盘
注意：若只开队列持久化而消息非持久，MQ 重启后消息仍会清空；若只开消息持久化但队列非持久，重启后队列消失，消息无处存放——二者必须共存。
消费者端：手动 ACK + 死信兜底 + 幂等设计
自动 ACK 是金融场景最大风险源。必须禁用，并在业务逻辑完全执行成功后再发 ACK：
- 配置
acknowledge-mode: manual，使用Channel.basicAck()显式确认 - 消费异常时不 ACK，且设
default-requeue-rejected: false，防止无限循环投递 - 配置死信交换机（DLX）和死信队列（DLQ），让三次重试失败的消息转入人工核查流程
- 结合唯一业务 ID（如订单号 + 时间戳哈希）做幂等校验，避免 DLQ 重推导致重复扣款
额外加固：连接与事务边界控制
金融系统还需防范网络闪断与事务不一致：
- 启用连接池（
cache.channel.size）、设置合理超时（connection-timeout），避免因连接中断导致 ACK 未发出 - 生产者侧建议将消息发送与本地业务操作放在同一数据库事务中（如 Spring
@Transactional），借助“发消息前先落库”+“定时扫描未确认消息”实现最终一致性 - 禁用 RabbitMQ 事务（
channel.txSelect），因其同步阻塞严重降低吞吐，Confirm 机制已足够可靠
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
