Redis Stream 不受maxmemory-policy淘汰机制影响，仅XADD的MAXLEN/MINID参数可在写入时截断数据；MAXLEN加~为近似截断，不加则严格控制条数，且只从最老端删除；消费者组未XACK会导致PEL积压，MAXLEN无法清理。
Redis Stream 的内存淘汰机制不作用于 XADD 的 MAXLEN 截断
Redis 的 maxmemory-policy（如 allkeys-lru）对 Stream 类型**完全无效**——Stream 不会被主动驱逐，哪怕内存爆满、策略设为 volatile-lfu 也一样。这不是 bug，是设计使然：Stream 被视为“日志型结构”，淘汰逻辑交由应用层控制。真正起限长作用的只有 XADD 自带的 MAXLEN 或 MINID 参数，它们在写入时就做截断，不依赖后台淘汰。
用 XADD + MAXLEN 实现流数据独立限长的正确姿势
MAXLEN 是唯一可靠的流长度控制手段，但容易因参数理解偏差导致行为不符预期：
-
XADD mystream MAXLEN ~ 1000 *中的~表示“近似裁剪”——Redis 可能保留略多于 1000 条（比如 1005），以减少频繁压缩开销；若要**严格等于 1000**，必须去掉~：XADD mystream MAXLEN 1000 * - 当 Stream 已有 1200 条，执行
MAXLEN 1000，Redis 会从**最老端（左端）删除 200 条**，保留最新 1000 条；MAXLEN永远只影响新增写入，不会回溯清理历史 - 若同时使用
MAXLEN和TRIM命令（如XTRIM mystream MAXLEN 1000），两者效果等价，但XADD MAXLEN是原子写+截断，XTRIM是单独命令，存在中间状态窗口
为什么不能靠 maxmemory-policy 管理 Stream 内存？
Stream 在 Redis 内部以 Rax（radix tree）+ listpack 混合编码存储，其节点分配不受 LRU/LFU 标记机制管理。实测中即使设置 maxmemory-policy allkeys-lru 并触发内存淘汰，INFO memory 显示 mem_clients_normal 持续上涨，而 evicted_keys 为 0。更关键的是：Stream 的每个 entry 都可能被多个消费者组引用（PEL 队列），淘汰某条 entry 会导致消费者组状态错乱。所以 Redis 选择彻底绕过淘汰逻辑，把责任交给 MAXLEN/MINID 或定期 XTRIM。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
生产环境必须注意的三个细节
实际部署时这几个点最容易引发内存缓慢泄漏或消息丢失：
- 消费者组未及时
XACK，导致 PEL 积压——MAXLEN不清理 PEL 中的已读未确认消息，这部分内存持续增长且无法被XTRIM触及 -
XADD未带MAXLEN，仅靠定时XTRIM，若写入洪峰期间XTRIM延迟执行，Stream 可能瞬时膨胀数倍，OOM 风险陡增 - 使用
MAXLEN ~ N时，监控工具若按“精确条数 = N”告警，会误报；应改用XRANGE mystream - + COUNT 1+XPENDING组合估算有效数据量
Stream 的“限长”本质是写入契约，不是内存治理手段；一旦漏掉 MAXLEN，后续所有补救都只是亡羊补牢。
