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 里的消息得靠业务层监控和超时清理
