redis内存耗尽时需配置八大淘汰策略之一，核心是根据数据是否有ttl、访问模式（lru/lfu/ttl/随机）及业务可靠性要求选择合适策略，避免误配noeviction或volatile策略导致实际无键可淘汰。
Redis 没有“堆内存”概念，它不依赖 JVM 或类似运行时的堆管理机制。所谓“堆内存不足”是常见误解——Redis 的内存完全由操作系统直接分配，其内存限制（maxmemory）控制的是整个 Redis 进程可用的物理内存总量，而非某类“堆空间”。
你真正需要关注的，是 Redis 在总内存达到 maxmemory 上限时，如何选择键来释放空间。这叫内存淘汰策略（maxmemory-policy），不是 JVM 堆 GC，也不涉及对象引用、分代回收等机制。
先搞清两个关键前提
• Redis 内存 = 所有数据 + 元数据 + 客户端缓冲区 + AOF 缓冲等，全部占用的是操作系统物理内存；
• 淘汰触发时机：仅当新写入操作（如 SET、LPUSH）导致内存即将超 `maxmemory` 时才触发，读操作不会触发淘汰。
八种淘汰策略怎么选？看数据有没有 TTL
策略本质分两类：
– 只动带过期时间的键（volatile-xxx）：适合缓存+持久数据混合场景，比如 session（带 TTL）和配置项（永不过期）共存；
– 所有键都参与淘汰（allkeys-xxx）：适合纯缓存场景，所有数据均可丢弃。
- volatile-lru：在带 TTL 的键里，淘汰最久没被访问的 → 适合会话、临时令牌等访问有局部性场景
- volatile-ttl：在带 TTL 的键里，优先淘汰马上要过期的 → 减少无效驱逐，适合 TTL 设置较分散的缓存
- allkeys-lru：全局淘汰最久未用键 → 经典缓存策略，电商商品页、API 响应缓存常用
- allkeys-lfu（Redis 4.0+）：全局淘汰访问频次最低的 → 更适应“长尾冷数据多、少数热点极热”的场景，比如推荐系统缓存
别踩这些典型坑
• 误配 noeviction 却没监控：写请求持续失败，业务报 OOM 错误却没人告警；
• 用了 volatile 策略但大量键没设 TTL：实际无键可淘汰，结果退化成 noeviction；
• allkeys-random / volatile-random 用于核心缓存：随机性导致热点数据被误删，命中率骤降；
• 忽略内存碎片：`used_memory_rss / used_memory > 1.5` 时，即使 `used_memory` 没超限，也可能因碎片无法分配新块而触发淘汰。
实战建议：三步定策略
1. 先分类数据：哪些必须永驻（如分布式锁标记）、哪些天然有时效（如验证码、token）；
2. 再看访问特征：是“最近访问决定价值”（选 LRU），还是“长期访问频次决定价值”（选 LFU）；
3. 最后验证行为：用 `INFO memory` 观察 `mem_clients_normal`、`mem_allocator` 和淘汰计数 `evicted_keys`，确认策略按预期生效。
