Redis 8.6 Streams 怎样理解幂等消息处理

Redis 8.6 Streams 的幂等消息处理，核心是幂等生产：生产者在断线或重启后重发 XADD 时，Redis 在有效追踪范围内识别相同生产者与幂等标识，避免重复新增条目。它不是“消费者业务永远只执行一次”，也不会自动把 Redis 与外部数据库事务合成一个原子提交。

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

我看这项能力时，首先关心的不是省掉多少行去重代码，而是接口承诺到底覆盖哪一段。下面是基于官方语义的设计判断与原创示例，没有声称已经完成生产迁移或性能测试。

我先把接口目标限定为写入去重

设想设备上报服务发出一条事件，Redis 已接收，但网络在响应返回前断开。生产者不知道结果，仍需要重试。普通 XADD 使用自动条目 ID 时，两次提交可能形成不同条目；8.6 的新增参数正是处理这个写入歧义。

我会把接口目标写成“同一个逻辑事件在重试时不重复入流”，而不是“整个业务恰好一次”。这样拆分后，生产、消费和业务副作用各有负责人：XADD 的新语义处理提交去重；消费者确认处理进度；业务系统约束自身的重复副作用。

生产者需要保留的不只是消息内容

接口里有三个不同的标识：pid 是生产者身份，iid 是该生产者范围内的逻辑消息标识，条目 ID 是 Redis Stream 中的记录地址。不能拿“每次连接随机一个 pid”去实现跨重启的去重；同一事件重试也不能每次重新生成 iid。

我更愿意在待发送记录中保存 pid、iid 和消息内容，再由重试代码复用这份记录。不同事件即使字段完全相同，也可能仍然需要两条记录，此时必须给它们不同 iid。反过来，同一个 pid/iid 不应承载两个不同事件。

若多个生产者用不同 pid 表达同一业务事件，不能指望它们之间自动去重。是否跨生产者判定同一业务事件，应由业务身份设计决定，而不是把短字符串碰巧相同视为统一契约。

IDMP 和 IDMPAUTO 的参数取舍

IDMP pid iid 由应用提供两项标识；IDMPAUTO pid 由 Redis 根据字段和值计算 iid。两种方式都要求生产者重启后保持 pid。

对我来说，显式 IDMP 更适合“事件身份独立于内容”的系统。自动模式减少了生成 iid 的工作，却要求我接受“同一生产者下相同内容视为同一消息”的语义。如果两次独立温度读数恰好相同，而消息中又没有时间或业务事件标识，内容去重就可能把本应独立的事件合并。

另一个容易忽略的接口点是：命中既有 pid/iid 时，XADD 返回原条目 ID，而不是新增一条带新内容的记录。它不负责合并字段，更不是“同 iid 更新消息”的写法。重试记录应保持内容一致，改事件必须重新分配身份。

重试窗口决定保证能覆盖多久

Redis 需要保存近期见过的 iid，因此保证受时间和容量共同约束。流级 IDMP-DURATION 指定保留时间，单位秒；IDMP-MAXSIZE 限制每个 pid 保留的近期 iid 数量。达到容量限制时，不能再只拿时长推导覆盖范围。

我会同时估算最长恢复重试间隔、单生产者消息速率，以及消息已入流但本地尚未标记完成的积压量，再预留余量。参数不是越大越好：更多追踪记录也意味着内存成本。这里不直接套用固定默认值或虚构每秒吞吐。

XCFGSET 更改现有流的 duration 或 maxsize 值会清空该流的 IDMP 映射。因此，调整参数不是无副作用的在线小修补；应把它视为去重覆盖范围发生变化的变更。不要在每次发送前机械调用配置命令。

旧客户端升级不能悄悄取消去重

新增参数从 Redis 8.6 开始提供。只升级服务端，不代表客户端的高层 XADD 方法已经支持；反过来，客户端能编码参数，也不代表代理和所有目标节点都能接受。

迁移前应按具体客户端版本查看官方参数接口。若使用通用命令通道，应按独立参数编码，不拼接带用户输入的命令字符串。本文不指定未经确认的 SDK 最低版本。

我不会在收到新参数不支持、语法错误或权限错误时，自动删掉 IDMP 再重发普通 XADD：那虽然可能让请求成功，却已经撤销了上层依赖的保证。可行策略是显式失败、停止这条路径并由调用方处理，或采用事先定义并独立评估的旧版去重方案。

网络超时也不是“肯定没写入”。需要重试时保留原身份，在窗口与持久化等部署前提下处理；不能把内存里的去重记录理解为无条件的数据持久性承诺。

一组重复提交示例与采用清单

下面使用独立测试键，命令中的星号用引号保护，防止 shell 展开。只在支持该功能的隔离环境尝试；示例没有在本文环境运行。

# 同一逻辑事件首次提交：设备服务身份与事件号均保持稳定
redis-cli XADD demo:telemetry:idem IDMP sensor-agent-a event-temp-701 '*' device probe-7 value 24

# 模拟响应丢失后的原样重试；不重新生成 pid 或 iid
redis-cli XADD demo:telemetry:idem IDMP sensor-agent-a event-temp-701 '*' device probe-7 value 24

# 独立事件即使内容相同，也使用新的 iid
redis-cli XADD demo:telemetry:idem IDMP sensor-agent-a event-temp-702 '*' device probe-7 value 24

# 观察测试流条目与幂等追踪信息，不预设具体条目 ID
redis-cli XRANGE demo:telemetry:idem - +
redis-cli XINFO STREAM demo:telemetry:idem

在键原本不存在、无其他写入、追踪仍有效且没有删除裁剪的前提下，前两次提交应返回同一条目 ID；第三次属于独立事件，可新增条目。这是语义预期，不是已测输出。XINFO STREAM 的 iids-duplicates 等字段用于观察去重，不能当成业务处理成功次数。

消费者侧的 XACK 是从消费组待确认列表移除对应 ID，并非向外部数据库提交事务。我倾向于把业务去重记录与同一数据库中的业务写入置于同一事务，再按已定义的消费契约确认；如果涉及外部接口，则还要依赖该接口提供的幂等键或补偿策略。这是应用架构建议，不是 8.6 新增命令自动完成的工作。

IDMPAUTO 适合所有重复内容吗？

不适合需要保留多次独立相同内容事件的场景。先定义“相同业务事件”，再选择生成标识的方法。

升级后还能保留原来的消费去重吗？

可以，而且不能仅因启用幂等生产就删除它。生产者重试与消费者重复执行覆盖的是不同故障点。

我会给哪些系统采用它？

已经有稳定事件身份、可界定重试窗口、希望减少重复入流的系统值得采用。若身份随机、重试跨越不可控时间，或期待它替代跨系统事务，我会先修正接口契约，再决定是否启用。

参考：Streams 幂等生产、XADD 参数、XCFGSET、XACK、Redis 8.6 官方发布解读。