Redis 8.6 Streams 幂等生产怎么减少重复消息

Redis 8.6 给 Streams 增加了幂等生产能力。生产者执行 XADD 后如果网络断开，或者进程在收到回复前崩溃，恢复时可以用同一组生产者 ID 和幂等 ID 重试；Redis 会返回第一次写入的 entry ID，而不是再次追加一条消息。

官方地址：https://redis.io/

先判断重复是怎样产生的

最容易漏掉的窗口是“服务端已经追加，客户端没有拿到响应”。这时生产者无法判断消息是否成功，只能重试。另一种窗口是调用完成后进程立即退出，业务表还没来得及把 entry 标记为已发送。普通的 XADD stream * ... 每次都会生成新的 Stream ID，因此重试会留下两条内容相同但 ID 不同的记录。

Redis 8.6 的幂等生产只解决追加阶段的重复，不会替消费者处理业务。消费者仍然要用消费组、XACK、超时接管和业务侧幂等键处理重复投递。

业务有唯一编号时使用 IDMP

IDMP 把生产者 ID（pid）和消息幂等 ID（iid）交给应用生成。pid 应代表稳定的生产者身份，不能每次启动都随机变化；iid 应代表一个具体业务事件，例如订单事务号。相同的 pid+iid 再次提交时，Redis 返回原 entry ID，不会创建第二条记录。

# 使用订单事务号作为 iid；网络超时后必须原样重试这组 ID
redis-cli XADD orders IDMP order-service txn-20261006-0007 * \
  order_id 1007 status paid

# 恢复逻辑仍复用同一个 pid 和 iid，而不是重新生成 UUID
redis-cli XADD orders IDMP order-service txn-20261006-0007 * \
  order_id 1007 status paid

这里的关键不是两次 field-value 完全相同，而是同一业务消息要复用同一对标识。若应用把第二次重试误写成新的事务号，Redis 会把它视为新消息。

内容判重时再考虑 IDMPAUTO

IDMPAUTO 只要求提供稳定的 pid，Redis 根据消息内容计算 iid。它适合内容相同就必须视为同一事件的场景，例如重复上报同一份不可变快照。它不适合“字段相同但每次代表不同事件”的场景，因为内容判重会把这些事件合并。

# 内容本身就是事件身份；Redis 根据 field-value 生成 iid
redis-cli XADD telemetry IDMPAUTO sensor-writer * \
  device_id dev-17 reading 23.4 captured_at 2026-10-06T14:00:00Z

# 若 captured_at 每次重试都会变化，就不要用自动模式
# 改用 IDMP，并让 iid 使用上游事件号

两种模式都要求 pid 在生产者重启后保持不变。自动模式还多了一次内容哈希成本，换来的好处是应用不必自行维护 iid。

按恢复窗口配置去重记录

Redis 不会无限保存所有历史 iid。用 XCFGSET 设置每个 Stream 的保留时间和每个 pid 的最大追踪数：

# 预计故障恢复最长 15 分钟，每个生产者保留最近 2000 个 iid
redis-cli XCFGSET orders IDMP-DURATION 900 IDMP-MAXSIZE 2000

# 查看当前 Stream 的长度，结合生产速率检查 MAXSIZE 是否够用
redis-cli XLEN orders

IDMP-DURATION 的单位是秒，官方文档给出的范围是 1 到 86400；IDMP-MAXSIZE 控制每个生产者保留的最近 iid 数。配置时应覆盖“应用从崩溃到重新发送未确认消息”的最长时间，并给消息量留出余量。参数过小会让迟到重试再次写入，参数过大则增加内存占用。

常见问题

幂等生产能保证消费者只处理一次吗？

不能。它保证同一消息不会被生产端重复追加；消费组投递、超时重派和业务处理仍需消费者自己做幂等。

可以把 Stream entry ID 当作 iid 吗？

不建议。重试前通常拿不到第一次自动生成的 entry ID；应使用事务号、计数器或 UUID 等在调用前就确定的标识。

为什么配置改完后旧重试可能再次写入？

XCFGSET 修改去重参数时会清理该 Stream 的 IDMP 映射。变更前要确认没有依赖旧映射的迟到重试，必要时在业务层保留更长的发送记录。

落地时可以先为一个低风险 Stream 开启 IDMP，记录重试命中率，再根据最长恢复时间调整两个保留参数。这样既能减少重复消息，也不会把“生产端不重复”误当成完整的端到端 exactly-once。