Stream 的容量控制
Stream 是只追加结构，不控制长度就会无限增长。XADD 时可以直接带上 MAXLEN 做写入即裁剪，也可以之后用 XTRIM 单独裁剪。两个命令都分精确与近似两种模式：不带 ~ 的写法精确裁到指定条数或时间点，代价是逐条删除；带 ~ 的写法按宏节点整块删除，速度更快，但实际保留量可能略多于设定值。要按时间窗口保留数据，用 MINID 指定保留的最小 ID。
基本信息
| 写入裁剪 | XADD key MAXLEN ~ 1000 * field value |
|---|---|
| 独立裁剪 | XTRIM key MAXLEN ~ 5000 |
| 按时间裁剪 | XTRIM key MINID ~ <毫秒时间戳ID> |
| 近似模式 | 加 ~ 后缀，按宏节点整块删除 |
| 状态查看 | XLEN 看长度，XINFO STREAM 看首尾 ID 与消费组 |
典型使用场景
- 日志与事件流按条数保留最近 N 条，控制内存增长
- 按时间窗口保留数据，用 MINID 配合毫秒时间戳 ID 实现
- 消费组仍在处理的消息不宜裁掉，裁剪前先核对组进度
- 写入时直接内联 MAXLEN，省掉额外的定时裁剪任务
- 排查内存持续上涨时，确认是不是忘了设置任何裁剪策略
示例
示例
redis-cli XADD logs MAXLEN ~ 1000 '*' msg hello # 写入并近似裁剪
redis-cli XTRIM logs MAXLEN ~ 5000 # 近似保留最近 5000 条
redis-cli XTRIM logs MAXLEN 5000 # 精确裁剪，开销更高
redis-cli XTRIM logs MINID 1730000000000 # 只保留该 ID 之后的数据
redis-cli XLEN logs # 当前长度
redis-cli XINFO STREAM logs # 首尾 ID、长度、消费组信息
redis-cli XINFO GROUPS logs # 组进度与待处理数量裁剪方式对照
| 用法 | 精度 | 适用场景 |
|---|---|---|
| MAXLEN ~ N | 近似，可能略多于 N 条 | 高频写入，优先性能 |
| MAXLEN N | 精确到 N 条 | 对长度有硬性要求 |
| MINID ~ ID | 近似，按时间点保留 | 时间窗口类数据 |
| XADD 内联裁剪 | 与写入同批完成 | 不需要额外定时任务 |
近似裁剪按宏节点整块删除，默认每个宏节点大约 100 条，因此实际保留数量通常略多于设定值。这是官方明确的性能与精度取舍，不是异常现象。
裁剪并不会自动清理消费组的待处理条目记录：被裁掉但尚未确认的消息，其记录仍留在待处理列表里，需要结合待处理条目的认领与清理策略一起考虑，否则会出现永远无法处理的残留。