Redis Streams 怎样判断队列是否有积压

Redis Streams 里看到消息越来越多，并不能直接说明消费队列已经积压。XLEN 只告诉你 Stream 里当前保留了多少条记录；真正排查消费组，要先用 XPENDING stream group 看“已经投递但还没有 XACK”的消息，再用 XINFO GROUPS 看尚未投递给消费组的 lag。这两个数字一起看，才能判断是处理慢、确认丢失，还是生产速度超过了消费速度。

判断 Redis Streams 积压的最小组合是：XPENDING 看未确认消息，XINFO GROUPS 看 pending 与 lag，XINFO CONSUMERS 再定位到具体消费者。

先分清 XLEN、pending 和 lag

Redis Streams 的消息通常通过 XREADGROUP 交给消费组。消息交付后，Redis 会把它放进该消费组的 Pending Entries List（PEL）；业务处理成功后调用 XACK，这条引用才会从 PEL 移除。因此，pending 反映的是“已经有人领走，但还没有确认”的状态。

lag 描述另一件事：消费组的逻辑读取位置后面，还有多少条消息没有交付给组内消费者。一个组可能 pending 很大但 lag 很小，说明消费者拿到了消息却迟迟不确认；也可能 pending 接近零但 lag 持续变大，说明消费者没有及时领取新消息。XLEN 则包括保留在 Stream 中的历史记录，设置了裁剪策略时更不能把它当作实时积压。

XPENDING 先看消费组已经卡住多少条

最短的检查命令只需要 Stream 名和消费组名：

# 查看消费组级别的 PEL 摘要：总数、最小 ID、最大 ID、各消费者数量
redis-cli XPENDING orders worker-group

# 按消息列出前 20 条 pending，便于看到消费者、空闲时间和投递次数
redis-cli XPENDING orders worker-group - + 20

摘要返回四部分信息：pending 总数、最早 pending ID、最晚 pending ID，以及每个 consumer 持有的数量。明细查询还会给出消息 ID、消费者名称、idle 毫秒数和 delivery count。某个消费者的 idle 长时间增长，通常比“总数变大”更能说明它已经停止处理或处理链路被卡住。

用 XINFO GROUPS 区分未确认和未投递

要判断生产者是否已经跑在消费者前面，再执行：

# 查看每个消费组的 pending、last-delivered-id、entries-read 和 lag
redis-cli XINFO GROUPS orders

# 进一步按消费者查看空闲时间和各自持有的 pending 数
redis-cli XINFO CONSUMERS orders worker-group

重点关注同一个消费组里的两个字段：pending 表示 PEL 中还未确认的条目，lag 表示仍未交付给该组的条目。两者都增长时，既有确认链路问题，又有消费能力不足的可能；只有 lag 增长时，优先看消费者数量、阻塞读取和单条处理耗时；只有 pending 增长时，优先看异常退出、幂等处理与确认时机。

lag 不是任何场景下都可用的精确计数。Redis 文档说明，消费组从任意中间 ID 创建或设置，或者组游标之间的记录已被 XDEL / 裁剪删除时，lag 可能返回 NULL。这时应把它当作“暂时不可计算”，继续用 XPENDING 明细、消费者 idle 和业务处理指标判断，不要把 NULL 当成零。

从数字回到故障根因

线上复盘可以按这个顺序收敛：先记录 XPENDING 摘要，确认是否有未确认消息；再用范围查询找出 idle 最大或 delivery count 异常的条目；然后用 XINFO CONSUMERS 看是否只有某一个 consumer 持有大量 PEL。若 pending 很大而 lag 较小，先修复消费者崩溃、超时和漏掉 XACK 的分支；若 lag 持续变大而 pending 较小，再检查生产速率、单条处理耗时和消费组并发度。

确认消息确实由失联消费者留下后，才考虑按业务幂等规则使用 XAUTOCLAIM 或 XCLAIM 转移所有权。领取并不等于处理成功，成功处理后仍要 XACK；对于不能重复执行的业务，还要把消息 ID 或业务键纳入幂等控制。

常见问题

XLEN 很大，是否一定代表队列积压？

不一定。XLEN 是 Stream 当前保留长度，可能包含已经处理过的历史消息；消费组积压应看 pending 和 lag。

XPENDING 为零，为什么仍然感觉消息没处理完？

可能是消息尚未交付给消费组，此时检查 XINFO GROUPS 的 lag；也可能使用的是不经过消费组状态的 XREAD，需要确认读取模型。

lag 返回 NULL 应该怎么处理？

先确认消费组起始 ID 和 Stream 是否发生过裁剪，再用 XPENDING 明细、消费者 idle、业务耗时和生产速率交叉判断，不把 NULL 当作零。

排查 Redis Streams 时，数字的含义比数字大小更重要：pending 是“领了未确认”，lag 是“还没交付”，XLEN 是“还保留多少”。把三者分开记录，才能决定是修确认、恢复消费者，还是增加消费能力。