Redis 淘汰策略与热点键访问怎样匹配

Redis 淘汰策略要同时匹配两件事：哪些键允许被删，以及“值得保留”由最近访问还是持续访问频率决定。热点稳定、历史访问有参考价值时可以比较 LFU；热点随活动快速轮换时，可以先以 LRU 作为对照。两者都是近似选择，不能保证某个热点键永不被淘汰。

下面采用一个假设的商品缓存场景说明取舍，不是线上事故记录，也没有执行压测或修改 Redis。范围限于 Redis Open Source 常见的 LRU、LFU、随机和 TTL 策略；其他版本新增策略不在本篇比较中。

先分清回源增多影响的是哪些请求

若商品详情可从数据库重建，缓存未命中意味着多一次回源；若同一实例还保存不能丢失的业务状态，问题就不再只是命中率。选择 allkeys 策略之前，必须确认实例内所有键都允许淘汰，不能因为键名有不同前缀，就以为它们获得了隔离。

把业务分成可重建缓存和不可随意删除的数据，比先争论 LFU 是否更好更重要。热点访问很集中也不代表工作集能装入内存：若热门商品本身已经超过预算，换排序规则无法补足容量。淘汰同样不解决单个热点键的并发服务能力问题。

一次活动切换怎样暴露工作集变化

假设日常请求集中于常销商品，活动开始后，一批新商品获得连续访问，活动结束又回到常销商品。这条时间线只说明访问分布的变化，不含任何虚构命中率。

• 活动前：反复被访问的常销商品构成稳定工作集，频率信息有参考价值。
• 活动期间：新热点与旧热点竞争内存。最近访问与历史频率可能给出不同的保留倾向。
• 活动结束：旧活动商品若仍凭历史访问占据空间，需要考察频率衰减和新工作集的适应情况。

LFU 的频率不是无限累积的精确访问总数，而是带衰减的近似计数；LRU 也不是完整记录所有键的严格全局排行榜。因此，“访问一次新键就一定淘汰某个旧键”不能作为可复现承诺。短活动和稳定长尾业务应分开比较，不要只看一次活动结束后的累计指标。

候选范围和排序依据是两项决定

allkeys 表示所有键都可能参与淘汰；volatile 表示只有设置了过期时间的键参与。后缀才表示怎样挑选，例如 LRU 偏向淘汰较久未访问的键，LFU 偏向淘汰低频键。volatile-ttl 按剩余 TTL 倾向选较快过期的键，不等于按热度排序。

没有任何带 TTL 的键时，volatile 类策略无法找到可淘汰候选，表现类似 noeviction。即使还有带 TTL 的键，只要它们不足以释放所需空间，写入仍可能失败。不要把“无 TTL 不参加 volatile 淘汰”理解为持久性保证；更不能因此把两类数据永久混放。

把策略修改限制在可重建缓存

下面是专用、可重建缓存实例的配置片段，不是通用生产参数。容量数值仅用于说明语法，应结合实际内存预算、复制和持久化缓冲等开销另行确定。此片段不包含连接信息，也不会由本文自动执行。

# 仅供独立缓存测试实例使用，容量不是生产建议
maxmemory 256mb
# 示例基线：全体键可淘汰，按最近访问近似选择
maxmemory-policy allkeys-lru

当业务确认热点长期稳定时，可在隔离环境把策略一项改为 allkeys-lfu，保留相同的数据容量和访问样本用于比较，不同时调整 TTL、对象大小和采样参数。LFU 的 lfu-log-factor 控制计数增长尺度，lfu-decay-time 影响频率衰减，不宜在尚未确认工作集特点时一起改动。

若测试出现更高回源压力，回退到已记录的原策略，并恢复此前受控配置。回退策略不能恢复已经淘汰的键，缓存仍依赖正常回源重建；生产变更需要容量和回源承载准备。noeviction 也不是自动止损方案，它把部分内存压力表现为写入错误，而不是凭空增加容量。

用相同观察窗口避免误判

读者可在自己授权的环境查看配置与计数，下面只是只读命令示例，并非本文执行结果。连接、认证与权限按环境提供，不在文章里写入密码。

# 查看当前策略与容量，支持对应CONFIG权限时使用
redis-cli CONFIG GET maxmemory-policy
redis-cli CONFIG GET maxmemory
# 分开记录内存状态、命中及淘汰相关累计计数
redis-cli INFO memory
redis-cli INFO stats

同一个观察区间内，用命中计数增量除以命中与未命中增量之和，分母为零时不计算命中率。进程重启或计数重置后应重新建立基线，不能跨重置相减。再把淘汰计数与自然过期计数的增量、应用回源情况放在一起解释：过期多不等于策略淘汰多；全局命中率也不能说明某个业务前缀的表现。

LFU 能保证最热的键一直存在吗？

不能。它只是近似保留倾向，TTL 到期、显式删除与容量不足仍会影响键是否存在。需要长期保存的数据不应只依赖缓存保留概率。

所有缓存都有 TTL，还需要 allkeys 吗？

应看业务契约，而不是机械看当前键是否恰好都有 TTL。如果实例定义就是全体数据均可重建，allkeys 能直接表达该范围；如果只允许 TTL 子集参与，就必须接受候选池不足的限制。

命中率下降就要改 LFU 吗？

先区分容量不足、TTL 过短和工作集迁移。策略只是这些约束中的一项。最终选择应写成“这个工作集下的取舍”，而不是“热点键一律使用某策略”。

官方参考：Redis Key eviction，https://redis.io/docs/latest/develop/reference/eviction/；Redis 7.2 配置注释，https://raw.githubusercontent.com/redis/redis/7.2/redis.conf。