Redis Streams 怎么用消费者组重试超时未确认消息

Redis Streams 消费者组里的消息，如果已经被 XREADGROUP 投递却没有执行 XACK，就会留在 Pending Entries List（PEL）中。处理这类“超时未确认”消息，比较稳妥的顺序是：先用 XPENDING 看归属、空闲时间和投递次数，再用 XAUTOCLAIM 把达到阈值的消息转给健康消费者，业务成功后由新消费者执行 XACK。不要把 XAUTOCLAIM 当成删除命令，它只改变 pending 消息的所有权。

先用 XPENDING 看清消息为什么卡住

先看消费者组摘要，不要一上来就批量接管。下面的命令会返回 PEL 中的消息数、最小和最大消息 ID，以及各消费者名下的 pending 数量：

# 查看 orders:stream 在 workers 组中的 PEL 摘要
XPENDING orders:stream workers

# 查看全部消费者中最多 20 条明细
XPENDING orders:stream workers - + 20

明细通常包含四个关键信息：消息 ID、当前消费者、空闲毫秒数和投递次数。空闲时间说明它距离上次投递或接管已经多久，投递次数则帮助判断它是偶发延迟，还是一直失败。比如某条消息仍归属于已经下线的 worker-a，且 idle time 已超过业务允许的处理窗口，就具备被接管的条件。

可以把判断条件整理成一张小表：

用 XAUTOCLAIM 接管超时 pending 消息

XAUTOCLAIM 从 Redis 6.2 开始提供自动扫描 PEL 的方式。它接收 Stream key、消费者组、接管者、最小空闲毫秒数和起始游标，并把符合条件的消息所有权转移给接管消费者，同时返回下一次扫描使用的游标。

# recovery-1 只接管空闲超过 60 秒的消息，每次尝试 20 条
XAUTOCLAIM orders:stream workers recovery-1 60000 0-0 COUNT 20

第一次从 0-0 开始。返回的第一个值是下一游标；如果仍未返回 0-0，应保存游标继续扫下一段。COUNT 是每次尝试处理的上限，不是最终一定能拿到的消息数，因为 Redis 还要过滤掉未达到 min-idle-time 的条目。

生产代码通常让一个恢复消费者周期性扫描，而不是让每个业务消费者同时从 0-0 开始。扫描者只保留游标和阈值配置；拿到消息后先执行业务幂等处理，成功才确认：

# 业务处理成功后确认；失败则暂不 XACK，让它继续留在 PEL
XACK orders:stream workers 1700000000000-0

# 只需要 ID 时可减少返回体，但要注意 JUSTID 不会增加投递计数
XAUTOCLAIM orders:stream workers recovery-1 60000 0-0 COUNT 20 JUSTID

把重试、确认和重复消费边界补齐

接管不是“消息只会执行一次”的保证。原消费者可能在业务已经落库、但尚未 XACK 时宕机，恢复消费者就可能再次拿到同一条消息。因此处理函数要以消息 ID 或业务唯一键做幂等约束，例如订单状态更新使用条件写入、外部副作用使用去重表。只有确认业务结果已经可重复安全地接受，才调用 XACK。

重试策略至少要有三条边界：第一，阈值必须大于正常处理的长尾时间，避免两个活跃消费者同时处理；第二，按 delivery count 限制无限重试，把持续失败的消息转移到专门的错误流或人工队列；第三，恢复扫描要使用固定 COUNT 和可续接游标，避免一次接管造成新的处理尖峰。XDEL、XTRIM 解决的是 Stream 数据保留，不等价于完成消费者组确认。

常见问题：为什么看到了消息却不能直接删除

XPENDING 会改变消息的消费者归属吗？

不会。它是观察接口，只读取 PEL 信息；改变归属要用 XAUTOCLAIM 或针对明确 ID 的 XCLAIM。

XAUTOCLAIM 返回 0-0 就代表消息处理成功了吗？

不是。0-0 只表示本轮扫描已经到达 PEL 末端。处理结果仍由业务代码决定，成功后必须另行执行 XACK。

应该把 min-idle-time 设成多少？

用正常处理耗时的高分位、实例故障恢复时间和允许重复消费的成本共同决定。太短会误接管仍在处理的消息，太长则会让故障消息在 PEL 中等待过久；先观察 idle time 与 delivery count，再逐步调参。