面试题：如何在 RabbitMQ 中处理消息的重复消费问题？

在 RabbitMQ 中处理消息的重复消费问题是一个常见的面试题，主要考察你对消息队列可靠性和幂等性设计的理解。以下是详细的回答思路：

1. 理解重复消费的原因

在分布式系统中，消息的重复消费可能由以下原因导致：

网络抖动：消费者成功处理了消息，但在向 RabbitMQ 发送 ACK（确认）时网络中断，导致 RabbitMQ 认为消息未被处理。
消费者崩溃：消费者在处理消息后未发送 ACK 就崩溃了，RabbitMQ 会将消息重新投递给其他消费者。
手动重试机制：某些情况下，消费者可能会因为业务逻辑失败而主动触发重试。

因此，即使 RabbitMQ 提供了消息确认机制（ACK/NACK），也无法完全避免重复消费的问题。

2. 解决方案

针对重复消费问题，可以从以下几个方面入手解决：

（1）生产者端：确保消息唯一性

在生产者发送消息时，可以为每条消息生成一个全局唯一的 Message ID，并将其作为消息的一部分发送到队列中。
消费者在处理消息之前，先检查是否已经处理过该 Message ID，如果已处理则直接丢弃。

# 示例：使用 Redis 存储已处理的消息 ID
message_id = message.get("id")
if redis_client.exists(f"processed:{message_id}"):
    # 已处理，跳过
    return
else:
    # 标记为已处理
    redis_client.set(f"processed:{message_id}", "1")
    # 处理消息逻辑

（2）消费者端：实现幂等性

幂等性是指无论消息被处理多少次，结果都是一样的。
设计消费者逻辑时，确保操作是幂等的。例如：
数据库更新操作可以通过主键或唯一约束来防止重复插入。
对于支付场景，可以通过订单号判断是否已支付成功。

-- 示例：通过订单号实现幂等性
INSERT INTO orders (order_id, status) 
VALUES ('12345', 'paid') 
ON DUPLICATE KEY UPDATE status = 'paid';

（3）消费者确认机制

确保消费者在处理完消息后，及时发送 ACK 给 RabbitMQ。
如果消费者在处理过程中发生异常，不要发送 ACK，让 RabbitMQ 自动将消息重新入队。

def callback(ch, method, properties, body):
    try:
        # 处理消息
        process_message(body)
        # 确认消息
        ch.basic_ack(delivery_tag=method.delivery_tag)
    except Exception as e:
        # 不发送 ACK，消息会重新入队
        print(f"Error processing message: {e}")