Redis Stream XTRIM 如何避免消费组积压无限增长

Redis Stream 用作事件队列后，最容易误判的一件事是：执行了 XTRIM，消费组的积压却没有明显下降。原因在于“流里还存多少条消息”和“消费组 PEL 里还有多少条未确认引用”不是同一个指标。XTRIM MAXLEN 负责裁剪 Stream 条目，不能替代消费者的 XACK、超时认领和失败重试。

一、先分清 Stream 长度和消费组积压

假设业务把订单事件写入 orders，支付组消费很慢。XLEN orders 返回的是 Stream 当前保存的条目数；消费组把消息读走后，消息仍可能留在流里，直到被裁剪。消息被投递但没有确认时，消费组还会在 Pending Entries List（PEL）中记录它。

因此，XTRIM 后看到的结果可能是：流长度下降了，但 PEL 仍然很大；也可能是消息已经从 Stream 中删除，PEL 中只剩悬空引用。后者并不代表消息还能被重新读取，排障时不能把 PEL 数量直接当作可恢复消息数量。

二、用三个命令定位积压到底在哪里

先执行下面的检查清单。命令输出只用于观察当前实例，不要把示例数字当成固定阈值。

# 先看 Stream 的物理条目数
XLEN orders

# 再看每个消费组的 pending、消费者和已投递位置
XINFO GROUPS orders

# 最后查看支付组的 PEL 摘要与最早、最晚 pending ID
XPENDING orders payment-group

三、普通版本先用近似 MAXLEN 控住物理长度

如果目标是控制内存和流的物理大小，可以在写入时裁剪，也可以由维护任务定期裁剪。~ 允许保留少量超出阈值的条目，通常比每次都精确裁剪更省 Redis 的工作量。

# 近似保留最近约 100000 条，适合高频写入场景
XADD orders MAXLEN ~ 100000 * order_id 1001 state paid

# 也可以由维护任务周期性执行近似裁剪
XTRIM orders MAXLEN ~ 100000

这里的 100000 是容量预算，不是“未确认消息最多只能留这么多”。在没有 ACK 的消费者故障恢复方案前，盲目把阈值调小，可能先删掉仍需重试的历史消息。生产环境应让裁剪阈值大于最长允许处理时间内的写入量，并给故障恢复留出余量。

四、Redis 8.2 起用 ACKED 保护未完成消息

Redis 8.2 起，XTRIM 增加消费组引用处理选项。需要跨多个消费组保留消息时，优先理解下面三个选择：

• KEEPREF：默认策略，裁剪 Stream 条目，但保留消费组 PEL 中已有引用；适合兼容旧行为，却可能留下悬空引用。
• DELREF：裁剪条目时一并删除所有消费组引用；适合确认这些消息不再需要重试的清理窗口，不适合故障未定位时直接使用。
• ACKED：只裁剪已经被所有消费组确认的条目；如果仍被引用的条目数量超过阈值，实际长度仍可能暂时高于目标。

# 只有所有消费组都确认的条目才参与裁剪
XTRIM orders MAXLEN ~ 100000 ACKED

# 维护任务复查各组 pending，避免把 ACKED 当成积压修复命令
XINFO GROUPS orders
XPENDING orders payment-group

ACKED解决的是“裁剪时如何看待消费组引用”，并不会替消费者完成确认。某一组长期不 ACK，消息仍可能无法按预期裁剪；这时应先查消费者存活、处理耗时、异常重试和认领逻辑。

五、上线前用保留窗口和复查指标兜底

推荐把“容量上限”和“可恢复时间”分开设定：容量上限由 MAXLEN 控制，可恢复时间由消费者处理延迟、重试次数和外部归档共同决定。上线时先用较大的阈值灰度，观察 XLEN、各组 pending 数、最老 pending ID、消息处理延迟和认领成功率，再逐步收紧。

如果发现 pending 数突然上升，先暂停激进裁剪，保留现场并确认是否存在漏 ACK。只有明确知道旧消息不再需要恢复时，才考虑 DELREF。如果使用的是 Redis 8.2 之前的版本，不要写入 ACKED，应通过消费者 ACK、XPENDING 观察和 XAUTOCLAIM 恢复流程解决积压。

相关问题

XTRIM MAXLEN 是精确限制吗？

不一定。使用 = 或省略操作符时是精确裁剪；使用 ~ 时允许略高于阈值，以换取更低的裁剪开销。

为什么 XTRIM 后 XPENDING 还显示数据？

默认 KEEPREF 会保留消费组引用，而且 pending 还可能来自消费者确实没有 ACK 的消息。先看 Stream 条目和 PEL 是否对应，再决定恢复或清理。

可以直接用 DELREF 清空积压吗？

不建议。DELREF 会删除消费组对被裁剪条目的引用，可能同时失去重试依据；只有完成业务确认并接受不可恢复时才使用。