消息丢失只会发生在生产端、MQ 服务端、消费端三个环节，想要零丢失必须三个环节层层设防，配套持久化、确认机制、限流、故障转移、死信队列兜底。下面分场景拆解丢失原因 + 对应的解决方案。
一、整体丢失根源梳理
- 生产者发送阶段：消息没抵达 Broker、网络闪断、路由错误、发送成功误以为失败；
- Broker 服务端：内存消息未落盘、节点宕机、队列未持久化、集群故障；
- 消费者消费阶段：自动 ACK 提前确认，消息还没执行业务逻辑程序崩溃，消息直接丢失。
二、第一阶段：生产者端保证消息可靠投递（不丢发出的消息）
1. 问题场景
- 网络波动，消息发出去 MQ 没收到；
- exchange 不存在、路由键匹配不到队列，消息被直接丢弃；
- 生产者默认发完就认为成功，无回执，不知道消息是否入队。
解决方案
方案 1：开启 Publisher Confirm（生产者确认机制，官方推荐）
Broker 收到消息后主动回调通知生产者：消息已经成功存入队列。 两种模式：
- 同步 confirm：发送一条阻塞等待 ACK，可靠性最高，吞吐量偏低；
- 异步 confirm：注册回调，收到成功 / 失败通知异步处理，兼顾性能与可靠。
配置要点（Java SpringBoot 示例逻辑）
# 开启生产者确认
spring.rabbitmq.publisher-confirm-type=correlated
# 开启消息退回（路由失败时回调）
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.template.mandatory=truemandatory=true：消息路由失败（无匹配队列）不会直接丢弃，触发 return 回调，生产者自行缓存重试。
方案 2：Publisher Transaction 事务模式
开启 AMQP 事务，channel.txSelect()发送消息后手动txCommit()； 缺点：性能极差，吞吐量下降几十倍，线上基本不用，优先 Confirm 机制。
方案 3：本地消息表 / 事务消息（终极可靠，分布式场景）
适合强一致性场景（数据库业务操作 + 发消息必须原子性）：
- 执行业务 SQL 同时往本地消息表插入待发送消息，状态为「待发送」；
- 定时任务轮询本地消息表，取出未发送消息投递 MQ；
- 收到 MQ confirm 成功后，更新消息表状态为「已发送」；
- 投递失败不断重试，失败次数超限标记异常人工处理。
方案 4：消息前置缓存 + 重试
发送失败先存入本地内存 / Redis，定时重试，设置最大重试次数，避免无限重试压垮 MQ。
补充：路由失败兜底
绑定备份交换机 Alternate Exchange，路由不到目标队列的消息自动转入备用队列，不会直接丢弃。
三、第二阶段：RabbitMQ Broker 服务端防止消息丢失
1. 丢失场景
- 队列、交换机未声明持久化，MQ 重启后全部清空；
- 消息投递到内存队列，还没刷盘落盘，服务器宕机断电；
- 单节点部署，节点挂掉无备份数据。
2. 四层持久化配置缺一不可
（1）交换机持久化 durable=true
创建 Exchange 时标记持久化，MQ 重启交换机不会消失。
（2）队列持久化 durable=true
队列本身元数据落地磁盘，重启队列不销毁；
注意：队列持久化≠消息持久化。
（3）消息持久化 deliveryMode=2
发送消息时设置投递模式：
1：非持久化（内存，重启丢失）；2：持久化，消息写入磁盘。
（4）开启磁盘刷盘机制
RabbitMQ 收到持久化消息不会立刻同步刷盘，默认异步刷盘； 极端宕机可能极少量内存缓存消息丢失，优化配置：
# 调整刷盘策略，缩短刷盘间隔
rabbit_disk_monitor:set_low_watermark({mem_relative, 0.4}).3. 集群高可用部署
模式 1：普通集群（仅同步元数据，消息不复制）
队列只存在创建节点，该节点宕机队列不可用，不能保证消息不丢。
模式 2：镜像队列（经典高可用，推荐）
队列主节点 + 若干镜像副本，消息实时同步到镜像节点：
-
主节点接收消息写入磁盘，同步给镜像；
-
主节点宕机，自动选举镜像节点升级为主队列，数据不丢失；
-
配置策略指定哪些队列开启镜像复制：
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
模式 3：Quorum Queue（仲裁队列，RabbitMQ 3.8 + 官方主推）
基于 Raft 一致性算法，比镜像队列性能、稳定性更好：
- 至少半数节点写入成功才算消息提交；
- 天然支持故障自动切换、数据强一致，优先新项目使用仲裁队列替代镜像队列。
4. 磁盘与内存水位保护
防止 MQ 内存打爆触发自动清理非持久化消息： 配置内存高水位，达到阈值阻塞生产者发送，拒绝新消息，避免 MQ OOM 丢消息。
四、第三阶段：消费者端杜绝消息丢失（最容易踩坑的环节）
1. 核心丢失原因
默认自动 ACK（autoAck=true）：MQ 把消息投递给消费者之后，立刻标记消息删除。 此时消费者刚拿到消息，还没处理业务逻辑就宕机、kill 进程、异常崩溃，消息永久丢失。
2. 解决方案：手动 ACK 确认机制
核心配置：关闭自动签收，手动告知 MQ 处理结果
# 关闭自动ACK，手动签收
spring.rabbitmq.listener.simple.acknowledge-mode=manual业务处理分三种回执：
- basicAck(deliveryTag, multiple=false)：业务正常处理完毕，MQ 删除该消息；
- basicNack(deliveryTag, requeue=true)：处理失败，消息重新放回队列，下次重新消费；
- basicNack(requeue=false)：消费多次依旧失败，拒绝重回原队列，转入死信队列。
正确业务执行流程
MQ推送消息 → 本地保存日志/幂等校验 → 执行业务逻辑（DB操作）→ 执行成功 → 手动ACK
执行业务异常 → 不ACK，nack重回队列重试禁止的错误写法
业务代码还没执行，提前调用 ACK；捕获异常后直接 ACK，等同于丢弃消息。
3. 配套优化方案
（1）合理重试次数，避免无限死循环重试
同一消息反复消费失败（数据错误、参数异常），一直重回队列会无限占用资源：
- 本地设置重试次数（3~5 次）；
- 次数耗尽后拒绝入队，投递到死信队列 DLQ。
（2）死信队列 DLX（兜底兜底）
绑定规则： 消息满足以下条件自动转入死信交换机 + 死信队列：
- nack 且 requeue=false；
- 消息过期 TTL；
- 队列达到最大长度被丢弃； 后续人工监听死信队列，排查异常数据，修复后重新投递。
（3）消费幂等性（防止重复消费带来业务问题）
ACK 重试、网络重复推送会出现同一条消息多次消费，业务上看似 "消息丢了 / 数据错乱"： 实现方案：
- 每条消息携带唯一业务 ID（orderId、msgId）；
- 数据库唯一索引约束，重复插入直接报错；
- Redis 记录已处理 msgId，消费前先判断是否已处理；
- 状态机控制业务订单状态，重复执行不会篡改数据。
（4）限流保护
消费者处理速度跟不上生产速度，消息堆积打爆内存，MQ 可能触发策略清理； 设置 prefetch 手动拉取数量：
spring.rabbitmq.listener.simple.prefetch=10同一时间最多拿到 10 条消息，处理完 ACK 之后再拉新消息，避免大量消息积压在客户端。
五、其他辅助防丢优化手段
1. 消息过期 TTL 谨慎配置
设置消息 TTL 到期后会被 MQ 自动删除，业务不需要过期不要随便配置，避免消息还没消费就过期丢失。
2. 监控告警
监控指标：消息堆积量、死信队列数量、消费失败率、节点状态、磁盘使用率；堆积暴涨、死信激增及时介入处理。
3. 网络层优化
生产者、消费者与 MQ 之间开启长连接保活，心跳检测，断开自动重连，临时网络断开不会直接丢弃消息。
4. 禁止随意清空队列、重启服务
运维操作前先暂停生产者，等待堆积消费完毕再重启节点，避免强制下线导致正在同步的消息丢失。
六、一套线上标准「零丢失落地架构总结
-
生产者 开启 publisher-confirm+return 回调 + mandatory=true；重要业务搭配本地消息表可靠投递；失败重试，路由异常转入备用交换机。
-
Broker 交换机 + 队列持久化 + 消息 deliveryMode=2 持久化；部署仲裁队列 Quorum Queue 集群；监控磁盘内存水位，开启镜像 / 集群高可用。
-
消费者 关闭 autoAck，手动 ACK；业务成功 ack，异常 nack 重试；限定最大重试次数，失败转入死信队列；消费端做好幂等；设置 prefetch 限流。
-
兜底层 死信队列异常数据归档 + 全链路日志记录每条 msgId 收发记录，丢消息可追溯定位；定时巡检死信与堆积。
七、常见面试精简总结
- 生产端：Confirm 确认机制、mandatory、本地消息表；
- 服务端：交换机 + 队列 + 消息三重持久化、集群高可用（仲裁队列）；
- 消费端：手动 ACK，拒绝自动签收；失败重试 + 死信队列 + 幂等； 三个环节全部配置到位，RabbitMQ 可以做到理论上几乎不会丢失消息。