Redis XREADGROUP 消费确认与重试的处理方案

Redis Streams 的消费确认和重试，关键不在“读到消息就算完成”，而在于把领取、业务成功、确认和故障接管分成四个动作。XREADGROUP 领取后，消息会进入消费组的 Pending Entries List（PEL）；业务真正成功后再执行 XACK。消费者宕机或处理超时，再用 XPENDING 观察并用 XAUTOCLAIM 或 XCLAIM 转交，最后由重试次数决定继续处理还是进入死信。

官方地址：https://redis.io/docs/latest/commands/xreadgroup/

先把 XREADGROUP 和 XACK 看成一条交接链

消费组把 Stream 中的工作分摊给多个 consumer。下面的命令只负责初始化示意，生产环境应把组名、consumer 名和错误处理交给应用配置：

# 中文注释：创建消费组；$ 起点表示从当前末尾开始接新消息
redis-cli XGROUP CREATE orders order-workers $ MKSTREAM

# 中文注释：只读取尚未交付给其他 consumer 的新消息
redis-cli XREADGROUP GROUP order-workers worker-a COUNT 10 BLOCK 2000 STREAMS orders >

# 中文注释：业务写库、扣库存等副作用成功后，再确认这个消息 ID
redis-cli XACK orders order-workers 1710000000000-0

同一条消息先被分配给 worker-a，就会记录在该 consumer 的 PEL 中；另一个 consumer 不会因为重复读取新消息而自动拿到它。XACK 只是确认指定 ID 已处理，并从这个消费组的 PEL 移除引用，不等于删除 Stream 原文。

确认时机决定消息会不会丢

一个稳妥的处理函数通常是：解析消息、校验业务幂等键、执行可重入的业务动作、记录结果，最后才发出 XACK。如果在解析或写库之前确认，进程随后崩溃时 Redis 已经认为消息完成，PEL 也无法再帮你找回。

反过来，业务已经成功但 ACK 因网络抖动没有送达，消息可能再次投递。这是消费组常见的至少一次语义，所以业务侧要把消息 ID 或订单号作为幂等键，不能把“重复投递”误认为 Redis 重复生产。

XPENDING 只负责观察，XAUTOCLAIM 负责回收

排查时先看消费组的 PEL，而不是盲目重复执行读取命令：

# 中文注释：先看总 pending 数、最早/最晚 ID 和各 consumer 的数量
redis-cli XPENDING orders order-workers

# 中文注释：只抽取空闲超过 60 秒的待确认消息，便于判断是否需要接管
redis-cli XPENDING orders order-workers IDLE 60000 - + 20

# 中文注释：把满足空闲阈值的消息交给 worker-recovery，并返回下一页游标
redis-cli XAUTOCLAIM orders order-workers worker-recovery 60000 0-0 COUNT 20

XPENDING 是观察动作，不会改变所有权。XAUTOCLAIM 适合做周期性恢复扫描，XCLAIM 适合应用已经拿到明确 ID 后的定向转移。转移后仍要正常执行业务和 XACK；claim 不是成功确认。

把重试设计成有边界的处理方案

建议把空闲阈值设为“正常处理时间的数倍”，而不是一个极小值。否则原 consumer 还在处理，恢复 worker 就可能提前接管，形成两个 worker 同时执行副作用。恢复后根据 delivery count 做分层：

• 低次数：短暂退避后继续处理，成功即 XACK。
• 中次数：记录错误原因和消息 ID，延长退避并告警。
• 达到上限：写入独立死信 Stream 或持久化表，再对原消息做明确的业务处置。

死信不是“删掉失败消息”。它应该保留原 ID、业务幂等键、最后错误和投递次数，方便修复代码后定向重放。若使用 NOACK，消息不会进入 PEL，只适合可以接受偶发丢失的场景，不应和可靠消费混用。

上线前检查这份小清单

• 每个进程使用稳定且唯一的 consumer 名，重启后能识别旧 consumer 是否留下 PEL。
• ACK 放在业务成功之后，业务动作可用消息 ID 或业务主键幂等。
• 恢复任务有明确的 idle threshold、扫描批量和并发上限。
• 记录 delivery count、最后错误和死信原因，并监控 PEL 总数及最老消息年龄。
• 规划 Stream 的保留窗口；过早 XTRIM 可能让仍在 PEL 中的原文不可重放。

相关问题

XREADGROUP 使用 0 和 > 有什么区别？

> 请求尚未交付给任何 consumer 的新消息；使用具体 ID（常见是 0）则是读取当前 consumer 自己的历史 pending 消息。恢复其他 consumer 的消息，应走 claim 或先观察后转移。

XAUTOCLAIM 后还需要 XACK 吗？

需要。claim 只改变 pending 消息的所有者，业务成功后仍要对原消息 ID 执行 XACK，否则它会继续留在 PEL 中。

为什么 PEL 数量一直下降不了？

常见原因是业务失败后没有 ACK 也没有恢复扫描，或者恢复后再次失败却没有限制重试。先用 XPENDING 看最老 ID、consumer 和 idle，再追踪该 ID 的 delivery count。

什么时候可以使用 NOACK？

只有当消息丢失的代价低于维护 PEL 和重试的代价时才考虑，例如可重建的统计刷新。订单、库存、支付结果等不可丢失任务不应使用它。