Redis Stream 消费者挂掉后消息卡在 PEL：用 XAUTOCLAIM 做可重复的接管流程

Redis Stream 消费者挂掉后，消息通常不是“消失”了，而是停在消费者组的 Pending Entries List（PEL）里：它已经被 XREADGROUP 投递，却还没有 XACK。这时直接重启同名消费者，往往只能解决新消息消费，不能可靠地处理旧 PEL。更稳妥的做法是先确认空闲时间，再用 XAUTOCLAIM 分批接管，处理成功后由恢复消费者确认。

先确认 PEL：消息卡住不等于消息没写进 Stream

先看消费者组的待确认总量和每条消息的空闲时间：

XPENDING orders order-workers
XPENDING orders order-workers - + 20
XINFO CONSUMERS orders order-workers

如果某条消息的 idle time 已经超过你的处理超时，它才是候选接管对象。不要把 PEL 当成 Stream 的另一份数据：Stream 保存消息，PEL 保存消费者组对“谁收到、还没确认”的跟踪。消费者退出后，记录仍会留下，因此多个 Pod 出现 PEL 不均衡并不代表写入阶段把消息复制给了每个 Pod。

比较 XAUTOCLAIM 与 XCLAIM：自动扫描还是手工指定 ID

XAUTOCLAIM 从指定 start 开始扫描 PEL，只转移 idle time 达到 min-idle-time 的消息；它自 Redis 6.2.0 提供，适合故障消费者恢复和定时巡检。命令形式如下：

XAUTOCLAIM orders order-workers recovery-1 60000 0-0 COUNT 50

COUNT 是每次尝试接管的上限，不保证一定返回 50 条，因为 Redis 会过滤未达到空闲阈值的消息。XCLAIM 则需要调用方先拿到具体消息 ID，适合人工挑选、重放某一小批记录。恢复任务通常选 XAUTOCLAIM；已由告警系统点名的单条异常，可以用 XCLAIM。

写一个可重复的 XAUTOCLAIM 循环

把上一轮返回的游标作为下一轮的 start，不要每次都从头扫。下面是可直接改造成客户端代码的命令序列：

# 第一批：从 PEL 开头接管最多 50 条，空闲至少 60 秒
XAUTOCLAIM orders order-workers recovery-1 60000 0-0 COUNT 50

# 假设返回的下一游标为 1710000000000-3，则继续扫描
XAUTOCLAIM orders order-workers recovery-1 60000 1710000000000-3 COUNT 50

# 业务处理成功后，对实际消息 ID 确认
XACK orders order-workers 1710000000000-1 1710000000000-2

完整循环要保存三个结果：下一游标、成功接管的消息、已不存在而被清理的消息 ID。游标回到 0-0 表示这次扫描到尾部，但如果恢复任务持续运行，过一段时间仍可从 0-0 再扫一轮，因为原本不够 idle 的消息可能已经达到阈值。接管只改变归属并重置 idle time，业务处理失败时不要急着 XACK。

用监控和重试上限收住接管边界

恢复任务至少要记录 PEL 总量、最大 idle time、每批接管数量、处理成功数和 XACK 失败数。普通 XAUTOCLAIM 会增加消息的 attempted deliveries；同一消息反复被接管，说明业务处理本身可能持续失败，应转入死信或人工队列，而不是无限重试。只想先盘点 ID 时，可以使用 JUSTID，它只返回消息 ID，也不会增加重试计数。

另外要注意版本边界：Redis 7.0 起，返回值会额外列出 Stream 中已经被删除或裁剪、但仍残留在 PEL 的 ID。监控中把它们作为清理事件记录即可。恢复消费者应使用独立名称，设置小批次和退避；正常流量很低时不必高频轮询，可以由 PEL 的数量或最大 idle time 触发一次接管。

决策表：

常见问题

为什么 COUNT=50 却只拿到几条？因为 COUNT 是尝试上限，扫描过程中还会排除 idle 不足的消息，实际返回少于 COUNT 是正常的。

需要一直调用 XAUTOCLAIM 吗？不需要每秒轮询。按 PEL 总量、最大 idle time 或消费者健康事件触发，使用游标分批执行，并为同一消息设置最大尝试次数。

接管后还要 XACK 吗？要。XAUTOCLAIM 只转移消费者组中的所有权；只有业务成功处理后，才用 XACK 将消息从 PEL 移除。