详解MQ如何避免消息重复消费和消息丢失？

在项目中，消息重复消费和消息丢失是 RabbitMQ 使用过程中常见的可靠性问题。以下是结合实际场景和解决方案的总结：

一、消息重复消费

1. 原因分析

• 网络波动：消费者处理消息后未及时发送 ACK，网络中断导致 RabbitMQ 认为消息未被消费，重新投递。
• 消费者宕机：消费者处理消息时崩溃，未发送 ACK，消息重新入队。
• ACK 机制失败：消费者手动 ACK 时发生异常，导致消息未被正确确认。

2. 解决方案

（1）幂等性设计

确保消费者处理逻辑对重复消息无副作用，例如：

• 数据库唯一约束：通过业务字段（如订单号）的唯一性约束防止重复插入。

  CREATE TABLE orders (
      id VARCHAR(64) PRIMARY KEY, -- 订单号作为主键
      amount DECIMAL(10, 2)
  );
  

  // Java 示例（使用 MyBatis）
  public void processOrder(Order order) {
      try {
          orderMapper.insert(order); // 唯一约束冲突时会抛出异常
          // 业务逻辑...
      } catch (DuplicateKeyException e) {
          log.warn("订单已存在: {}", order.getId());
      }
  }
  

• Redis 去重：记录已处理消息的 ID，通过 SETNX 命令实现原子性检查。

  public boolean isMessageProcessed(String messageId) {
      Boolean result = redisTemplate.opsForValue().setIfAbsent("msg:" + messageId, "1", Duration.ofMinutes(30));
      return Boolean.TRUE.equals(result);
  }
  
  public void consumeMessage(Message message) {
      String messageId = message.getMessageId();
      if (!isMessageProcessed(messageId)) {
          return; // 已处理过，直接返回
      }
      // 业务逻辑...
  }
  

（2）手动 ACK 机制

• 关闭自动确认，在消息处理成功后手动发送 ACK，避免未处理完成的消息被 RabbitMQ 误判为已消费。

  # Spring Boot 配置文件
  spring:
    rabbitmq:
      listener:
        simple:
          acknowledge-mode: manual  # 手动确认
          prefetch: 1  # 每次只处理一条消息
  

  // Java 示例（手动 ACK）
  @RabbitListener(queues = "demo_queue")
  public void consumer(Message message, Channel channel) throws Exception {
      try {
          // 处理消息逻辑
          processMessage(message);
          // 手动确认
          channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
      } catch (Exception e) {
          // 拒绝消息并重新入队
          channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
      }
  }
  

（3）消息全局唯一 ID

• 生产者端：为每条消息附加唯一 ID（如 UUID）。

  public void sendOrder(Order order) {
      String messageId = UUID.randomUUID().toString();
      Message message = MessageBuilder.withBody(order.toJson().getBytes())
          .setHeader("messageId", messageId)
          .build();
      rabbitTemplate.send("order.exchange", "order.key", message);
  }
  

• 消费者端：检查消息 ID 是否已处理，避免重复处理。

二、消息丢失

1. 原因分析

• 生产者发送失败：消息未正确发送到 RabbitMQ。
• 队列未持久化：RabbitMQ 崩溃导致内存中的消息丢失。
• 消费者未确认：消费者处理失败且未拒绝消息，导致消息被标记为已消费。

2. 解决方案

（1）生产者确认机制（Confirm 模式）

• 开启 Confirm 模式，确保消息成功写入 RabbitMQ。

  // Java 示例（Confirm 模式）
  channel.confirmSelect(); // 开启确认模式
  channel.basicPublish(exchange, routingKey, props, body);
  if (!channel.waitForConfirmsOrDie(5000)) {
      // 重试或记录日志
  }
  

• Mandatory 参数：消息无法路由到队列时返回给生产者，避免消息丢失。

  channel.basicPublish(exchange, routingKey, true, props, body);
  

（2）消息和队列持久化

• 队列持久化：声明队列时设置 durable=true。

  channel.queueDeclare("durable_queue", true, false, false, null);
  

• 消息持久化：设置消息的 delivery_mode=2。

  AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
      .deliveryMode(2) // 持久化
      .build();
  channel.basicPublish(exchange, routingKey, props, body);
  

（3）消费者手动 ACK 和死信队列

• 手动 ACK：确保消息处理完成后才发送确认。

  spring:
    rabbitmq:
      listener:
        simple:
          acknowledge-mode: manual
  

• 死信队列：未被正确消费的消息进入死信队列，便于后续处理。

  // 声明死信队列
  Map<String, Object> args = new HashMap<>();
  args.put("x-dead-letter-exchange", "dead_letter_exchange");
  channel.queueDeclare("normal_queue", true, false, false, args);
  

三、总结

问题类型	核心解决策略
消息重复消费	幂等性设计（唯一约束/Redis去重） + 手动 ACK + 唯一消息 ID
消息丢失	生产者 Confirm 模式 + 队列/消息持久化 + 消费者手动 ACK + 死信队列

四、注意事项

1. 幂等性设计优先级：即使采取了所有可靠性措施，仍需在业务逻辑层保证幂等性。
2. 性能与可靠性平衡：
   • 高吞吐场景：使用 Redis 去重（内存速度快）。
   • 强一致性场景：使用数据库唯一约束（持久化保障）。
3. 监控与告警：通过 RabbitMQ 管理插件（management plugin）实时监控队列状态，设置阈值告警。

通过上述策略，可以有效减少 RabbitMQ 中的消息重复消费和消息丢失问题，确保系统的可靠性和一致性。