金融级rabbitmq消息不丢失必须协同生产者confirm、broker持久化与消费者manual ack：生产者启用confirm+deliverymode=2+mandatory=true并补偿重发；broker使用quorum队列实现raft强一致；消费者手动ack+幂等+死信兜底，并配套监控与混沌演练。
要在 Java 中用 RabbitMQ 实现金融级消息不丢失，必须把生产者确认（Confirm）和消费者手动应答（Manual ACK）作为两个不可割裂的环节来协同设计。单独启用任一机制都不足以兜住全链路风险——Confirm 防不住 Broker 到消费者之间的断连或崩溃，Manual ACK 也拦不住生产者发丢或 Broker 持久化失败。真正可靠，靠的是两端闭环+中间持久化。
生产者端：Confirm 模式 + 消息持久化 + 失败补偿
不能只调用 channel.confirmSelect() 就算完成。关键动作有三步：
- 声明 Exchange、Queue 时全部设
durable = true；发送消息时必须设置MessageProperties.PERSISTENT_TEXT_PLAIN（即 deliveryMode=2），确保消息写入磁盘 - 开启 Confirm 后，必须注册
ConfirmListener，在handleNack中触发补偿逻辑：优先指数退避重发（最多 3 次），失败后落库到t_outbox表，含 message_id、payload、status、next_retry_time - 禁用
mandatory=false的默认行为，对关键业务必须设mandatory=true并配合ReturnListener，捕获路由失败（如交换机没绑定队列），避免消息静默消失
Broker 层：Quorum 队列 + 强一致集群
Classic 队列在节点故障时可能丢未同步消息，金融场景必须弃用。正确做法是：
- 创建队列时显式指定
"x-queue-type" → "quorum"，利用 Raft 协议实现多数派写入与自动选主 - 集群至少 3 节点（推荐 5），跨机房部署需评估网络延迟对 Raft 投票超时的影响，避免脑裂
- 关闭 lazy mode，改用
x-max-length或 TTL 控制积压，防止内存溢出导致进程崩溃
消费者端：手动 ACK + 幂等 + 死信兜底
autoAck=true 是金融系统红线。必须做到：
-
basicConsume(queue, false, ...)中第二个参数为false；业务处理成功后再调basicAck(deliveryTag, false)；异常时根据类型选择：basicNack(..., requeue=false)进死信队列，或requeue=true有限重试 - 幂等性由业务强保障：订单类用数据库唯一约束（
INSERT INTO t_msg_log(msg_id) ON CONFLICT DO NOTHING）；高并发场景用 Redis SETNX + 过期时间（建议 ≥ 2 小时，覆盖最大重试窗口） - 每个业务队列必须绑定 DLX（Dead Letter Exchange）和 DLQ，配置
x-dead-letter-exchange和x-dead-letter-routing-key，NACK/超时/拒绝消息统一进 DLQ，供人工干预或自动分析
可观测性：监控 + 故障演练常态化
机制再全，看不见就等于没用。必须落地以下两点：
- 接入 Prometheus + Grafana，重点采集：unacked 消息数、quorum queue 的 sync-state、confirm timeout 率、DLQ 积压量、消费者处理耗时 P99
- 每月执行一次 Chaos Engineering：随机 kill RabbitMQ 节点、注入网络分区、模拟磁盘满，验证 Quorum 自愈能力、Confirm 补偿任务是否触发、DLQ 是否及时分流
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
