redis stream完全无视maxmemory-policy，因其被设计为“只追加日志”结构，所有entry可能被多个消费者组的pel引用，淘汰会导致状态错乱；其rax+listpack存储不支持lru/lfu标记，实测evicted_keys恒为0。

Redis Stream 为什么完全无视 maxmemory-policy

因为 Redis 内部压根没给 Stream 实现淘汰逻辑——这不是遗漏，是明确设计。Stream 被当作“只追加日志”结构处理，所有 entry 都可能被多个消费者组引用（PEL 队列里还挂着未 ACK 的消息），如果后台按 LRU/LFU 淘汰某条 entry，会导致消费者组状态错乱、消息丢失或重复投递。

实测中，哪怕你把 maxmemory-policy 设成 allkeys-lfu 并触发内存上限，INFO memory 里的 evicted_keys 始终为 0，而 mem_clients_normal 持续上涨。Stream 的 Rax + listpack 存储方式也不支持传统淘汰标记机制。

XADD MAXLEN 是唯一实时限长手段

Stream 不吃 LTRIM 那套，XTRIM 也不是实时控制开关，只有 XADD 命令内嵌的 MAXLEN 参数能真正实现“写入即裁剪”的原子性。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• XADD mystream MAXLEN 1000 * field value：严格保留最多 1000 条，超出部分在本次写入时直接丢弃最老端数据
• XADD mystream MAXLEN ~ 1000 * field value：允许保留 1000 或 1001 条，减少内部压缩开销，不保证精确
• MAXLEN 必须紧跟在 stream key 名之后、ID 和字段之前；放错位置（比如写在 * 后面）会直接报 ERR Syntax error
• 它只对本次 XADD 生效，不会回溯清理已有数据——如果 stream 已有 2000 条，再执行 MAXLEN 1000，不会删掉 1000 条，只在下一次写入时开始截断

为什么不能靠 XTRIM 补救式限长

XTRIM 是独立命令，非原子、无触发机制、不嵌入写入流程，用它做“实时限长”等于裸奔。

• XTRIM mystream MAXLEN 1000 只执行一次，不会自动重复；要靠定时任务轮询，中间存在明显窗口期
• 若生产者狂发 XADD（没带 MAXLEN），两秒内可能积压数万条，XTRIM 还没跑完，内存已爆
• 多个客户端并发写入时，XTRIM 和 XADD 之间存在竞态：A 写入后 B 立刻 XTRIM，但 C 在 B 执行前又写了一条，这条就逃逸了裁剪
• XDEL 更不可取——它只是逻辑标记删除，Rax 树节点不真正释放，频繁 XDEL 反而加剧内存碎片和占用

容易被忽略的内存与行为细节

Stream 单条消息的内存开销远高于 List 元素：每个 entry 包含完整 ID（时间戳+序列号）、字段名、字段值、编码头等，且底层用 Rax 树索引，结构更重。

• 启用 MAXLEN 会让单次 XADD 耗时略增（要同步做裁剪），但这是必要代价——避免后续 XREAD 扫描卡顿、OOM 崩溃
• 消费者组未及时 XACK，会导致 PEL（Pending Entries List）持续堆积，这部分数据 MAXLEN 完全不碰——它们算“已分发但未确认”，仍需保留
• 如果你依赖消费组做可靠投递，MAXLEN 控制的只是“未被任何组读取过的消息”长度，PEL 里的消息得靠业务层监控和超时清理