Redis XINFO 观测消费者组积压的指标清单

观察 Redis Streams 消费者组积压，不能只盯一个数字。lag 表示尚未投递给消费者组的条目，pending 表示已经投递但还没有被 XACK 的 PEL 条目；再结合每个消费者的 pending、idle、inactive，才能判断是读取能力不足、处理变慢，还是某个消费者已经失去响应。

官方命令文档：https://redis.io/docs/latest/commands/xinfo-groups/、https://redis.io/docs/latest/commands/xinfo-consumers/、https://redis.io/docs/latest/commands/xpending/。

先把“积压”拆成两个队列

一次线上排查里，监控只展示“积压 12 万”，值班人员先扩容消费者，但吞吐没有恢复。继续查看才发现 lag 已经接近 0，真正增长的是 pending：消息早已投递，只是处理完成后没有及时确认。把两类数据混在一个总数里，会把修复方向带偏。

XINFO GROUPS 先看组级全貌

对一个 Stream 执行 XINFO GROUPS，重点采集以下字段：

• name：消费者组名称。
• consumers：组内消费者数量，不能直接等同于健康消费者数。
• pending：该组 PEL 的长度。
• last-delivered-id：最近一次投递到组的条目 ID。
• entries-read：消费者组的逻辑读取计数。
• lag：尚未投递的条目数；某些情况下会返回 NULL。

# 查看 Stream 上所有消费者组的组级指标
redis-cli XINFO GROUPS orders:stream

lag 从 Redis 7.0 起提供，它依据 Stream 的累计新增计数与组的逻辑读取计数估算。若消费者组被设置到任意中间 ID，或者 last-delivered-id 与 Stream 末尾之间发生删除、裁剪，Redis 可能暂时无法计算 lag，此时返回 NULL。监控系统必须把它记录为“未知”，不能转换成 0。

四种组合能快速缩小范围

不要把 lag + pending 简化成“总积压”后只保留一个告警。两者对应不同责任边界，也需要不同修复动作。

XINFO CONSUMERS 找出负载倾斜和失活成员

组级 pending 升高后，用消费者视图下钻。每个消费者都有独立的 pending 计数，可快速看到 PEL 是否集中在单个 owner 上。

# 下钻指定消费者组，观察每个消费者的 PEL 与活跃状态
redis-cli XINFO CONSUMERS orders:stream order-workers

Redis 7.2 调整了时间字段语义：idle 表示距离消费者最近一次“尝试交互”的毫秒数，新增的 inactive 表示距离最近一次“成功交互”的毫秒数；在 Redis 7.2 之前，idle 表示最近一次成功交互的间隔。升级采集器时如果继续按旧语义解释 idle，可能把持续空轮询的消费者误判为仍在成功处理消息。

XPENDING 补足消息年龄和投递次数

XINFO 适合看整体状态，但不会列出每条 pending 消息的空闲时长和投递次数。先使用 XPENDING 摘要获取总数、最小 ID、最大 ID以及各消费者的 pending 数，再按小批量查询详情：

# 查看 PEL 摘要：总数、ID 范围和消费者分布
redis-cli XPENDING orders:stream order-workers

# 只取前 20 条详情，避免一次拉取过多 PEL 数据
redis-cli XPENDING orders:stream order-workers - + 20

# 筛选空闲至少 60 秒的 pending 条目
redis-cli XPENDING orders:stream order-workers IDLE 60000 - + 20

扩展结果中的每条记录包含消息 ID、当前 owner、距离最近一次投递的毫秒数以及投递次数。空闲时长持续超过业务处理时限，且投递次数增加，通常比“pending 总数高”更能说明消息正在反复失败或消费者已经异常。

版本升级时需要调整哪些采集项

客户端库可能把 RESP2 返回值映射成数组、字典或专用结构体。升级前应在预发布环境确认字段缺失、NULL 和新增字段的反序列化行为，避免采集器因为固定下标而读错值。

告警不要脱离业务处理时限

没有适用于所有 Stream 的统一阈值。订单事件要求几十秒处理，与离线索引允许几十分钟积压，告警线完全不同。更可靠的组合是：

• 未投递压力：lag 连续多个采样周期增长，同时写入速率高于读取速率。
• 未确认压力：pending 增长，并出现超过业务处理时限的 PEL 条目。
• 消费者失活：inactive 超过时限，且该消费者仍持有 pending。
• 负载倾斜：单个消费者持有组内大部分 pending，其他消费者明显偏低。
• 不可观测状态：lag 为 NULL 持续过久，需要检查组游标设置、删除或裁剪行为。

迁移与回归检查清单

• 记录 Redis 服务端版本，而不是只看客户端库版本。
• 对 entries-read、lag、inactive 做字段存在性判断。
• 把 lag 的 NULL 与数值 0 分开存储和展示。
• 确认 Redis 7.2 前后 idle 的告警语义已经切换。
• 保留 XPENDING 小批量下钻入口，不在监控采集周期全量扫描 PEL。
• 用业务处理时限定义“老化 pending”，不照搬固定毫秒数。
• 演练消费者停止确认、停止读取和负载倾斜三种场景，确认告警分别指向 pending、lag 与消费者分布。

相关问题

lag 为 0 是否代表没有积压？

不一定。lag 为 0 只说明没有等待投递的条目，PEL 中仍可能存在大量已投递但未确认的 pending 消息。

pending 高就一定要增加消费者吗？

不一定。如果问题是处理逻辑失败、XACK 漏调或外部依赖变慢，增加消费者可能扩大重试压力。应先查看 pending 年龄、投递次数与 owner 分布。

XINFO 会修改消息所有权吗？

不会。本文使用的 XINFO 与 XPENDING 都是观测命令；消息重新分配需要 XCLAIM 或 XAUTOCLAIM，那属于恢复流程，应另行设计幂等与重试边界。