Redis 7.0 中 listpack 退化、内存碎片降低导致淘汰延迟加剧、volatile-* 策略因过期键积压和缺失 TTL 而失效，三者共同引发 LRU/LFU 淘汰失真与雪崩风险。
listpack 编码退化导致 LRU/LFU 信息失真
Redis 7.0 默认用 listpack 替代 ziplist 存储小对象，但只要配置或操作稍有偏差，就会退化为 quicklist 或 linkedlist，进而让原本紧凑的 key 失去统一内存布局。LRU/LFU 淘汰依赖访问时间戳和热度计数器，而这些元数据在 listpack 中是集中、稳定维护的；一旦退化，每个节点独立管理元数据，采样池看到的“最近访问”变成碎片化快照，淘汰顺序严重偏离真实冷热分布。
常见退化触发点：
-
list-max-ziplist-size设为负值（如-2），强制启用quicklist -
hash-max-ziplist-entries或zset-max-ziplist-entries过小（如设成16），少量数据就升级结构 - 高频
LPOP+RPUSH边界操作，反复 realloc 导致listpack分裂
验证是否生效：DEBUG OBJECT key 返回 encoding: listpack 才算正常；若显示 quicklist，说明淘汰逻辑已运行在非预期结构上。
maxmemory-policy 触发时机受碎片率影响变大
7.0 的 listpack 降低 jemalloc 内部碎片，mem_fragmentation_ratio 常压在 1.1–1.3，而旧版本常达 1.6+。这意味着：同样设 maxmemory 4gb，5.0 可能因碎片实际只剩 2.5gb 可用就触发淘汰；7.0 却能撑到接近 3.8gb。表面看是“更省空间”，实则是淘汰被推迟——但一旦触发，往往已是真实数据量逼近上限，淘汰强度陡增，表现为单位时间内 evicted_keys 突然飙升。
排查时别只盯 used_memory，要同时看：
-
used_memory_rss和used_memory差值是否 >100MB -
mem_fragmentation_ratio是否持续（说明碎片低，淘汰延迟属正常） - 若差值小但淘汰频繁，问题大概率不在碎片，而在 TTL 集中或写入突增
AOF 重写与淘汰策略在 7.0 中耦合更紧
7.0 默认开启 lazyfree-lazy-eviction yes，但该配置仅对删除动作异步化，无法缓解 BGREWRITEAOF 期间的内存申请压力。aof_rewrite_buf 是动态增长的，若此时 used_memory / maxmemory > 0.7，重写过程极易突破阈值，触发连续同步淘汰（freeMemoryIfNeeded），CPU 拉高、延迟毛刺明显。
关键调整项：
- 把
auto-aof-rewrite-percentage从默认100降至60–80（尤其当内存水位 >70% 时） -
auto-aof-rewrite-min-size同步下调至32mb，减小单次重写数据量 - 禁用
lazyfree-lazy-eviction yes（即保持默认no），确保淘汰动作同步完成，避免异步堆积延迟释放内存
volatile-* 策略在 7.0 中更容易失效
7.0 对过期键的惰性删除更激进，且定期删除扫描频率未同步提升。如果大量 key 设置了相同 TTL（如全设 EXPIRE key 3600），它们会在同一秒自然过期，但 Redis 不会立刻删——而是等下次访问或定期扫描才清理。这导致 volatile-lru 在内存未满时完全不触发，而真正需要它时（如过期洪峰后），expires 字典里已积压大量待删 key，used_memory 虚高，淘汰策略反而误判为“还有空间”，直到某次写入突然触发大批量驱逐。
更隐蔽的问题是：若部分 key 忘记设 TTL，volatile-lru 就直接退化为 noeviction 行为（对无 TTL key 完全不处理），而监控里 evicted_keys 为 0，容易误判“没压力”。
生产建议：
- 杜绝所有 key 使用统一 TTL 值，必须加随机偏移（如
3600 + rand(300)） - 用
INFO stats查expired_keys和evicted_keys的比值，若前者远大于后者，说明过期清理跟不上 - 宁愿选
allkeys-lru并预留 20% 内存余量，也别依赖volatile-*类策略防雪崩
真正影响策略表现的，从来不是策略名本身，而是它运行其上的数据结构稳定性、内存压力反馈的真实性和过期清理节奏的可控性。7.0 把底层细节藏得更深，但每处优化都放大了配置偏差的后果。
