XTRIM 不能只用 MAXLEN 因其会误删未消费消息，安全清理需基于所有消费者组最小 pending ID 的前一个 ID，即全局安全删除点；Redis 6.2+ 支持 XTRIM ... MINID ~xxx 精准清理。
为什么 XTRIM 不能只写 MAXLEN 1000 就完事？
因为单纯靠 MAXLEN 截断，极可能误删还没被消费的消息——尤其当某个消费者组严重落后时。比如你设了 MAXLEN 1000，但 XPENDING 显示某组最小 pending ID 是 1717020000000-0，而流里最老消息是 1716950000000-0，那这 70 万条全删掉，那个落后的组就永远收不到它们了。
真正安全的清理，得知道“所有组都确认到哪了”。这个点叫「全局安全删除点」，等于所有消费者组中「已处理消息 ID 的最小值」。它不是 last_delivered_id，而是每个组 XPENDING 返回的最小 pending ID 的前一个 ID。
-
XPENDING mystream mygroup - + 1查单个组最小 pending ID - 多个组要分别查，再取最小值，再手动减一（或用
~前缀让 Redis 自动找边界） - Redis 6.2+ 支持
XTRIM mystream MINID ~1717020000000-0，这才是精准清理
MAXLEN 和 MINID 在 XADD 里怎么选？
MAXLEN 可以直接写在 XADD 命令末尾，是生产端最轻量的兜底；MINID 则只能用于 XTRIM，没法在写入时用。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
XADD mystream MAXLEN 1000 * field value：每写一条都检查长度，O(1) 开销，内存立刻释放 -
XADD mystream * field value+ 定时XTRIM mystream MINID ~xxx：更准但需额外监控和计算，适合对数据完整性敏感的场景（如金融事件流） - 别混用：
XADD ... MAXLEN和后台XTRIM ... MINID同时开，可能触发重复裁剪，浪费 CPU
Spring Boot 里配置 MAXLEN 防 OOM 的实操要点
Spring Data Redis 的 StreamOperations.xAdd() 不直接暴露 MAXLEN 参数，得绕一下。
- 用
execute()手动调 Redis 原生命令：redisTemplate.execute((RedisCallback<String>) con -> con.xAdd(...)) - 或者改用
LettuceConnectionFactory+ 原生StatefulRedisConnection，控制力更强 - 配置项别硬编码——把
max-len: 1000写进application.yml，上线后可动态调整 - 务必配监控：用
MEMORY USAGE mystream+XINFO STREAM mystream看实际增长斜率，1000 条只是起点，高吞吐下可能得调到 5000+
消费者没 XACK，XTRIM 也救不了内存
XTRIM 只删流里的消息体，不碰消费者组的 Pending Entries List（PEL）。而 PEL 会为每条未确认消息单独存一份引用，内存占用不比消息体小。
- 一个 pending 消息至少占 32 字节元数据 + ID 占用，和消息体叠加后，内存翻倍很常见
-
XPENDING mystream mygroup要定期跑，发现 pending 数持续上涨，说明消费者卡住了或忘了XACK - 补救方法只有两个：
XACK手动确认，或用XCLAIM把超时 pending 消息转给其他消费者重试
流长度控制只是半程，真正的内存守门员，是消费者是否及时交出 XACK。这点容易被忽略，但一旦漏掉，XTRIM 再勤快也没用。
