Redis consumer group 怎样查看待处理消息数量

查看 Redis consumer group 已投递但尚未确认的消息数量，使用 XPENDING 流键 消费者组名，读取摘要的第一个元素。如果你说的“待处理”是尚未投递给该组的消息，则应另外查看 XINFO GROUPS 中的 lag；pending 和 lag 不是同一个指标。

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

问题：待处理到底指未投递还是未确认

假设任务流为 demo:jobs:thumbs，消费者组为 renderers，两个工作进程使用 worker-east 和 worker-west。这些名称是本文原创示例。运维看到“任务没做完”，首先要确定问题出在领取之前，还是领取之后没有确认。

PEL 是该组的待确认条目列表，记录已投递但还没确认的消息状态。lag 则描述仍等待投递的数量，可用时才有具体数值。流中还可能保留已确认消息，因此 XLEN 也不能直接当作该组待处理数。

最小配方：用 XPENDING 摘要取得总数

已知流和组存在时，在有权限的连接上执行下面的 shell 示例。命令未在本文环境中运行；默认 redis-cli 连接本地实例，远程环境应按自己的连接配置使用。

# 只读查询组级摘要，第一个元素是该组 PEL 条目总数
redis-cli XPENDING demo:jobs:thumbs renderers

摘要同时提供待确认 ID 范围和有待确认消息的消费者分布。读总量时不要数消费者个数，也不要拿最大、最小 ID 相减：Stream ID 不是连续任务序号。

若总数为 0，只能得出“这次查询没有待确认条目”。它不能证明流为空、尚未投递消息为零，或所有外部业务动作都成功。消息确认状态与图片是否真正生成、文件是否成功保存，还需要应用自身状态来表达。

关键字段：不要用明细行数代替总量

# 查询最多 12 条待确认明细；12 是返回上限，不是组级总数
redis-cli XPENDING demo:jobs:thumbs renderers - + 12

明细适合观察消息 ID、当前归属消费者、投递空闲毫秒数和投递次数。摘要与明细是两种返回结构，客户端解析代码应分开处理。拿到 12 行只代表这次最多返回 12 条，无法断言总量也是 12。

查询变体：按消费者和空闲时间缩小范围

# 查看各消费者的 pending，避免遍历其全部消息来计数
redis-cli XINFO CONSUMERS demo:jobs:thumbs renderers

# 限定 worker-east，只取最多 12 条供排查使用
redis-cli XPENDING demo:jobs:thumbs renderers - + 12 worker-east

# Redis 6.2 起支持 IDLE；60000 的单位为毫秒
redis-cli XPENDING demo:jobs:thumbs renderers IDLE 60000 - + 12

最后一条命令用于抽取空闲至少约一分钟的条目，并不返回“所有超时消息的总数”。空闲时间和投递次数可以提示排查方向，但不能直接证明消费者崩溃或业务失败。长任务、确认延迟以及重投递也会影响这些数值。

如果需要进一步取多页，受支持的版本可用上一页最后 ID 的开区间继续查询；同时要接受查询期间数据变化。这里的任务只是观察数量，不应为了得到一个总数反复扫描全部 PEL，更不应为了“清零”就发确认命令。

消费者信息官方地址：https://redis.io/docs/latest/commands/xinfo-consumers/。

兼容与误判：空值、错误和采样时刻

lag 缺失或为空时保留未知状态。该字段从 Redis 7.0 起加入 XINFO GROUPS。服务端在无法确定 lag 时可返回空值；客户端遇到缺失字段或空值，不应默认为 0。官方说明：https://redis.io/docs/latest/commands/xinfo-groups/。

查询失败要单独记录。组不存在、键类型错误、权限不足或网络超时，都不是“零待处理”。监控应把数据值、查询是否成功、采样时间分别存储，避免错误发生时面板突然归零而看起来恢复正常。

多次只读查询不是同一快照。生产者和消费者持续工作时，先读摘要再读消费者分布，其间可能发生投递、确认和归属变化。两个时刻的数值不完全一致，不足以判定数据损坏。对于需要严格对账的业务，使用业务记录与明确的取样方案。

在版本支持、lag 已知且统计口径一致的前提下，可以将 pending 与 lag 分列展示，以便判断“已领取未确认”和“未领取”分别积压多少。不要把它们笼统命名为失败任务数，更不要在 lag 未知时强行求和。

完整片段：保存一次只读排查记录

下面的片段把组概况、消费者分布、摘要及少量明细放在一份记录中，适合人工排查。它没有修改消息状态；每个命令的回复需要按各自结构解释，文本记录不适合用行数做自动计数。

#!/usr/bin/env bash
# 使用独立演示名称；按部署环境为 redis-cli 配置连接
stream_key='demo:jobs:thumbs'
group_name='renderers'

# 给各段加标签，保留错误信息，避免把查询失败当作空列表
{
  printf '%s\n' '--- group overview ---'
  redis-cli XINFO GROUPS "$stream_key"
  printf '%s\n' '--- consumer distribution ---'
  redis-cli XINFO CONSUMERS "$stream_key" "$group_name"
  printf '%s\n' '--- pending summary ---'
  redis-cli XPENDING "$stream_key" "$group_name"
  printf '%s\n' '--- pending sample, at most 12 ---'
  redis-cli XPENDING "$stream_key" "$group_name" - + 12
} > pending-observation.txt 2>&1
# 这是逐条采样记录，不是业务完成证明或一致性快照

pending 很大，要立即增加消费者吗？

先观察消费者分布和任务耗时。未确认消息已经有其处理状态，单纯增加只读取新消息的实例，不会自动接手所有旧条目；恢复策略需单独设计。

XPENDING 会把消息重新投递吗？

它用于查看状态。不要把查询与领取、转移归属或确认混用。

摘要为 0，为什么还有任务排队？

可能排在未投递范围，也可能任务已经被确认而外部业务仍未完成。先分清消息状态与业务状态，再选择对应数据源。