Redis Streams 消费者组消息堆积怎么办：从 XPENDING 到 XACK 一步步排查

Redis Streams 很适合做轻量消息队列，但消费者组用久了以后，很多人会遇到一个现象：生产端一直写入，消费者看起来也在跑，可业务延迟越来越高，甚至告警提示队列积压。

这篇文章我们不直接背命令，而是按一次真实排查走：先看 Stream 和消费者组状态，再看 Pending 列表，接着判断消息为什么没有被确认，最后用认领、重试和 XACK 把消费链路恢复正常。

问题现场：订单事件消费越来越慢

先看一个典型场景：订单服务把事件写入 Stream，异步消费者负责更新统计、发送通知、同步搜索索引。刚上线时一切正常，过一段时间后，接口没有明显报错，但异步处理延迟越来越高。

我们先画一下现场：生产者继续写消息，Stream 队列增长，其中一个消费者掉线，未确认消息停在 Pending 列表里，最后触发告警。

此时不要急着重启所有消费者。先确认到底是新消息太多，还是旧消息卡在 Pending 里没有被确认。

初步判断：是队列太长还是 Pending 太多

我们先准备一个最小示例。假设 Stream 名为 order_events，消费者组名为 order_group：

XGROUP CREATE order_events order_group $ MKSTREAM
XADD order_events * order_id 10001 event paid
XADD order_events * order_id 10002 event paid

消费者读取时一般使用 XREADGROUP：

XREADGROUP GROUP order_group consumer-a COUNT 10 BLOCK 5000 STREAMS order_events >

这里的关键点是：消费者读到消息后，并不代表消息已经完成。只有业务处理成功，并调用 XACK，这条消息才会从 Pending 列表里移除。

动手验证：用 XINFO 和 XPENDING 看清积压

接着我们先看 Stream 自身信息：

XINFO STREAM order_events

再看消费者组信息：

XINFO GROUPS order_events

如果你看到某个消费者组的 pending 数量持续上升，说明消息已经被投递给消费者，但没有被确认。进一步查看 Pending 概览：

XPENDING order_events order_group

输出里通常会看到总 Pending 数、最小消息 ID、最大消息 ID，以及消费者分布。继续查明细：

XPENDING order_events order_group - + 10

这一步我们要关注两个信号：消息闲置时间是否越来越长，Pending 是否集中在某个消费者名下。如果都符合，基本可以判断：不是生产太快，而是某个消费者拿了消息后没有确认。

定位原因：消费者掉线后消息没确认

现在我们有了第一条线索：Pending 积压集中在 consumer-a。接着要问：为什么它没有确认？常见原因有三类：

• 消费者进程退出，消息已经投递但业务没有完成。
• 业务处理失败后没有进入重试逻辑。
• 处理成功了，但代码漏掉了 XACK。

如果消费者还能启动，先检查业务日志和错误记录。如果原消费者已经不可用，就要让其他消费者认领这些闲置太久的 Pending 消息。

修复方案：认领、重试、确认

修复时不要直接删除消息。更稳的流程是：先查 Pending，确认闲置时间，再认领给新的消费者，重新执行业务逻辑，成功后 XACK。

1. 认领闲置消息

Redis 6.2 以后，可以用 XAUTOCLAIM 批量认领闲置超过阈值的消息：

XAUTOCLAIM order_events order_group consumer-recover 60000 0-0 COUNT 20

这里 60000 表示只认领闲置超过 60 秒的消息，避免刚刚被正常消费者拿到的消息被抢走。

2. 重新处理业务

认领后要重新执行业务处理。这里一定要保证业务幂等，比如订单通知不要重复发，统计写入不要重复加。常见做法是按消息 ID 或业务单号做去重记录。

3. 成功后 XACK

处理成功后再确认消息：

XACK order_events order_group 1700000000000-0

这一步非常关键。只处理业务但不 XACK，消息仍然会留在 Pending 里；只 XACK 但业务没成功，又会造成消息丢失。顺序应该是：业务成功，再确认。

验证结果：队列恢复和告警解除

最后我们重新检查消费者组状态：

XINFO GROUPS order_events
XPENDING order_events order_group

如果 Pending 数量下降，消费者延迟恢复，业务日志里没有大量重复处理，就说明这次恢复是有效的。还可以补一个简单监控：

• 消费者组 pending 数量。
• Pending 最大闲置时间。
• 每分钟 XACK 数量。
• 消费者在线数量。
• 业务处理失败次数。

容易踩坑

• 只看 Stream 长度：Stream 长度正常，不代表 Pending 没有堆积。
• 处理成功忘记 XACK：业务完成但消息仍在 Pending，后续会被重复认领。
• 重试没有幂等：认领重试可能导致重复写库、重复通知。
• 闲置阈值太短：正常慢任务可能被其他消费者抢走。
• 直接删除消息：没有确认业务状态前，不建议粗暴删除。

总结清单

Redis Streams 的消费者组并不难用，真正要注意的是“读取”和“完成”之间的状态。只要把 Pending 当作一等监控对象，消费堆积就不会变成黑盒问题。