Redis Stream 怎样按 ID 截断而不误删新消息

如果 Redis Stream 的保留规则是“从某个消息 ID 开始保留”，不要把长度裁剪和 ID 裁剪混在一起。最小可用写法是 XTRIM stream-key MINID = first-id-to-keep：小于这个 ID 的条目会被裁掉，阈值本身以及更大的 ID 仍然保留。

本文只解决按 ID 截断的边界问题。官方命令说明中，MINID 从 Redis 6.2.0 开始可用；= 是精确裁剪，~ 是近似裁剪。官方地址：https://redis.io/docs/latest/commands/xtrim/

先把 Stream ID 边界想清楚

Stream ID 通常由“毫秒时间戳-序号”组成，例如 1712669055705-0。按 ID 清理时，最重要的判断不是“删除到哪一条”，而是“哪一条是第一条必须保留的消息”。把这个第一条消息的完整 ID 作为 MINID 阈值，规则就很清晰：

• ID 小于阈值：属于旧窗口，可以被裁剪。
• ID 等于阈值：属于保留窗口，不会被 MINID 裁掉。
• ID 大于阈值：属于更新消息，继续保留。

因此，标题中的“不误删新消息”对应一个具体动作：阈值取“第一条要保留的完整 ID”，而不是取“最后一条要删除的 ID”。同一毫秒内可能有多个序号，只写毫秒值会把边界表达得不完整，生产配置应保留完整的时间戳和序号。

用 XTRIM MINID 写出精确保留窗口

假设消费窗口从 1712669055705-0 开始，先用精确模式按 ID 裁剪：

# 以第一条必须保留的 Stream ID 作为 MINID 阈值
XTRIM orders MINID = 1712669055705-0

# 返回值是本次从 orders 中实际删除的条目数量

= 可以省略，因为它是默认行为；显式写出来更容易让脚本审查者看出这是严格边界。精确裁剪的含义是：Stream 中最早的 ID 不会早于给定阈值，除非原本最早的消息已经比阈值更新。

如果业务上要保留的是某条消息之后的内容，就不要直接把那条“最后删除”的 ID 传进去。应先确定下一条要保留的完整 ID，再把下一条 ID 作为阈值。这样可以避免把边界消息一并删除，也避免在同一毫秒的序号变化下误判。

精确与近似怎样选择

高频写入时，严格裁剪会让 Redis 做更多删除工作。如果允许旧条目暂时多留一些，可以使用 ~：

# 允许保留少量低于阈值的旧条目，以减少裁剪开销
XTRIM orders MINID ~ 1712669055705-0

# 限制本次裁剪需要处理的条目数量，适合把工作量摊开
XTRIM orders MINID ~ 1712669055705-0 LIMIT 1000

近似模式的关键边界是“可能少删”，不是“向前多删”：它可能留下少量低于阈值的旧消息，但不会因为近似而把阈值之后的新消息当成旧消息删除。代价是清理后仍可能看到比预期更多的条目。

LIMIT 是工作量控制，不是新的保留边界。需要严格清理时不要把较小的 LIMIT 误解成“已经完成了全部裁剪”；需要关闭限制时可使用 LIMIT 0，但应结合写入压力谨慎设置。

消费组存在时，别忽略引用策略

Stream 如果被消费组读取，裁剪消息和消费组的 Pending Entries List（PEL）之间还会有引用关系。Redis 8.2 起，XTRIM 支持用 KEEPREF、DELREF 和 ACKED 明确处理方式：

• KEEPREF：默认策略，删除 Stream 条目，但保留消费组中的引用。
• DELREF：删除条目时，同时清理消费组对这些条目的引用。
• ACKED：只清理已经被所有消费组确认的条目。

如果多个消费组对同一批消息有不同进度，优先把数据保留边界和确认策略一起评估；不要只看到 Stream 的最早 ID 变化，就推断所有消费组都已处理完成。使用这些参数前也要确认服务端版本支持对应能力。

用两个只读命令复查边界

发布裁剪任务后，可以用只读查询确认“最早条目”和“消费组状态”是否符合预期。下面的命令是复查入口，不把命令返回内容伪装成本文已经执行过的运行截图：

# 查看裁剪后最早的一小段消息，重点检查第一条 ID
XRANGE orders - + COUNT 3

# 查看 Stream 的长度、首尾 ID 等概要信息
XINFO STREAM orders

# 查看各消费组的读取与待确认状态
XINFO GROUPS orders

复查时先看最早 ID，再看 Stream 长度和消费组状态。若使用了 ~，最早 ID 仍可能小于阈值，这是近似裁剪的预期；若使用 = 却发现阈值之后的消息消失，应优先检查脚本传入的完整 ID、key 是否正确，以及是否有其他裁剪任务同时作用于同一个 Stream。

常见边界问题

MINID 会删除阈值本身吗？

不会。按官方定义，MINID 删除的是 ID 小于阈值的条目；阈值及更大的 ID 属于保留侧。

为什么不用 MAXLEN 代替？

MAXLEN 按条目数量保留最新消息，适合“最多留 N 条”的规则；当业务窗口由时间或事件 ID 表达时，MINID 更直接，也不会因为写入速度变化而改变时间边界。

应该传毫秒时间戳还是完整 ID？

应传完整的 Stream ID。时间戳相同的消息仍可能拥有不同序号，完整 ID 才能表达精确的第一条保留消息。

小结

按 ID 截断 Redis Stream 时，把 MINID 当作“第一条保留消息”的边界即可：严格窗口使用 =，高频场景可使用 ~，需要控制单次清理负担时再加 LIMIT。存在消费组时，继续评估 PEL 引用策略，并用 XRANGE、XINFO STREAM 和 XINFO GROUPS 复查边界。