Redis如何结合业务特点定制淘汰策略？-Redis-PHP中文网

maxmemory 必须先设置，否则所有淘汰策略无效；noeviction 在缓存场景下危险，因只拒写不驱逐，易致上游异常雪崩；volatile-lru 依赖过期键比例，allkeys-lru 更通用；volatile-ttl 适用于短周期任务状态缓存；lfu 有cpu开销，需压测验证。

redis如何结合业务特点定制淘汰策略？

maxmemory 必须先设，否则所有淘汰策略都无效——这是最常被忽略的前提。

为什么 `noeviction` 在缓存场景下反而危险？

它不删数据，只拒写。但缓存系统本就依赖“写入驱逐旧值”，一旦触发，SET、HSET 等命令直接返回 OOM command not allowed when used memory > 'maxmemory' 错误，上游服务可能抛异常或降级失败。

适用场景其实很窄：仅限纯只读+可重建的元数据缓存，或金融类强一致性写库（此时 Redis 仅作旁路日志暂存）。普通业务缓存用它，等于把内存压力转嫁给应用层重试逻辑，极易雪崩。

检查是否已启用：CONFIG GET maxmemory 返回 "0" 就代表没开上限，淘汰策略形同虚设
noeviction 下 evicted_keys 指标恒为 0，但 rejected_connections 或客户端报错数会飙升
若必须保数据，优先考虑分库：热数据用 allkeys-lru，冷数据单独实例配 noeviction

`volatile-lru` 和 `allkeys-lru` 到底该选哪个？

关键看你的过期键占比和数据分层逻辑。如果大量 key 都没设 EXPIRE（比如用户 session 用 SETEX，但配置中心数据用 SET 永不过期），volatile-lru 可能根本找不到可淘汰对象，最终退化成 noeviction。

而 allkeys-lru 虽然更“激进”，但它对无过期时间的 key 同样有效——只要访问频次低，就会被抽样淘汰。这对通用缓存更友好。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

查当前过期键比例：INFO keyspace 中看各 db 的 expires 字段，若 keys 远大于 expires，volatile-* 类策略基本失效
maxmemory-samples 默认是 5，调高到 10～15 可提升 LRU 近似精度，但单次淘汰耗时增加，需压测验证延迟毛刺
注意：LRU 是近似算法，靠 robj.lru 字段的 24 位时间戳截断值判断，不是精确访问顺序

`volatile-ttl` 适合什么真实业务？

它不看访问频次，只比谁快过期。典型用于短周期任务状态缓存：比如秒杀库存预扣减的临时锁（SET lock:order:123 "1" EX 10），或 API 限流窗口计数器（INCRBY counter:ip:192.168.1.1 1 + EXPIRE）。这类数据天然具备“越早设过期，越该先删”的语义。

但一旦混入长 TTL 或永不过期 key，volatile-ttl 就完全失效——它只在带 EXPIRE 标记的 key 中找最小 TTL。

监控 evicted_keys 增速的同时，务必对比 expired_keys：若后者远高于前者，说明淘汰主要靠被动过期，volatile-ttl 实际未起效
不要把它当“智能清理”，它只是 TTL 排序器。想保热点，得靠 LFU；想保时间敏感性，才用它
Redis 7.0+ 支持 maxmemory-eviction-step 控制单次淘汰数量，避免大 key 集中释放导致延迟抖动

LFU 策略的隐含成本你测过吗？

volatile-lfu 和 allkeys-lfu 要维护每个 key 的访问频次计数器，每次 GET 都要更新。高频读场景下，CPU 使用率可能比 LRU 高 15%～20%，尤其在小 key 大量并发读时。

它的优势在于识别“稳定中频访问”数据（比如每日固定时段查询的报表缓存），但对突发流量不敏感——计数器衰减周期默认是 100 万次访问或 1 分钟（由 lfu-decay-time 控制），新热 key 需要时间积累热度。

启用前先开 INFO stats 看 instantaneous_ops_per_sec 峰值，若 > 5w QPS，建议压测 LFU 开销
lfu-log-factor 越大，频次区分度越高（10 以上才能明显区分 100 次 vs 1000 次访问），但计数器溢出风险上升
LFU 不是银弹：如果业务里 80% 的读集中在 20% 的 key 上，allkeys-lru 实际命中率可能更高，因为 LRU 对“最近一次访问”更敏感

真正难的不是选策略，而是让策略和业务生命周期对齐——比如用户 token 缓存用 volatile-ttl，商品详情用 allkeys-lru，配置中心用 noeviction 单独实例。混在一个实例里硬套一种策略，迟早踩坑。