Redis XINFO GROUPS 怎样查看消费者组消费进度

Redis Stream 消费组的消费进度，建议先执行 XINFO GROUPS 。它返回每个消费组的名称、消费者数量、pending、last-delivered-id、entries-read 和 lag，可以把“已经投递但没确认”和“还没有投递”分开看。

官方文档：https://redis.io/docs/latest/commands/xinfo-groups/

最关键的判断是：pending 反映消费组 PEL 中已投递、尚未确认的消息；lag 反映按逻辑读取计数推算出的、仍等待投递的消息。两者都变大时，可能既有处理变慢，也有新消息进入。

准备 Stream 与消费组查询入口

XINFO GROUPS 是只读查询，参数只有 Stream 的 key。为了让查询能显示有意义的状态，可以先准备一个小型 Stream 和消费组；这些命令是示例写法，文章配图是静态说明图，不代表已在某个线上实例执行。

# 写入三条示例消息，field-value 要成对出现
redis-cli XADD orders * order_id 1001 status created
redis-cli XADD orders * order_id 1002 status paid
redis-cli XADD orders * order_id 1003 status shipped

# 从现有消息起点创建消费组；实际项目按业务选择 0-0 或 $
redis-cli XGROUP CREATE orders order-workers 0-0

# 让一个消费者领取两条消息，形成可观察的消费组状态
redis-cli XREADGROUP GROUP order-workers worker-a COUNT 2 STREAMS orders >

# 查看 orders 上所有消费组的进度字段
redis-cli XINFO GROUPS orders

按字段判断消费组处于什么位置

输出通常是一组字段和值。不要只盯着一个数字，而要把它们组合起来判断：

• name 是消费组名称；同一个 Stream 可以有多个组。
• consumers 是组内已登记消费者的数量，不等于当前正在处理的消息数。
• pending 是 PEL 长度，表示已经投递给消费者但尚未确认的消息数。
• last-delivered-id 是最后投递给组内消费者的消息 ID，用来观察组的投递位置。
• entries-read 是逻辑读取计数，用来计算 lag，不应当当成永远精确的已处理条数。

例如，某组的 pending=8、lag=0，表示新消息基本已经投递到消费者，但还有 8 条业务处理后未确认；反过来，pending=0、lag=20，更像是消费者没有继续领取新消息，而不是确认路径积压。

# 查询指定 Stream 的消费组；输出中的字段名比数组下标更适合巡检
redis-cli XINFO GROUPS orders

# 需要查看具体消费者的 pending、idle 等信息时再查询消费者级数据
# 这一条只用于定位组内成员，不替代组级的 lag 判断
redis-cli XINFO CONSUMERS orders order-workers

用 lag 判断尚未投递的消息

lag 可以理解为 Stream 的累计新增计数与消费组逻辑读取计数之间的差值，表示仍等待投递给该组消费者的条目数量。它更适合回答“这个消费组有没有追上 Stream 的新增速度”，而不是回答“业务处理是否成功”。

因此排查时可以按下面的组合看：

处理 lag 为 NULL 的情况

lag 不是任何时候都能算出数字。如果消费组用任意的最后投递 ID 创建或通过 XGROUP SETID 设置，或者组当前位置与 Stream 之间的条目已经被 XDEL、XTRIM 等操作删除，Redis 可能返回 NULL。这并不等于 Stream 没有消息，也不等于消费者已经停止。

这时先看 last-delivered-id、pending 和 XINFO STREAM 的首尾 ID，再确认是否有裁剪策略。随着消费组继续处理并重新建立可用的逻辑读取计数，lag 可能恢复；在恢复前不要把 NULL 强行当作 0 做自动扩容或自动缩容依据。

# 先看组级字段，保留 NULL 的原始语义
redis-cli XINFO GROUPS orders

# 再看 Stream 的新增计数、首尾 ID 和组数量
# 两条命令的结果一起使用，避免只用一个字段做扩缩容决策
redis-cli XINFO STREAM orders

把查询接入日常巡检

可以周期性保存 name、consumers、pending、last-delivered-id、entries-read 和 lag，按组比较趋势。扩容判断优先看 lag 是否持续上升；处理链路判断优先看 pending 是否持续上升；出现 NULL 时记录状态而不是替换成 0。

最后要记住三个边界：XINFO GROUPS 只提供观测，不会替你确认消息；pending 不是 Stream 剩余长度；lag 是基于逻辑读取计数的指标，受任意起点和裁剪影响。若需要定位某条待确认消息，再使用 XPENDING；若需要接管空闲消息，再单独评估 XAUTOCLAIM。

相关问题

为什么 pending 为 0 但 lag 仍然很大？ 这通常表示消息尚未投递到该组消费者，而不是确认已经失败，应先检查消费循环是否持续使用 XREADGROUP 读取新消息。

entries-read 是已经成功处理的数量吗？ 不是。它是用于推算 lag 的逻辑读取计数，不能替代业务成功数、确认数或数据库提交数。

lag 为 NULL 可以直接按 0 处理吗？ 不建议。NULL 表示当前无法可靠计算，应结合组起点、Stream 裁剪和后续消费趋势再做判断。