不存在。redis内存淘汰策略对stream数据完全不生效，stream是持久化结构，不会被lru/lfu等驱逐；所谓“丢失”实为xtrim截断、未ack致pel积压、aof未开启导致宕机元数据丢失等原因。
Redis内存淘汰对Stream数据丢失的影响真实存在吗？
不存在。Redis的内存淘汰策略（如maxmemory-policy）对Stream数据**完全不生效**——Stream是持久化数据结构，不会被LRU、LFU等策略驱逐。所谓“内存淘汰导致消息丢失”，其实是误把XTRIM截断、DEL误删、或未开启AOF/RDB导致的宕机丢失，当成内存淘汰在起作用。
为什么开了MAXLEN还会丢消息？关键在PEL不清理
MAXLEN只控制Stream主链表长度，对Pending Entries List（PEL）里的已读未确认消息毫无影响。消费者组拉取后没XACK，这些消息就卡在PEL里，持续占内存，且XTRIM根本触碰不到它们。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 监控时若只查
XLEN mystream，会误以为数据量正常，实际PEL可能积压数万条 - 用
XPENDING mystream mygroup定期检查待确认消息数，超过阈值（如1000）必须告警 - 不能依赖“自动ACK”：Spring Data Redis默认
autoAcknowledge=true，一读即删PEL，异常时消息直接消失 - 正确姿势是关闭自动ACK，并在业务逻辑成功后显式调用
stringRedisTemplate.opsForStream().acknowledge(group, message)
服务重启后消费进度回退，不是Stream问题而是AOF没开
Stream的消费组状态（LASTID、PEL、消费者信息）全靠Redis服务端持久化机制落地。如果仅启用RDB，两次快照之间宕机，这部分元数据就丢了，重启后消费者从头开始读，造成重复消费甚至漏消费。
- 必须开启AOF：
CONFIGSET appendonly yes（Redis 6.0+可热启；旧版本需改redis.conf并重启） - AOF刷盘策略选
everysec，平衡性能与安全性；always慎用，磁盘IO跟不上时会阻塞写入 - 验证是否生效：执行
INFO persistence，确认aof_enabled:1且aof_last_rewrite_time_sec非-1 - 别信“Stream自带持久化”——它只是数据结构支持持久化，不等于你已经配好持久化
手动ACK失败后怎么兜底？重试和死信要自己建
Redis Stream本身不提供重试队列或死信机制。一旦XACK失败（网络中断、连接断开），消息就永远滞留在PEL里，既不重发也不丢弃。
- 消费者处理失败时，不要直接抛异常完事；应捕获后记录日志，并主动调用
XCLAIM把消息转给其他消费者或专用重试消费者 - 用
XPENDING ... IDLE 60000找出空闲超60秒的消息，定时扫描并触发人工干预或自动归档 - 死信处理建议另起一个Stream（如
mystream.dlq），用独立消费者监听PEL异常消息，避免污染主链路 - Spring Boot中，
StreamMessageListenerContainer的errorHandler必须自定义，不能依赖默认空实现
XTRIM，也不受内存淘汰影响，但一旦堆积，就是内存缓慢泄漏的源头——而这个问题，监控脚本里往往只盯着XLEN，完全看不见。
