RabbitMQ高并发下可靠性投递需生产端（异步批量confirm+mandatory return）、Broker端（持久化+镜像）、消费端（手动ACK+幂等+本地消息表）三侧协同；单靠开启confirm机制会引发性能雪崩。
高并发下 RabbitMQ 的消息可靠性投递不是靠“加机器”或“开更多 confirm”就能解决的，而是必须在生产端、Broker 端、消费端三侧做协同设计，否则 confirm 机制本身就会成为性能瓶颈，甚至引发雪崩。
confirm 模式必须用异步 + 批量，不能单条等 ACK
同步等待每条消息的 basicPublish 返回 ACK，在 QPS 超过 500 后延迟会指数上升；RabbitMQ 默认的普通 confirm（每发一条等一个）在高并发下实际吞吐可能跌到 1/3。必须启用批量确认 + 异步回调：
-
publisher-confirm-type: correlated是基础，但仅此不够 - 配合
template.setConfirmCallback(...)异步处理结果，避免阻塞主线程 - 通过
channel.confirmSelect()后连续发多条再调channel.waitForConfirmsOrDie(5000)实现批量确认（注意超时设置，别卡死） - 批量大小建议控制在 100–500 条之间：太小失去批量意义，太大导致单次失败重试成本高
消息路由失败必须捕获 returnCallback，不能只依赖 confirmCallback
confirmCallback 只管“消息是否到达 Exchange”，不保证“是否成功入队”。高并发下 routing key 写错、队列被误删、镜像同步延迟等情况更易暴露——此时消息会静默丢失，confirmCallback 仍返回 ack=true。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 必须显式开启
publisher-returns: true和template.mandatory: true - 设置
template.setReturnCallback(...)，检查replyCode（如312表示 NO_ROUTE） - 典型错误：
replyText=NO_ROUTE或replyText=NO_CONSUMERS，这类消息需立即进补偿队列或落库重试，不能忽略 - 注意：returnCallback 是同步触发的，不要在里面做耗时操作（如 DB 写入），应转为异步事件
消费端幂等 + 手动 ACK 必须绑定业务生命周期
高并发下自动 ACK（autoAck=true）等于主动放弃可靠性——只要消费者进程 crash 或 GC 停顿超过 heartbeat，消息就永久丢失。
- 必须设
autoAck=false，且channel.basicAck(tag, false)要放在业务逻辑真正提交之后（比如 DB commit 成功后） - 幂等性不能只靠消息 ID 缓存，要结合业务状态判断：例如订单创建场景，应查
order_status != 'created'而非仅 Redis 中是否存在processed:msg_id - 重试策略要分层：短时失败（DB 连接超时）走
basicNack(tag, false, true)重回原队列；长时失败（第三方接口不可用）走死信交换机，避免阻塞主链路 - 注意 channel 复用问题：Spring AMQP 默认每个 listener 使用独立 channel，但若手动管理 connection/channel，高并发下未关闭的 channel 会快速占满 Broker 连接数
本地消息表 + 定时补偿是兜底关键，不是可选项
即使 confirm + return + manual ACK 全部开启，网络分区、Broker 集群脑裂、客户端 OOM 等极端情况仍会导致消息状态“悬而未决”。这时候没有本地消息表，就等于没保险。
- 消息入库必须和业务 DB 在同一事务中（如 Spring
@Transactional），用INSERT ... ON CONFLICT DO NOTHING防重复 - 状态字段至少包含：
status（0=待发送，1=已发送，2=已确认，3=已失败），next_retry_at（时间戳，用于定时任务捞取） - 补偿任务不能简单“重发所有 status=0 的消息”，要加条件：
created_at < now() - INTERVAL '2 minutes'，避免刚发出去就被误重试 - 特别注意：补偿任务自身必须幂等，同一消息可能被多个实例同时捞到，要用 DB for update 或分布式锁控制
真正难的不是配置那几个开关，而是把 confirm 的异步回调、return 的路由校验、消费端的 ACK 时机、本地表的状态流转全部串成一条原子链路——任何一环脱钩，高并发下丢消息就是秒级发生的事。
