金融级消息不丢不重需四段闭环联动：生产端Confirm+持久化+强路由校验，Broker层Quorum队列+多数派写入，消费端Manual ACK+强幂等+死信兜底，并配套监控与混沌演练。
金融级消息不丢不重，靠的不是单点配置，而是生产、传输、存储、消费四段闭环联动。单独开 Confirm 或只做幂等，都挡不住链路中任一环节的故障。
生产端：Confirm + 持久化 + 强路由校验
不能只调 channel.confirmSelect() 就算完事。必须三者齐备：
- Exchange 和 Queue 声明时设
durable = true，确保元数据落盘 - 每条消息必须用
MessageProperties.PERSISTENT_TEXT_PLAIN（即deliveryMode=2），强制写磁盘 - 开启 Confirm 后，必须注册
ConfirmListener；handleNack中不能仅打日志，要立即触发补偿：前 3 次指数退避重发，第 4 次起落库到t_outbox表，含message_id、原始 payload、状态和下次重试时间 - 关键业务必须设
mandatory = true，并配ReturnListener，捕获路由失败（比如交换机没绑定队列），避免消息静默消失
Broker 层：Quorum 队列 + 多数派写入
Classic 队列在节点宕机时可能丢失未同步消息，金融场景必须禁用：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 创建队列时显式指定
x-queue-type: quorum，启用 Raft 协议实现多数派确认写入 - 集群至少 3 节点（推荐 5），跨机房部署需调大 Raft
election_timeout，防脑裂 - 关闭 lazy mode；用
x-max-length或 TTL 控制积压，避免内存溢出崩溃
消费者端：Manual ACK + 强幂等 + 死信兜底
autoAck=true 是红线，必须手动控制交付节奏：
立即学习“Java免费学习笔记（深入）”；
-
basicConsume(queue, false, ...)第二个参数必须为false；业务逻辑执行成功后才调basicAck(deliveryTag, false) - 异常时区分处理：
basicNack(..., requeue=false)直接送 DLQ；requeue=true仅限瞬时异常（如 DB 连接超时），且限制重试次数 - 幂等必须由业务层强保障：订单类用数据库唯一约束（
INSERT INTO t_msg_log(msg_id) ON CONFLICT DO NOTHING）；高并发用 Redis SETNX + ≥2 小时过期（覆盖最大重试窗口） - 每个队列必须绑定 DLX 和 DLQ，配置
x-dead-letter-exchange和x-dead-letter-routing-key，所有 NACK/超时/拒绝消息统一进 DLQ，供人工干预或自动归因
配套机制：监控 + 混沌演练
再严密的设计也需可观测与验证：
- 接入 Prometheus + Grafana，监控 Confirm 失败率、DLQ 积压量、ACK 延迟 P99、Redis 幂等 Key 命中率
- 每月执行混沌工程：随机 kill RabbitMQ 节点、注入网络分区、模拟磁盘满，验证 Quorum 自愈能力与补偿任务触发时效
- 所有补偿任务需记录 trace_id，与原始消息 ID 关联，支持全链路回溯
