XPENDING 怎样找出长期未确认消息

在 Redis Streams 消费者组里，想找出“长期未确认”的消息，先不要直接扫描原始 Stream，而是查看消费者组的 Pending Entries List（PEL）。XPENDING 可以先给出 pending 总量和消费者分布，再用明细查询或 IDLE 毫秒过滤定位具体消息。

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

XPENDING key group 适合看全局概况；XPENDING key group - + count 适合看明细；再加上 IDLE min-idle-time，就能筛出至少空闲指定毫秒数的待确认消息。它负责观察，不负责自动认领或确认。

先看 pending 消息从哪里来

一条消息被消费者组通过 XREADGROUP 读到后，如果应用还没有执行 XACK，Redis 会在该组的 PEL 中记录它。PEL 记录了消息 ID 和当前消费者，所以“pending 数量变大”只说明有消息还没有确认，并不等于某个消费者一定已经宕机。

# 用 > 读取消费者组中的新消息；读到的消息会进入该组的 PEL
redis-cli XREADGROUP GROUP orders worker-a COUNT 10 STREAMS orders-stream >

# 处理成功后确认消息；确认会把对应 ID 从 PEL 中移除
redis-cli XACK orders-stream orders 1710000000000-0

# 只观察待确认集合，不改变消息的确认状态
redis-cli XPENDING orders-stream orders

这里要分清两个边界：XREADGROUP 负责把消息交给消费者，XPENDING 负责读取 PEL 的状态，XACK 负责完成确认。只有在这条关系上建立正确预期，后面的“长期未确认”筛选才不会被误读成重试命令。

用摘要判断是否需要继续下钻

最短的查询只有 key 和 group：

# 先看该消费者组的 pending 总量、最小 ID、最大 ID 和消费者分布
redis-cli XPENDING orders-stream orders

摘要返回的信息可以回答三个问题：当前有多少条待确认消息、它们覆盖的 ID 范围是什么、哪些消费者名下有 pending。总量为零时，不需要继续按 IDLE 查；总量很大或某个消费者分布异常时，再进入明细查询。

摘要只告诉你“有多少”和“由谁持有”，不会告诉你每一条消息具体空闲了多久。不要把最小 ID 当成最早未确认时间，也不要仅凭消费者名判断它已经失联；这两个结论都需要明细字段支持。

用明细读取空闲时间和投递次数

明细形式需要提供起始 ID、结束 ID 和数量。使用 - 与 + 可以覆盖当前 PEL 的 ID 范围：

# 返回最多 20 条明细：消息 ID、消费者、空闲毫秒数、投递次数
redis-cli XPENDING orders-stream orders - + 20

# 只看 worker-a 名下的前 20 条 pending，减少无关结果
redis-cli XPENDING orders-stream orders - + 20 worker-a

# 继续向后遍历时，把上一次最后读到的 ID 放在左括号后；这里排除该 ID
redis-cli XPENDING orders-stream orders \"(1710000000000-0\" + 20

每条明细通常包含四个值：消息 ID、当前消费者、距离上次投递经过的毫秒数，以及投递次数。空闲时间回答“多久没有再次投递”，投递次数回答“这条消息被交付过几次”；两者一起看，比只看 pending 数量更接近故障现场。

用 IDLE 筛出长期未确认消息

当目标是找出至少一分钟没有再次投递的消息，可以把 IDLE 放在范围参数前面。时间单位是毫秒：

# 过滤整个消费者组中空闲至少 60000 毫秒的 pending，最多返回 20 条
redis-cli XPENDING orders-stream orders IDLE 60000 - + 20

# 只筛选 worker-a 名下空闲至少一分钟的消息
redis-cli XPENDING orders-stream orders IDLE 60000 - + 20 worker-a

这个查询适合做值班排查或定时观察：先用摘要判断规模，再用一个较小的 count 分页读取。IDLE 过滤的是 PEL 中的空闲时间，不是 Stream entry 的创建时间；如果消息被重新投递，空闲时间会按 Redis 的投递记录变化。

Redis 6.2.0 起支持 IDLE 过滤和排他范围。需要遍历较大的 PEL 时，按上一次返回的最后一个 ID 使用 (last-id 作为下一页的起点，避免重复读取边界消息；每次只取固定数量，也更容易控制单次查询成本。

定位之后再决定是否恢复

XPENDING 只提供观察信息。发现某个消费者名下有很久未活跃的消息后，还要结合业务确认：消费者是否只是处理慢、消息是否允许重复处理、当前消费者是否仍可能恢复。确认需要改变消息状态时，再考虑 XACK、XCLAIM 或 XAUTOCLAIM；不要把查询结果直接当成可以认领的授权。

相关问题

XPENDING 能直接找出已经丢失的消息吗？

不能。它查看的是消费者组的 PEL，也就是已经投递但尚未确认的消息。要查 Stream 中的原始记录，还要根据消息 ID 配合其他 Stream 命令读取。

IDLE 60000 表示消息创建了一分钟吗？

不是。它表示消息在 PEL 中距离上次投递至少经过 60000 毫秒。创建时间和投递空闲时间是两个不同维度。

找到长期 pending 后是否应该马上 XACK？

不应该。XACK 会移除待确认记录，只有业务已经完成处理或明确决定放弃时才适用。需要转交给其他消费者时，应根据幂等性和恢复策略评估 XCLAIM 或 XAUTOCLAIM。

总结

排查长期未确认消息可以按三层推进：先用 XPENDING key group 看总量和消费者，再用范围明细读取消息 ID、消费者、空闲毫秒数和投递次数，最后用 IDLE 过滤出真正需要关注的条目。记住 XPENDING 只负责定位，确认和重新分配是后续动作，这样既能找到卡住的消息，也不容易因为一次查询误改变消费状态。