noeviction 是 Redis 3.0+ 默认淘汰策略，内存超限时拒绝写入并报 OOM 错误；真正延长 Redis 可用寿命需先设置 maxmemory 并合理配置淘汰策略，否则策略不生效。
noeviction 是默认策略，但它不会提高 Redis 的使用寿命——它只会在内存满时拒绝写入，让业务直接报错。真正能延长 Redis 实际可用寿命的，是合理启用并配置内存淘汰策略，避免因 OOM 崩溃、频繁重启或人工干预导致的服务中断。
为什么必须先设置 maxmemory？
Redis 默认不限制内存使用，淘汰策略根本不会触发。不设 maxmemory，哪怕配了 allkeys-lru 也等于没配。
- 必须在
redis.conf中显式写入，例如：maxmemory 2gb - 运行时也可动态设置：
CONFIG SET maxmemory 2gb，但重启后失效 - 值不能为 0 或未设置；单位支持
gb、mb、kb，不带单位默认字节 - 注意：主从复制场景下，该配置只对主节点生效（从节点不参与淘汰）
volatile-ttl 适合什么场景？
它只淘汰设置了过期时间（TTL）且剩余时间最短的 key，本质是“赶在过期前主动清理”，特别适合 TTL 高度离散、且有明确生命周期的缓存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 典型用例：短信验证码（
expire设为 5 分钟）、临时 token（setex设为 2 小时） - 优势：避免大量短期 key 堆积，减少惰性删除和定期删除的压力
- 风险：如果大部分 key 都没设 TTL（比如持久化存储类数据），该策略退化为不淘汰 —— 此时写入仍会失败
- 验证是否生效：
INFO memory查看evicted_keys是否增长，INFO stats看expired_keys是否明显低于平时
allkeys-lru 和 volatile-lru 别混用
两者都基于 LRU 近似算法，但作用范围完全不同，选错会导致数据误删或策略失效。
-
allkeys-lru：所有 key 都参与淘汰，不管有没有 TTL。适合纯缓存场景（如页面 HTML 片段、API 响应体），但会把你不希望淘汰的长期配置项也清掉 -
volatile-lru：只淘汰带 TTL 的 key，永久 key（如全局开关、白名单）绝对安全。适合混合数据类型部署，但若写入的 key 大部分没设 TTL，就会快速触达maxmemory并报 OOM - Redis 不会自动帮你补 TTL ——
SET user:1001 "data"这种写法产生的 key 永远不会被volatile-*策略处理 - 检查 key 是否有 TTL：
TTL keyname返回-1表示无过期时间，-2表示 key 不存在
淘汰不是万能的，关键看 evicted_keys 和 used_memory_peak
配置完策略不等于问题解决，得盯住两个指标：一个是实际淘汰了多少 key，另一个是内存峰值是否持续逼近 maxmemory。
-
INFO memory中的evicted_keys为 0？说明策略没生效，优先查maxmemory是否设了、key 是否带 TTL -
used_memory_peak接近maxmemory且波动小？说明淘汰节奏跟不上写入节奏，可能需要调大maxmemory或优化客户端缓存写入模式 - 高频淘汰（每秒数百次）会增加 CPU 开销，
INFO stats中的evicted_keys增速 +instantaneous_ops_per_sec可交叉判断 - LFU 类策略（
allkeys-lfu、volatile-lfu）在 Redis 4.0+ 才支持，低版本配了会启动失败
evicted_keys 开始线性增长，同时 mem_fragmentation_ratio > 1.5，就得怀疑是不是 key 生命周期设计不合理，或者客户端在反复写入未设 TTL 的热数据。 
