Redis Stream按长度保留历史事件

Redis Stream 很适合记录订单状态、设备事件和异步任务，但它的“追加”特性也带来一个现实问题：事件不断写入，历史就不断变长。我的处理方式是把保留策略放在写入路径或维护任务里，而不是等内存告警后再临时删除。

保留最近一段历史，最直接的方案是给 XADD 加 MAXLEN；已经存在的 Stream 则使用 XTRIM。官方地址：https://redis.io/docs/latest/commands/xtrim/

写入时用 MAXLEN 控制最近事件

如果业务只需要最近 1 万条事件，可以在生产者写入时直接声明上限：

# 写入一条事件，并让 Stream 大致保留最近 10000 条
redis-cli XADD order-events MAXLEN ~ 10000 * \
  order_id 10086 status paid

# 查看当前条数，确认裁剪后规模是否符合预期
redis-cli XLEN order-events

这里的 ~ 是近似裁剪标记，不是 shell 运算符。它允许 Redis 为了减少频繁整理而暂时多保留一些条目，适合高频写入。若业务要求每次写入后都严格不超过阈值，可以去掉 ~，但应先评估额外整理成本。

已有 Stream 用 XTRIM 做维护

历史数据已经积累后，可以单独执行裁剪。常见的定期维护命令如下：

# 对已有 Stream 做近似长度裁剪，适合低频维护任务
redis-cli XTRIM order-events MAXLEN ~ 10000

# 需要严格按数量裁剪时去掉 ~，返回被移除的条目数量
redis-cli XTRIM order-events MAXLEN 10000

XTRIM 返回被删除的条目数量；它不是“保留后的长度”。因此不要把返回值直接当成 XLEN 使用。若按事件时间而不是条数保留，可以考虑 MINID，让某个 ID 之前的事件离开 Stream；两种策略的边界不同，不能只改参数就当成同一个方案。

我更倾向于高频生产时使用 XADD ... MAXLEN ~ N，再用定时任务检查实际长度；只有需要把历史立即收紧时，才单独运行精确 XTRIM。

消费组存在时，先算清楚历史窗口

Stream 的长度上限不是越小越好。假设消费者平时 2 分钟处理完，但故障恢复可能需要 15 分钟，那么只保留最近 1000 条并不能自动保证可恢复；事件一旦被裁掉，就不能再从 Stream 中补读。

还要注意消费组的 Pending Entries List：裁剪 Stream 数据不会替消费者完成确认，也不会把失败处理变成成功处理。生产上应把“允许回放多久”“最长离线多久”“处理失败如何补偿”写进容量与保留策略，而不是只看 XLEN。

用检查命令确认裁剪没有误伤

# 查看长度与首尾 ID，判断保留窗口是否发生移动
redis-cli XLEN order-events
redis-cli XRANGE order-events - + COUNT 2
redis-cli XREVRANGE order-events + - COUNT 2

# 查看消费组状态，重点关注 pending 与消费者空闲时间
redis-cli XINFO GROUPS order-events

检查时至少记录三项：当前长度、最早事件 ID、消费组的 pending 数量。如果最早 ID 已经跨过仍需补偿的事件，继续缩短 MAXLEN 只会让恢复路径更脆弱。对关键事件，还可以在裁剪前异步归档到持久化存储，让 Redis Stream 只承担近期读取和消费协调。

相关问题

MAXLEN 后面的 ~ 能不能省略？

可以。省略后是精确裁剪，适合必须严格控制长度的场景；高频写入通常先评估近似裁剪带来的性能收益。

XTRIM 返回 1000 是不是现在只剩 1000 条？

不是，它表示本次移除的条目数量。裁剪后剩余多少要用 XLEN 单独读取。

裁掉的事件还能从消费组里恢复吗？

不能把被裁掉的 Stream 条目当作可靠回放来源。需要恢复时，应提前保留足够窗口或把关键事件归档到其他持久化存储。