Redis XTRIM 怎样按 MINID 保留指定范围的 Stream

想保留某个 ID 起的 Redis Stream，使用 XTRIM 键名 MINID = 下界ID。它删除严格小于下界的记录，等于下界的已有记录会保留；这不是保留任意闭区间的命令，也不会自动清理上界之后的消息。

我倾向于先确定“允许丢掉哪些消息”，再选裁剪参数。下面以独立实验键解释边界，命令没有在本文环境执行，文中的数量是对给定样例的语义推导，不是实测结果。MINID 需要 Redis 6.2 或以上。

官方命令入口：https://redis.io/docs/latest/commands/xtrim/

我会先把保留范围写成 ID 下界

如果任务是只留最近若干条，MAXLEN 更直接；如果任务是保留某个消息 ID 起的所有记录，MINID 更贴合。数量上限和时间窗口不是一回事：流量突增会改变固定条数覆盖的时间长度。

Stream ID 由毫秒部分和序号部分组成，比较时先比较前者，再比较后者。例如 2000-3 小于 2000-4。建议传完整 ID，不把字符串按字典序排序，也不把整个 ID 转成一个普通整数。

下界只是裁剪资格条件，不是补齐承诺。假如流里根本没有等于阈值的条目，裁剪也不会创造一条；剩余的第一条可以大于阈值。下面用完整 ID 便于讨论同一毫秒里的不同消息。

用独立样例看清等号处的记录

请选择确认不存在的独立实验键，例如 demo:xtrim:lesson168；若键已存在，应换一个新名字，不要先删除未知数据。下面是供读者在隔离环境逐条执行的 redis-cli 命令：

EXISTS demo:xtrim:lesson168
XADD demo:xtrim:lesson168 1000-0 kind old
XADD demo:xtrim:lesson168 2000-0 kind boundary
XADD demo:xtrim:lesson168 2000-1 kind same_ms
XADD demo:xtrim:lesson168 3000-0 kind newer
XRANGE demo:xtrim:lesson168 - +
XTRIM demo:xtrim:lesson168 MINID = 2000-0
XRANGE demo:xtrim:lesson168 - +
XLEN demo:xtrim:lesson168

仅在 EXISTS 为 0 时继续写入。假设没有其他客户端修改该键，四次 XADD 都成功，则精确裁剪应删掉 1000-0 这一条，保留其余三条。XTRIM 的整数返回值是本次删除条数，不是剩余长度；剩余数量看 XLEN，具体边界看 XRANGE。

若把阈值改成 2000-1，已有的 2000-0 也处于可裁剪范围。若想只展示 2000-0 到 2000-1，可以使用 XRANGE demo:xtrim:lesson168 2000-0 2000-1 查询，这不会删除范围之外的数据。不要为了获得查询子集而误用不可恢复的裁剪。

精确裁剪和近似裁剪各适合谁

我会把 = 留给“下界以前必须清干净”的任务，把 ~ 留给允许少量旧数据残留、希望降低裁剪开销的任务。这是有条件的取舍，不代表某一种写法总是更好。

XTRIM demo:xtrim:lesson168 MINID ~ 2000-0 LIMIT 1000

这条是近似裁剪的另一个示例，不要接在上面的精确样例后比较删除数量。内部宏节点的组织会影响能否整块移除，所以小样例里近似裁剪返回 0，并不必然是阈值失效。LIMIT 用来控制近似裁剪工作量，不是承诺只剩 1000 条，也不是毫秒超时设置；不要把 LIMIT 拼到精确裁剪上。

严格保留策略不能只依据“命令成功”判定达标；近似模式本身允许残留。大积压情况下，也不能承诺单次精确裁剪零延迟。应把可接受残留与单次工作量分别写入运维约束。

消费组引用不能当作消息正文

消费组的 PEL 是待确认条目的引用清单，不是消息正文的备份。默认裁剪会移除满足裁剪条件的 Stream 条目，即使消费组仍引用这些 ID；引用还在，不意味着消费者还能拿回已删正文。

Redis 8.2 起可明确指定引用策略：KEEPREF 保留现有待确认引用，DELREF 同时移除相应引用，ACKED 只裁剪所有消费组都已读取并确认的条目。较老版本不能直接照搬这些新增参数。这里不把 DELREF 作为通用清理建议，因为它会同时影响重试线索。

有多个消费组时，采用 ACKED 也可能留下超过时间下界的旧消息，尤其当某个消费组长期不推进。不能同时假定“未确认绝不丢”与“所有过期记录立即删除”总能成立。需要先决定保留优先级，并考虑归档、失败处理与慢消费组的职责。

把保留期限接到应用配置上

如果目标是保留最近一天，可以由应用计算固定的截止毫秒值，把它组成 截止毫秒-0 后交给 MINID；不要每次重试都暗中推进阈值。参数应来自受控配置，执行前记录键名、完整阈值、裁剪模式和消费组策略。

这个做法依赖 ID 的毫秒部分确实代表你希望度量的时间。使用显式 ID、回放历史数据或业务事件时间与写入时间不一致时，不能把它当成事件时间保留规则。阈值算错成未来值，还可能清掉当前所有记录。

XTRIM 是一次命令，不是 TTL 调度器。需要应用定期调用，或由写入端使用相应裁剪选项；新消息不会因为过去执行过一次 XTRIM 就自动获得长期保留保证。本文只展示手动裁剪，不直接给生产键接入自动删除任务。

对我来说，MINID 适合边界可解释的日志缓冲区；如果任务要求强审计、任意历史重放或慢消费者永久可恢复，应先有独立持久归档。停止调度只会阻止后续裁剪，不能恢复已经删掉的消息。

哪些现象值得继续观察

读者落地时可以观察命令耗时、实际删除条数、最老剩余 ID、Stream 长度以及各消费组积压。它们回答不同问题：删除条数大不代表内存同比释放，长度变短也不代表所有消费者已经确认。

为什么 MINID 没清掉阈值以前的全部记录？先看是否用了近似模式、工作量限制或 ACKED，再看键、阈值与生产者是否一致。不要把所有残留都归为 Redis 错误。

能否只保留两个 ID 之间的消息？MINID 只负责下界；临时读取区间用 XRANGE。若要物理删除上界之后的数据，需要另外设计删除规则，不能用一次 MINID 冒充双边裁剪。

裁剪后能通过 XACK 找回正文吗？不能。确认待处理引用与恢复正文是两件事；恢复能力取决于独立归档，而不是待确认清单。

我的选择是先把完整 ID 下界讲清，再决定是否接受近似残留；只要存在未处理消息不能丢的要求，就把消费组策略和归档责任放在裁剪命令之前讨论。

参数及版本依据：Redis 官方 XTRIM 文档。