Redis Stream 裁剪时 KEEPREF 和 ACKED 怎么选

Redis Stream 做多消费组时，KEEPREF 和 ACKED 不是“精确裁剪”和“模糊裁剪”的区别，而是“是否顾及消费组引用”的区别。希望无论消费组处理到哪，都按 MAXLEN 或 MINID 清理旧条目，用 KEEPREF；希望只有所有消费组都确认过的条目才允许删除，用 ACKED。两者都不能替代慢消费者治理。

多组协作且不能删掉仍被任一组处理中的消息时，优先用 XTRIM ... ACKED；只是控制 Stream 物理长度、能接受 PEL 中暂时保留已删除条目的引用时，使用默认的 KEEPREF。

KEEPREF 到底保留了什么

消费组读取消息后，Redis 会在该组的 Pending Entries List（PEL）里记录条目 ID；处理成功后由 XACK 移除该组的待处理引用。一个 Stream 可以同时服务多个消费组，同一条消息在不同组里有各自的确认状态。

使用 KEEPREF 时，Stream 本体会按照裁剪策略移除旧条目，但已经存在于各组 PEL 的引用仍被保留。这是兼容性优先的默认行为：应用仍能通过待处理 ID 观察、重试或转移责任，只是重新读取该条目的完整字段可能已经做不到。

因此，KEEPREF 适合把 Stream 当作有限长度日志、把失败重试交给业务补偿的场景。它不等于“消息仍然完整可读”，也不等于“PEL 会自动清空”。如果业务要求条目被删除后连引用也不留，应评估 DELREF，但这会放弃对这些待处理引用的跟踪。

MAXLEN 和 ACKED 怎么组合

ACKED 把“是否可以裁剪”再加上一层条件：条目必须已经被所有消费组确认。只要有一个组仍把它留在 PEL 中，条目就不会因为这个选项被删除。它特别适合多个下游都必须看到同一事件的场景。

# 按数量保留最近一批，并跳过仍未被所有消费组确认的条目
XTRIM order-events MAXLEN ~ 100000 ACKED

# 按 Stream ID 设置时间边界；ACKED 仍要求所有消费组完成确认
XTRIM order-events MINID ~ 1710000000000-0 ACKED

这里的 ~ 是近似裁剪，通常更适合降低频繁精确整理的成本；如果必须尽量贴近阈值，可以去掉它采用精确裁剪。无论是否近似，ACKED 都不是“强制把长度变成 100000”的开关：如果未确认条目本身超过阈值，裁剪会受这些引用限制。

慢消费组为什么会让 ACKED 不动

假设消费组 A 已经对旧消息执行 XACK，消费组 B 仍在重试或长期离线，那么该消息对 B 来说仍是 pending。此时使用 ACKED，Redis 会把它视为不能安全删除的条目。Stream 变长不是命令失效，而是“全组确认”这个条件没有成立。

上线前可以用下面的检查动作定位阻塞组：

# 查看某个消费组的待确认数量、最小 ID 和最大 ID
XPENDING order-events billing-workers

# 查看 Stream 与各消费组的 last-delivered-id、pending 等状态
XINFO GROUPS order-events

如果某组的 PEL 长期增长，先处理消费者恢复、XAUTOCLAIM 或失败消息转移，再决定是否调整裁剪阈值。不要为了让长度下降直接切到 KEEPREF，否则可能留下无法取回正文的引用；也不要把 ACKED 当成故障恢复方案。

生产环境的选择清单

还要确认 Redis 版本支持这些引用策略：官方命令文档标注它们自 Redis 8.2 起可用于 XTRIM。跨版本部署时，不要只在客户端代码里拼接参数，应该在目标实例上核对命令能力并做一次小流量演练。

相关问题

KEEPREF 是不是会保留消息正文？

不是。它保留的是消费组 PEL 中的引用；Stream 条目本体仍可能已被裁剪，不能据此保证还能通过 XRANGE 读到字段。

ACKED 能保证 Stream 永远不超过 MAXLEN 吗？

不能。未被所有消费组确认的旧条目会阻止裁剪，因此实际长度可能超过阈值。

只有一个消费组时该怎么选？

若只关心长度并已有 pending 恢复机制，KEEPREF 更接近传统行为；若必须等该组确认后再删除，ACKED 更直观，但仍要监控 PEL。

参数细节可继续查阅 Redis XTRIM 官方文档 与 Redis Streams 官方说明。