⭐ 题目日期：

小红书 - 2024/11/11

📝 题解：

在消息队列（MQ）中防止重复消费是一个关键问题，而Redis因其特性成为实现这一目标的常用工具。以下是使用Redis校验防止MQ重复消费的详细解释：

---

一、重复消费的常见原因

在分布式系统中，重复消费通常由以下场景引发：

1. 消费者重试机制：消费者处理失败后，MQ自动重试投递消息。
2. 生产者重复发送：生产者因网络抖动或超时重复发送消息（如Kafka的至少一次语义）。
3. 分区再均衡：MQ分区重新分配时，可能导致消费者重复拉取消息。

---

二、为什么选择Redis？

1. 高性能与低延迟

• Redis基于内存操作，读写速度极快（微秒级响应），适合高频校验场景。
• 直接通过内存判断消息是否已处理，避免因数据库查询导致的性能瓶颈。

2. 原子性操作

• Redis提供原子命令（如SETNX、EXPIRE），能确保“检查-写入”操作的原子性，避免并发竞争。
• 示例：通过SET key msg_id NX EX 3600，实现“不存在则设置并设置过期时间”的原子操作。

3. 灵活的数据过期机制

• 可为每个消息ID设置合理的过期时间（如业务处理的最大超时时间），避免内存无限增长。
• 自动清理已过期的消息ID，减少存储压力。

4. 分布式一致性

• Redis作为集中式缓存，所有消费者实例共享同一份数据，保证全局唯一性校验。
• 相比本地缓存（如Guava Cache），避免因多实例导致的状态不一致。

5. 高可用支持

• Redis集群、哨兵模式或云服务（如AWS ElastiCache）可保障高可用性，防止单点故障。

---

三、具体实现方案

1. 核心流程

1. 消息生产端：为每条消息生成唯一标识（如msg_id，通常由业务ID+时间戳+随机数组成）。
2. 消息消费端：
   • 收到消息后，先查询Redis中是否存在msg_id。
   • 若存在：直接丢弃消息（说明已处理）。
   • 若不存在：执行业务逻辑，成功后写入msg_id到Redis并设置过期时间。

2. 关键代码示例（伪代码）

def handle_message(msg):
    msg_id = msg.get("msg_id")
    # 原子操作：尝试设置msg_id，过期时间1小时
    is_new = redis.set(msg_id, "1", nx=True, ex=3600)
    if not is_new:
        print("消息已处理，直接跳过")
        return
    try:
        # 执行业务逻辑（如扣减库存、更新订单状态）
        process_business(msg)
    except Exception as e:
        # 处理失败时删除msg_id，允许重试
        redis.delete(msg_id)
        raise e

3. 容错设计

• 业务处理与Redis写入的原子性：
  • 方案一：先写Redis再处理业务。 风险：若业务处理失败，需手动清理Redis中的msg_id。
  • 方案二：先处理业务再写Redis。 风险：业务成功后Redis写入失败，导致重复消费。
  • 推荐方案：结合数据库事务与Redis写入，确保两者一致性（如本地事务表+异步补偿）。
• Redis数据丢失的兜底：
  • 持久化策略：启用AOF（Append-Only File）+ RDB快照，减少数据丢失风险。
  • 业务表去重：在数据库层通过唯一索引或状态字段二次校验。

---

四、与其他方案的对比

方案	优点	缺点
Redis去重	高性能、实现简单	依赖Redis可用性，需处理原子性问题
数据库唯一索引	强一致性，无需额外组件	高频写入时数据库压力大
MQ内置去重	透明化（如RocketMQ消息Key去重）	依赖MQ实现，灵活性不足
布隆过滤器	内存效率高	存在误判，不适用于100%准确场景

---

五、适用场景与注意事项

适用场景

• 高频消息场景（如秒杀、支付回调）。
• 允许短暂数据不一致，最终一致性要求较高的业务。
• 需要快速失败（Fast-Fail）避免重复处理的场景。

注意事项

1. 消息ID的设计：需全局唯一（如UUID、Snowflake算法），避免哈希冲突。
2. 过期时间设置：需大于业务最大处理时间，防止过早清理导致重复消费。
3. Redis容量规划：预估消息量及过期时间，避免内存溢出（如1亿条消息，每条16字节，约需1.6GB内存）。

---

六、总结

使用Redis防止MQ重复消费的核心优势在于高性能、原子性操作和分布式一致性支持。它能够有效拦截绝大多数重复消息，但需结合业务层的兜底机制（如数据库唯一索引）以实现100%准确性的要求。在架构设计时，需权衡性能、一致性与复杂度，选择最适合业务场景的方案。