当前位置：首页 > 文章列表 > 数据库 > Redis > Redis Streams 怎样判断队列是否有积压

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

来源：17golang原创 2026-10-26 01:44:21 0浏览收藏

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

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

要点速览

pending 是消费组 PEL 中已投递、未确认的消息数。
lag 是仍等待投递的消息数，和 pending 不是同一类积压。
XLEN 受保留策略影响，只能说明 Stream 长度，不能单独作为告警依据。

先分清 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 长时间增长，通常比“总数变大”更能说明它已经停止处理或处理链路被卡住。

观察值	它说明什么	下一步
pending 持续增长	消息已交付但没有及时确认	检查业务异常、XACK 路径和消费者存活
idle 很大、投递次数反复增加	消息可能被重复领取或消费者失联	结合 XAUTOCLAIM 的空闲阈值处理
pending 为 0	当前没有未确认消息	仍需检查 lag，不能据此证明没有新消息等待

Redis Streams XPENDING 将 Stream、XREADGROUP、消费组、PEL 与消费者观测连接起来的静态结构说明图 — 图1：XPENDING 观察已投递未确认消息的结构说明图，不是运行截图或实测证据。

用 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 当成零。

Redis Streams XINFO GROUPS 对照 entries-added、entries-read、pending 与 lag 的静态关系图 — 图2：XINFO GROUPS 对照 pending 与 lag 的静态关系说明图，不是运行截图或性能报告。

从数字回到故障根因

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

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