Redis Streams XREADGROUP 后 Pending List 怎么处理

Redis Streams 用 XREADGROUP 消费消息后，消息没有立刻消失是正常的：只要消费组还没有收到 XACK，这条消息就会留在 Pending Entries List（PEL）里。真正需要处理的是先判断它仍在正常消费、属于当前 consumer 的历史，还是已经由失联 consumer 持有。

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

处理 PEL 的固定顺序是：用 XPENDING 看清归属和 idle 时间；原 consumer 用具体 ID 恢复自己的历史；故障 consumer 的消息由健康 consumer 用 XAUTOCLAIM 接管；业务成功后一定执行 XACK。

为什么 XREADGROUP 后消息会留在 Pending List

XREADGROUP 以消费组读取消息时，Redis 会记住消息交给了哪个 consumer。业务处理成功后，应用再发送 XACK stream group message-id，消息才会从该组的 PEL 中移除。进程崩溃、网络断开、处理超时或代码漏掉确认，都会让 pending 数量继续增加。

先不要把 pending 和 lag 混为一谈。前者是已经投递但未确认的消息，后者是还没有交给任何 consumer 的消息。可以先看消费组状态：

# 查看消费组的 pending、last-delivered-id 和 lag
redis-cli XINFO GROUPS orders-stream

如果 pending 很高而 lag 很低，重点是恢复或转移旧消息；如果两者都高，还要同时检查生产速度、消费并发和单条处理耗时。PEL 是消费状态索引，不替代 Stream 本身，也不应该用删除 Stream 或删除 key 的方式“清理积压”。

用 XPENDING 定位消息归属和空闲时间

XPENDING 建议分两次用。第一种是摘要，适合快速判断总量、最早和最晚消息 ID 以及涉及的 consumer：

# 先看消费组 PEL 的总览，不一次拉取大量消息
redis-cli XPENDING orders-stream orders-group

# 再按小批量查看消息 ID、所属 consumer、idle 毫秒数和投递次数
redis-cli XPENDING orders-stream orders-group - + 10

明细通常能回答四个问题：消息 ID 是什么、目前归谁、多久没有再次投递、已经投递过几次。不要只按投递次数判断故障；一个正在处理大任务的消息也可能暂时 idle，应该结合业务最大处理时长设置接管阈值。

当前消费者恢复自己的历史消息

如果原 consumer 只是短暂重启，优先让它恢复自己持有的消息。与读取新消息时的 > 不同，具体 ID 会读取这个 consumer 自己曾经收到但尚未确认的历史：

# worker-a 只恢复自己名下的历史 PEL，按小批量处理
redis-cli XREADGROUP GROUP orders-group worker-a COUNT 10 STREAMS orders-stream 0

每条消息成功处理后再确认：

# 只在业务副作用成功后确认；失败时保留在 PEL 供重试
redis-cli XACK orders-stream orders-group 1710000000000-0

这种方式不会替别人接管消息，也不会把全组 PEL 重新扫一遍。恢复循环结束后，再用 XPENDING 按 consumer 查询，确认 worker-a 的数量是否下降。

故障消费者用 XAUTOCLAIM 转移消息

原 consumer 已经失联时，健康 consumer 可以按照最小空闲时间接管消息。XAUTOCLAIM 会改变消费组中的所有权，并返回下一次扫描位置和被接管的消息；COUNT 应设置为小批量，避免一次把恢复压力放大。

# 只接管 idle 至少 60 秒的消息，0-0 表示从 PEL 起点查找
redis-cli XAUTOCLAIM orders-stream orders-group worker-recover 60000 0-0 COUNT 10

接管不是确认。健康 consumer 仍要读取返回的字段，执行幂等业务逻辑，成功后对原消息 ID 调用 XACK。如果只需要先扫描 ID，可以使用 JUSTID，再按业务策略决定是否拉取完整字段。

阈值不要照搬 60 秒。它至少应大于正常处理耗时的高分位，并留出网络抖动和短暂 GC 的余量。阈值过小会让两个 consumer 同时处理同一业务，阈值过大则会让故障消息等待太久。

建立幂等、重试和清理检查

PEL 恢复的难点不在命令本身，而在重复投递后的业务边界。支付、库存、通知等副作用应使用 Stream 消息 ID 或业务唯一键做幂等约束；处理失败时保留错误原因和投递次数，超过上限后进入死信流或人工队列，不要无限 XAUTOCLAIM。

• 确认前：业务结果已落库或外部调用已有可重试的幂等键。
• 接管前：idle 超过阈值，且原 consumer 没有健康心跳或处理日志。
• 收尾后：用 XINFO GROUPS 看 pending，按 consumer 用 XPENDING 复查，并把消息 ID 与应用日志关联。

最后保留一条可回滚的检查记录：接管时间、原 consumer、目标 consumer、消息 ID、处理结果和 XACK 结果。这样既能确认 PEL 正常回落，也能在重复副作用出现时定位责任边界。

相关问题

XREADGROUP 的 > 能读取 Pending List 吗？

不能。> 表示读取从未投递给任何 consumer 的新消息；恢复当前 consumer 的历史要使用具体 ID，例如 0。

可以直接删除 PEL 中的消息吗？

不要把删除 Stream 条目当作确认。业务成功后使用 XACK 移除消费组的 pending 状态；需要清理数据时再单独设计 Stream 保留策略。

XAUTOCLAIM 后还需要 XACK 吗？

需要。XAUTOCLAIM 只转移所有权，不代表业务已成功；健康 consumer 完成处理后仍要对原消息 ID 执行 XACK。