redis内存淘汰与持久化是完全独立的机制：淘汰策略在写操作时同步触发以释放内存，而持久化仅异步落盘且不减少内存占用。
内存淘汰和持久化根本不是同一层机制
Redis 的内存淘汰（maxmemory-policy）和持久化（RDB/AOF）解决的是完全不同的问题，不存在“谁优先触发”的竞争关系。持久化是异步/周期性将数据落盘，不响应内存压力；而内存淘汰是写操作路径上的**同步拦截点**——只要 maxmemory 已设且写入导致内存超限，Redis 就必须在返回命令结果前决定是否淘汰、淘汰谁。它不等后台子进程完成 RDB，也不管 AOF 是否正在重写。
高负载下内存淘汰更频繁的真正原因
高并发写入会快速推高 used_memory，尤其当大量 key 带 EX 或 PEXPIRE 时，volatile-* 类策略会密集参与决策。此时你看到的“频繁淘汰”，其实是以下现象叠加的结果：
- 写请求量大 → 内存增长快 → 更快触达
maxmemory - 大量带 TTL 的 key 存在 →
volatile-lru或volatile-ttl策略实际生效范围广 - LRU/LFU 采样逻辑本身有开销 → 高负载下采样频率或样本数可能被内部限流，反而让淘汰行为显得更“集中”
- 持久化（如
BGSAVE）会 fork 子进程，短暂加剧内存碎片和 RSS 增长 → 可能间接加速下一次淘汰触发
为什么不能靠持久化缓解内存压力
持久化文件（dump.rdb 或 appendonly.aof）只是磁盘副本，对 Redis 进程运行时的内存占用 零影响。即使你刚执行完 SAVE，used_memory 也不会下降 1 字节。常见误解是“AOF rewrite 能释放内存”，其实 rewrite 只是生成新 AOF 文件并原子替换旧文件，旧 AOF 文件的内存映射仍由父进程持有，直到 rewrite 完成后才逐步释放 —— 这个过程不回收 key 所占的内存。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真正释放内存的唯一方式，是让 key 被删除（显式 DEL、过期自动删、或被淘汰策略选中）。持久化只负责“记住它曾经存在过”。
配置不当导致淘汰误伤的关键点
最容易被忽略的是 maxmemory 和淘汰策略的组合陷阱：
- 没设
maxmemory：Redis 默认不限制内存，但 OOM Killer 可能在系统级杀掉进程，此时根本不会走 Redis 自身淘汰逻辑 - 设了
maxmemory却用noeviction：高负载下所有写命令直接返回(error) OOM command not allowed when used memory > 'maxmemory'，业务立刻写失败 - 混用
allkeys-*和永不过期 key：如果业务误存了大量无 TTL 的大 value（比如日志缓存），allkeys-lfu可能错误淘汰热点小 key，而冷大 key 却岿然不动 -
volatile-ttl在批量写入短 TTL 数据时，会倾向淘汰刚写入的 key（因为剩余 TTL 最短），造成缓存命中率断崖下跌
这些不是算法缺陷，而是策略与数据生命周期错配的必然结果。调优时必须同时看 INFO memory 中的 used_memory_peak、mem_fragmentation_ratio 和 evicted_keys，而不是只盯着淘汰策略名。
