Redis Streams 重试如何避免重复入流：幂等生产的消息身份边界

生产者最难受的场景不是 Redis 直接报错，而是 XADD 已经到达服务端，客户端却在等待响应时断了网。程序只能重试；如果第二次仍使用 *，Redis 会把它当成新消息。Redis 8.6 的 IDMP 和 IDMPAUTO 给这段窗口增加了生产端去重能力，但它解决的是“消息是否重复入流”，不是消费者端的恰好一次处理。

为什么自动生成的 Stream ID 不能承担幂等身份

普通写法是：

XADD order-events * order_id 9001 amount 3

这里的 * 让 Redis 生成一个单调递增的 Stream entry ID。它很适合做顺序游标，却不适合做重试键：第一次请求的响应丢失时，生产者根本不知道原始 ID；多生产者并行写入时，也不能自行安全地猜下一个 ID。

所以，超时后再发一次相同字段，Redis 看到的是两个独立的 XADD 请求。启用 IDMP 后，Redis 去重记录会把稳定的身份映射到原始条目；消费者组的 XACK、PEL 和重投机制发生在消费侧，无法替生产者判断这两个请求是不是同一条业务消息。

先把 pid 和 iid 设计成可重放的消息身份

pid 是生产者身份，要求唯一，并且在进程重启后仍保持一致；iid 是该生产者下的消息身份，要求同一条消息重试时不变。订单号、事务号或稳定 UUID 都可以承担 iid，关键不在格式，而在重试前后是否相同。

如果两条业务消息的字段内容可能完全相同，优先使用显式 iid。IDMPAUTO pid 依赖消息内容生成 iid，相同内容可能被当成同一消息；这不是命令失效，而是身份选择与业务语义不匹配。

把 IDMP 重试边界落到 XADD 命令

显式身份的最小写法如下，producer-api 是稳定的 pid，txn-9001 是这条消息的 iid：

XADD order-events IDMP producer-api txn-9001 * order_id 9001 amount 3

# 发生超时后，仍然复用同一个 pid 和 iid
XADD order-events IDMP producer-api txn-9001 * order_id 9001 amount 3

两次调用命中同一组身份时，Redis 不会再向 Redis Stream 插入重复条目，第二次返回原始 Stream entry ID。应用应记录这组返回值，并把“返回 ID 相同”作为验证信号，而不是只看客户端有没有异常。

内容天然唯一时，也可以使用：

XADD order-events IDMPAUTO producer-api * order_id 9001 amount 3

这个写法省掉了 iid 的生成，但代价是身份由消息内容决定。支付金额、时间戳或随机字段一变，就可能不再是同一条消息。需要严格绑定事务号时，显式 IDMP 更容易审计和回放。

和旧的业务去重方案对比它真正解决了什么

过去常见的做法是先用 SETNX 写一把幂等锁，再执行 XADD；或者由业务数据库 outbox 表保存发送记录。这些方案仍有价值，但它们需要处理锁过期、发送结果未知以及数据库和 Redis 两套状态不一致的问题。Redis 8.6 的 at-most-once production guarantee 把“重复提交同一条 Stream 消息”的判断放进了 XADD 语义里。

边界也要写清：Redis 只保证生产端的重复入流判断。Stream 里的条目仍可能因为消费者崩溃而处于待处理状态；消费者组依旧需要 XREADGROUP、XACK、重投和业务幂等。若还要保证数据库更新与事件发布的一致性，outbox 或事务消息仍不能省略。

上线前用返回值和保留边界做一次验证

上线前至少保留四项记录：pid、iid、每次 XADD 返回的 Stream entry ID，以及客户端认为发生超时的次数。测试进程重启、连接断开和相同内容两条消息，分别确认“没有新增条目”“换 iid 后确实是另一条消息”。

还要核对部署版本和 IDMP 相关配置是否可用。不要把“重复返回原始 ID”写成永久历史去重承诺，也不要把 Redis 8.6 的生产端 at-most-once 直接宣传成端到端 exactly-once。监控上把重复命中、真正新增和消费者未确认分开计数，排障会清楚很多。

常见问题

同一消息只要复用 Stream entry ID 就能去重吗？

不能。生产者在响应丢失时通常拿不到原始 ID，而且显式 Stream ID 还必须满足递增约束。应使用稳定的 pid+iid，让 Redis 判断重复。

IDMPAUTO 和 IDMP 应该怎么选？

消息内容本身能唯一标识业务事件时可用 IDMPAUTO；内容可能相同或需要按事务号审计时，使用显式 IDMP。

用了 IDMP 还需要消费者端幂等吗？

需要。IDMP 只收口生产端重复入流，消费者崩溃重投、数据库更新和跨系统副作用仍要由消费侧设计幂等。