RabbitMQ 如何保证消息不丢失？

面试考察点

1. 考察对消息丢失场景的全面理解
   面试官不仅想知道 “你用过什么机制”，更想知道你是否清楚一条消息从发送到消费，哪个环节可能丢、为什么丢。

2. 考察对 RabbitMQ 核心特性的掌握程度
   包括生产者确认、消息持久化、消费者手动 ack、镜像/仲裁队列等。需要说出各自的原理、配置方式以及它们之间的协作关系。

3. 考察可靠性与性能的权衡意识
   保证不丢失往往伴随性能开销，面试官希望听到你如何根据业务场景做取舍，而不是 “所有项目都全量开启”。

4. 考察实际项目中的最佳实践
   能否说出生产环境的配置参数（如 spring.rabbitmq.publisher-confirm-type=correlated）、异常处理（如回调失败后的重试/补偿）以及监控报警。

5. 考察故障排查与问题定位能力
   隐含的问题可能是：“如果消息还是丢了，你怎么排查？” —— 这需要你结合上述机制，逆向推导可能出问题的环节。

核心答案

RabbitMQ 保证消息不丢失，必须从三个环节分别加固：

• 生产端：启用发布者确认（Publisher Confirms），同步或异步等待 Broker 返回 ack，确认消息已正确到达交换机/队列。
• 服务端：队列和消息都设置为持久化（durable + persistent），并部署镜像队列或 仲裁队列，避免单节点宕机导致数据丢失。
• 消费端：关闭自动 ack，使用手动确认（manual ack），并在业务处理成功后才调用 basicAck，失败时根据策略选择重入队或进入死信队列。

这三层缺一不可，组合使用才能达到生产级可靠性。

深度解析

生产端：确认机制 vs 事务

原理
RabbitMQ 提供了两种让生产者感知消息送达的方式：

• 事务（AMQP 事务）：txSelect() – txCommit() / txRollback()。
  阻塞式，每个消息要等待磁盘写入和集群同步，吞吐量急剧下降（约降低 250 倍），生产环境几乎弃用。

• 发布者确认（Publisher Confirm）：推荐方案。
  将信道设置成 confirm 模式，每条消息被分配唯一 ID。Broker 成功处理后异步回调生产者。
  JDK 8/17 + Spring AMQP 2.2+ 支持 CorrelationData 配合 ConfirmCallback，可精确感知是到达交换机还是队列。

代码示例（Spring Boot）

# application.yml
spring:
  rabbitmq:
    publisher-confirm-type: correlated   # 开启 confirm 回调
    publisher-returns: true             # 开启 return 回调（消息未路由到队列时触发）

// 生产者发送时携带 CorrelationData
CorrelationData cd = new CorrelationData(UUID.randomUUID().toString());
rabbitTemplate.convertAndSend(exchange, routingKey, message, cd);

// 异步确认回调
rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
    if (!ack) {
        // 记录日志，落库标记失败，定时重试
    }
});
// 消息无法路由时的回调
rabbitTemplate.setReturnsCallback(returned -> {
    // 处理未找到队列的消息
});

最佳实践

• 结合数据库落库：消息发送前先存业务库，收到 confirm 后更新状态为“已发送”；
• 定时任务扫描长时间未确认的消息，重新发送。

服务端：持久化 + 高可用

持久化

• 交换机：durable=true
• 队列：durable=true
• 消息：发送时设置 deliveryMode=2（持久化）
  注意：仅持久化不代表数据不丢。消息在 RabbitMQ 收到后先写内存，持久化是异步刷盘，存在短时间窗口。若在刷盘前宕机，消息仍会丢失。

高可用方案

• 镜像队列（镜像模式）：传统 HA 方案，master 与 slave 同步数据，但性能损耗大，且有脑裂风险。
• 仲裁队列（Quorum Queue，RabbitMQ 3.8+）：官方推荐。
  基于 Raft 协议，强一致性，要求集群多数节点写入成功才算确认。相比镜像队列，更稳定、更适配容器化。

配置示例

// 声明仲裁队列
@Bean
public Queue quorumQueue() {
    return QueueBuilder.durable("queue.name")
            .quorum()   // 设置为仲裁队列
            .build();
}

最佳实践

• 集群至少 3 个节点，仲裁队列副本数默认 3；
• 配合 ha-mode: exactly 固定副本数量，避免数据倾斜。

消费端：手动 ack 与重试

机制

• 自动 ack（autoAck=true）：Broker 发出消息立即标记为已消费，若消费者处理时宕机/异常，消息即丢失。
• 手动 ack（autoAck=false）：业务处理成功才调用 basicAck；处理失败可调用 basicNack，参数 requeue=true 重新入队（可能造成循环），requeue=false 进入死信队列。

代码示例（Spring RabbitListener）

@RabbitListener(queues = "business.queue")
public void handleMessage(Message message, Channel channel, @Header(AmqpHeaders.DELIVERY_TAG) long tag) {
    try {
        // 业务处理
        channel.basicAck(tag, false);
    } catch (Exception e) {
        // 记录异常，根据重试次数决定是否丢弃或死信
        channel.basicNack(tag, false, false); // requeue=false
    }
}

常见误区

• 以为手动 ack 就能 100% 不丢，却在业务代码中忘记处理异常，导致未 ack 连接断开，消息重新入队（可能被其他节点消费），造成重复消费；
• 未设置死信队列，失败消息无限重入队，阻塞队列。

最佳实践

• 结合 Spring Retry 或自定义重试模板，达到重试上限后发往死信交换机；
• 消费逻辑保持幂等性，应对可能的重发。

对比分析：镜像队列 vs 仲裁队列

维度	镜像队列	仲裁队列
一致性模型	异步复制，最终一致	Raft 强一致
性能	高延迟，同步复制阻塞	较高，批量提交，ZooKeeper 风格
脑裂问题	存在，需配置 cluster_partition_handling	无，Raft 自动解决
适用版本	全版本	3.8+
推荐度	已逐渐被仲裁队列替代	新项目首选

总结

RabbitMQ 保证消息不丢失，不是靠单一特性，而是生产者 confirm + 消息持久化 + 仲裁队列 + 消费者手动 ack 的组合拳。

理解每个环节的风险点，并针对业务场景平衡可靠性与吞吐量，才是面试官真正期待的回答。如果在生产环境遇到消息丢失，请按 生产者回调 → 队列持久化 → 消费 ack 的路径逐一排查，很快就能定位到“掉链子”的环节。