Redis XINFO STREAM 统计首尾消息与消费组状态

排查 Redis Streams 时，我通常先看摘要，不会一上来就扫描消息。XINFO STREAM key 是只读观测入口：默认返回 Stream 长度、消费组数量、最后生成的 ID，以及首尾记录；需要进一步定位消费状态时，再加 FULL COUNT 限制返回规模。这样既能快速判断“流是空的、正在增长，还是消费组已经落后”，也不会把观测命令误当成确认或接管命令。

官方地址：https://redis.io/docs/latest/commands/xinfo-stream/

用默认摘要确认 Stream 的基本状态

先执行最小查询，重点看四组信息：当前长度、消费组数量、最近生成的 ID、首尾记录。示例中的命令只是调用示意，不代表已在本文环境执行。

# 只读查看 Stream 摘要，适合先判断数据是否存在
redis-cli XINFO STREAM orders

# 只读取消费组摘要，并限制每组返回的明细数量
redis-cli XINFO STREAM orders FULL COUNT 10

如果 length 为 0，不能直接推断 key 一定不存在：Stream 允许保留为空的结构，尤其当它关联过消费组时，应该结合 key 存在性和 groups 一起判断。若 first-entry、last-entry 有值，它们展示的是当前 Stream 中仍保留的边界记录。

区分消息数量、生成计数与首尾记录

生产排查最容易混淆的是三个数字。length 表示当前仍在 Stream 中的记录数；entries-added 记录生命周期内通过 XADD 加入过的总量，即使旧消息后来被裁剪，也不会随当前长度一起减少；last-generated-id 是最近生成的 ID，用于判断写入侧是否仍在推进。

例如 entries-added 很大而 length 较小，可能只是保留策略生效；如果 last-generated-id 长时间不变，才值得继续检查生产端是否停止写入。不要仅凭首尾 ID 判断某个消费者已经处理到哪里，消费进度要看消费组信息。

用 FULL COUNT 观察消费组和待处理摘要

FULL 会把消费组、PEL 和消费者明细纳入返回结果。对每个消费组，常用字段是 last-delivered-id、entries-read、lag 和 pel-count；消费者层面再看名称、空闲时间和待处理数量。COUNT 只限制 FULL 返回的 Stream/PEL 明细数量，不能把它当成“只统计前 N 条消息”的过滤器。

# 控制 FULL 结果规模，先取少量明细判断是否存在异常消费者
redis-cli XINFO STREAM orders FULL COUNT 10

# 生产巡检不要默认拉取全部明细；COUNT 0 可能带来很大的返回量
# 只有在流规模可控且确实需要完整 PEL 时再使用 COUNT 0

lag 表示仍等待该消费组投递的逻辑数量，在某些游标关系无法计算时可能为空；pel-count 则是已投递但尚未确认的记录数。两者同时偏高，通常说明“未投递”和“已投递未确认”都需要分开处理，而不是只增加消费者数量。

按只读观测边界形成检查清单

我会按下面的顺序记录一次巡检：先记 length 和 last-generated-id，确认流是否在增长；再看 groups 与首尾记录，判断结构和保留边界；最后只在需要时使用 FULL COUNT 10，比较各组的 lag、pel-count 和消费者状态。

这条命令不会接管超时消息，也不会确认消息、删除记录或裁剪历史。需要恢复消费者时看 XAUTOCLAIM/XCLAIM，需要改变 PEL 或消息确认状态时看 XACK 相关命令，需要按长度或 ID 控制保留量时再看 XTRIM。把这些动作和 XINFO 的只读观测分开，排查记录才不会出现“看到了积压就误删或误确认”的操作风险。

常见问题

XINFO STREAM 能直接看出哪个消费者最慢吗？

可以提供消费者级的空闲和待处理摘要，但“最慢”仍要结合采样时间、处理耗时和业务吞吐判断，不能只看一个字段。

为什么 length 和 entries-added 差很多？

前者是当前保留量，后者是生命周期累计加入量。裁剪、删除或流长期运行都会让两者自然拉开。

FULL COUNT 0 是否最准确？

它会请求完整明细，但准确不等于适合生产巡检。大流或大 PEL 应优先用小 COUNT 取摘要，必要时再分批深入。