Redis Streams Pending 列表积压怎样处理

Redis Streams 的 Pending 列表积压，通常不是 Stream 本身停止写入，而是消费者组已经把消息投递给某个消费者，却迟迟没有执行 XACK。处理这类问题要先看清消息属于谁、空闲了多久，再决定是让原消费者继续处理，还是交给健康消费者认领。不要直接删除 Pending 项，也不要把“重新读取”当成确认。

官方文档：https://redis.io/docs/latest/commands/xpending/

• 先查总量：XPENDING stream group 能快速看到 Pending 数量、最小和最大消息 ID，以及消费者范围。
• 再查明细：按消费者或 IDLE 过滤，找出真正长时间没有进展的消息。
• 最后收口：用 XAUTOCLAIM 认领超过阈值的消息，业务处理成功后再执行 XACK。

Pending 积压到底说明了什么

消费者组通过 XREADGROUP 读取消息时，Redis 会把已经交付但还没有确认的消息放进 Pending Entries List，也就是常说的 PEL。它记录的是“投递关系”和空闲时间，不等于消息已经丢失，也不等于所有积压都应该立刻转移。

最常见的原因有三类：消费者处理时间本来就长；消费者进程已经退出，但消息仍归属于旧消费者；业务处理完成了，却因为异常路径、超时或漏写确认而没有执行 XACK。因此第一步不是扩大消费者数量，而是先确认 Pending 是否持续增长，以及最老消息的空闲时间是否超过业务允许的处理窗口。

# 查看消费者组的 Pending 摘要；key、group 要替换成实际名称
redis-cli XPENDING orders:stream order-workers

# 查看消费者组的基本状态，确认读取游标和活跃消费者
redis-cli XINFO GROUPS orders:stream

# 查看消费者明细，结合 idle 和 pending 判断是否有失联实例
redis-cli XINFO CONSUMERS orders:stream order-workers

XPENDING 怎样查到真正卡住的消息

摘要只能告诉你数量和 ID 范围，定位时需要使用扩展形式：指定起止 ID、返回数量，并按消费者过滤。Redis 文档还支持 IDLE 条件，它适合把排查范围收窄到“已经空闲足够久”的消息。

# 先取最早的一小批明细，避免一次扫描过大的范围
redis-cli XPENDING orders:stream order-workers - + 20

# 只看某个消费者名下的消息，判断它是否还在推进处理
redis-cli XPENDING orders:stream order-workers - + 20 worker-a

# 只筛选空闲超过 60000 毫秒的消息；阈值要高于正常处理时长
redis-cli XPENDING orders:stream order-workers IDLE 60000 - + 20

判断时可以把结果分成两种。若 Pending 数量不大、空闲时间持续刷新，说明消息可能只是处理较慢，应先优化处理耗时或调整告警阈值。若某个消费者长期保有大量高空闲消息，而其他消费者仍然健康，才适合进入认领路径。对于同一业务键可能重复执行的场景，还要先确认下游写入具有幂等键或去重机制。

怎样认领超时消息而不制造重复副作用

Redis 6.2 及之后可以优先考虑 XAUTOCLAIM。它按最小空闲时间扫描 Pending，并把符合条件的消息转给指定消费者；返回结果中带有下一次扫描所需的游标。认领只改变消费者归属，不代表业务已经成功，所以接手后仍要读取消息内容、执行业务处理并在成功后确认。

# 从游标 0-0 开始认领空闲超过 60000 毫秒的消息，每次最多 20 条
# worker-recovery 是健康消费者名称；游标需要保存到下一轮扫描
redis-cli XAUTOCLAIM orders:stream order-workers worker-recovery 60000 0-0 COUNT 20

# 兼容需要明确消息 ID 的场景，按 ID 认领单条消息
# 只对已确认失联且具备幂等处理的消息使用
redis-cli XCLAIM orders:stream order-workers worker-recovery 60000 1690000000000-0

认领策略不要只按消息数量设置。最小空闲时间应覆盖正常处理的长尾耗时，并留出网络抖动和短暂重试空间；太短会让仍在工作的消费者被频繁抢走，太长又会延迟故障恢复。批量认领后应继续使用返回游标，直到本轮没有符合条件的消息，再根据监控结果决定下一轮间隔。

处理完成后怎样让积压真正回落

业务成功才执行 XACK。如果处理过程中发生可重试错误，可以暂时不确认，让消息继续留在 Pending；如果已经达到重试上限，则应把失败原因写入独立的补偿或死信路径，再确认原消息，避免一个坏消息永久占住恢复队列。无论选择哪种路径，都要让业务写入具备幂等性，因为消费者崩溃可能发生在业务副作用完成之后、XACK 之前。

# 业务处理成功后确认对应消息；多个 ID 可以一起确认
redis-cli XACK orders:stream order-workers 1690000000000-0

# 处理失败时先记录补偿信息，再决定是否确认原消息
# 不要把 XACK 当成“尝试过了”，它表示该消息已从 Pending 处理中移除
redis-cli XACK orders:stream order-workers 1690000000000-0

日常观察至少保留四个指标：Pending 总量、最老消息的空闲时间、各消费者的 Pending 分布，以及认领后成功确认的数量。总量下降但最老空闲时间仍持续上升，说明只是清掉了新消息，老消息问题还没有解决；总量不高但某个消费者长期不活跃，也应保留消费者故障排查。

常见问题

Pending 数量大就一定是消费者故障吗？

不一定。长事务、批量处理或下游接口变慢都会让正常消息暂时停留在 Pending。要结合 IDLE、消费者活跃状态和处理耗时判断。

XAUTOCLAIM 后还需要 XACK 吗？

需要。XAUTOCLAIM 只负责认领消息，成功处理后仍需 XACK；否则消息会继续留在新的消费者名下，并再次出现在 Pending 检查结果中。

能不能直接删除 Stream 重新开始？

不建议。删除 Stream 会同时破坏尚未处理的数据和消费者组上下文。除非已经有明确的数据补偿与重建方案，否则应先按消息 ID、空闲时间和业务幂等策略逐步恢复。

小结

Redis Streams Pending 积压的处理顺序可以固定为“摘要确认范围、明细判断空闲、认领失联消息、成功后确认、持续观察指标”。XPENDING 负责定位，XAUTOCLAIM 或 XCLAIM 负责转移，XACK 负责最终收口，而幂等设计负责承受认领和故障交接可能带来的重复投递。