Redis XINFO CONSUMERS 的 idle 与 inactive 字段区分指南

排查 Redis Stream 消费者时，最容易误读的是 idle：它不是简单的“多久没成功处理消息”。在 Redis 7.2 及以后，idle 表示距上次尝试交互的时间，inactive 才表示距上次成功交互的时间。把它们和 pending 放在一起看，才能判断消费者是真的停住，还是只是暂时没有新消息。

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

先读懂 XINFO CONSUMERS 的三个时间与积压字段

XINFO CONSUMERS key group 返回指定 Stream 消费组里的消费者列表。每个消费者至少要看四个属性：name 是名称，pending 是它在 PEL 中待确认的条目数，idle 和 inactive 都是毫秒计时。

Redis 7.2 前，idle 的语义更接近现在的 inactive。因此跨版本看监控时，不能直接把旧面板中的 idle 阈值原样套到新版本。图1把字段和版本语义画成静态关系，便于记住这个边界。

用一条命令读取消费者级状态

查询时必须同时给出 Stream 键和消费组名称。下面的命令只做观测，不会确认、删除或转移消息：

# 查看指定 Stream 消费组的消费者级状态
redis-cli XINFO CONSUMERS mystream worker-group

返回内容通常按消费者分组，包含 name、pending、idle 和 inactive。如果看到 NOGROUP，先检查消费组名；如果是 WRONGTYPE，说明 key 并不是 Stream。刚创建的组也不一定立刻出现消费者，消费者通常要在首次以某个名字调用 XREADGROUP 后才被记录。

这条命令的价值在于把整个消费组拆成消费者粒度。例如两个实例都属于同一组，但一个 pending=0，另一个 pending=120，此时不应只看组级“有积压”，而要继续追查具体实例。

按 idle、inactive、pending 组合排障

推荐先按下面的组合判断，避免只凭一个时间字段触发接管：

• pending=0，idle 和 inactive 都较大：更像是当前没有分配到新消息，或者消费者已经停止轮询；先看应用是否仍在运行和是否有新消息，不要直接认定消息丢失。
• pending 持续增加，inactive 也持续增加：说明历史上成功读到过消息，但确认或业务处理没有跟上，应检查异常、ACK 路径和处理耗时。
• idle 很小而 inactive 很大：消费者还在尝试交互，但可能反复读不到新消息；这个组合不能单独证明消费者故障。
• pending 较大且 idle 长时间不变：才值得进入超时消息排查，先用 XPENDING 查看具体消息的空闲时间，再决定是否用 XAUTOCLAIM。

XINFO CONSUMERS 是消费者级观测接口，不会替你完成恢复。图2展示它与消息级检查及接管工具的静态关系；恢复动作仍然要结合业务幂等、重试次数和确认策略设计。

常见问题

idle 和 inactive 应该监控哪一个？

两者一起保留。idle 反映最近一次尝试交互，inactive 反映最近一次成功交互；如果只看 inactive，可能错过消费者正在频繁轮询但始终没有读到消息的情况。

pending 为 0，是否说明消费者健康？

不能。它只说明该消费者当前没有待确认条目，还需要结合进程存活、轮询行为和 Stream 是否有新消息判断。

看到 idle 很大要立即执行 XAUTOCLAIM 吗？

不要直接执行。先确认 pending 是否存在，再用 XPENDING 获得消息级证据；没有待确认消息时，AUTOCLAIM 没有可接管的对象。