Redis Stream 保留按长度和最小 ID 控制流保留的实现方法

我在给事件流加内存保护时，最先遇到的误区是只设置一个“最多保留多少条”。订单事件、设备心跳和审计消息的保留目标并不一样：有的只需要最近 10 万条，有的必须保留最近两小时。Redis Stream 更适合把这两个目标拆开，用 MAXLEN 按数量裁剪，用 MINID 按消息 ID 边界裁剪。

先按保留目标选择 MAXLEN 或 MINID

MAXLEN 的阈值是条目数。执行 XTRIM orders MAXLEN 100000 后，Redis 会从最旧的低 ID 条目开始删除，目标是留下不超过 100000 条。它适合流量比较稳定、只关心最近 N 条消息的队列或事件环。

MINID 的阈值是 Stream ID。小于阈值的条目会被删除，大于或等于阈值的条目保留。它适合调用方已经把“保留两小时”换算成一个时间毫秒值的场景。Stream ID 的前半段通常体现毫秒时间，但不要把它当成业务时间字段；如果业务时间和写入时间不同，应先明确用哪一个作为留存依据。

用 XTRIM 主动调整 Stream 的保留边界

下面是一组可放进维护脚本的命令。示例中的 ID 只是说明格式，生产环境应由实际窗口计算得到；执行后用 XLEN 和 XINFO STREAM 检查结果，不要只看命令返回的删除条数。

# 数量护栏：近似裁剪，允许保留条目略多于 100000 以换取更低的整理成本
redis-cli XTRIM app:events MAXLEN ~ 100000

# 时间边界：删除 ID 小于阈值的旧消息，阈值末尾的 -0 表示该毫秒下的起始序号
redis-cli XTRIM app:events MINID ~ 1710000000000-0

# 结果检查：确认当前长度，并查看最老和最新消息 ID
redis-cli XLEN app:events
redis-cli XINFO STREAM app:events

不写 ~ 时是精确裁剪，数量或最老 ID 会更贴近阈值，但维护成本可能更高。对于“不能超过某个硬上限”的安全护栏，优先精确策略并配合容量告警；对于高频写入且只需控制大致内存的事件流，近似策略通常更合适。

把裁剪放在写入路径，还是单独维护

如果流量持续、保留策略固定，可以把裁剪参数直接放到 XADD，让每次写入顺便触发清理。这样不容易漏掉维护任务，但生产者会承担一点额外的写入开销；如果同一 Stream 有多个生产者，所有生产者都应使用同一条规则。

# 写入并维持大约 100000 条；消息字段仍按 field value 成对传入
redis-cli XADD app:events MAXLEN ~ 100000 * type order status created

# 需要按 ID 窗口写入时，使用 MINID；阈值由应用按明确的留存窗口计算
redis-cli XADD app:events MINID ~ 1710000000000-0 * type order status created

单独执行 XTRIM 更适合按小时或按峰值维护：可以把清理压力从每次写入移到低峰窗口，也便于统一记录“裁剪了多少条”。但它不是事务性的历史备份；如果消费者必须看到每一条消息，就不能把裁剪当作补偿机制。

消费组引用和上线检查清单

Stream 被消费组读取后，消息可能仍出现在 Pending Entries List（PEL）中。裁剪策略解决的是 Stream 本体中的条目留存，不代表消息已经被确认，也不保证未完成消费的任务还能从 Stream 正常重取。上线前要先确认：裁剪窗口大于最慢消费者的处理窗口；故障重放是否有外部归档；监控同时记录 XLEN、最老消息 ID、消费者延迟和 PEL 数量。

Redis 文档当前还提供了消费组引用处理选项：默认 KEEPREF 会保留 PEL 引用，DELREF 会连引用一起移除，ACKED 只处理已被所有消费组确认的条目。部署前应根据 Redis 版本和客户端支持情况选择，不能只把命令从 MAXLEN 改成 MINID 就认为恢复语义已经解决。

常见问题

MAXLEN ~ 100000 会严格只剩 100000 条吗？

不会。波浪号表示近似裁剪，Redis 可能为了效率在宏节点边界停止，因此实际长度可以略高于阈值。

MINID 的阈值是业务创建时间吗？

不是自动等同于业务时间。它比较的是 Stream ID；应用需要明确 ID 前半段与业务留存窗口的对应关系。

裁剪后还能靠 XACK 找回消息吗？

不能把 XACK 当作找回机制。裁剪和确认是两套语义，必须在边界前完成消费，或从外部归档重新补偿。