应选volatile-lfu当所有key均设过期时间，选allkeys-lfu仅限纯缓存场景且无永久数据；前者避免OOM报错，后者需严防误删核心键，二者均须合理配置maxmemory、lfu-log-factor和lfu-decay-time参数。
volatile-lfu 和 allkeys-lfu 到底该选哪个
线上业务里，volatile-lfu 和 allkeys-lfu 的行为差异远不止“是否包含永久 key”这么简单。关键在于：你有没有明确区分“缓存数据”和“配置/字典类数据”。
如果所有 key 都带 EXPIRE（比如 session、token、临时计算结果），那用 volatile-lfu 更安全——它只在你预期的范围内做淘汰；但如果你混用了长期存在的 key（如 config:app、dict:status），又没设 TTL，volatile-lfu 在内存打满时可能直接拒绝写入，报错 (error) OOM command not allowed when used memory > 'maxmemory'.，而不是删掉冷 key。
allkeys-lfu 无差别参与淘汰，适合纯缓存场景，但必须确保没有误存不该淘汰的永久数据。生产环境更常见的是前者配错导致服务抖动，而不是后者误删。
LFU 必须调的两个参数：lfu-log-factor 和 lfu-decay-time
Redis 的 LFU 不是简单计数器累加，而是用对数增长 + 定期衰减来防止历史访问“锁死”淘汰逻辑。默认值 lfu-log-factor 10 和 lfu-decay-time 1（分钟）在高并发下容易失真：
-
lfu-log-factor太小（比如 1），高频 key 的计数器会很快冲到上限，失去区分度；建议从 10 起步，压测时逐步调到 50～100，观察热点 key 是否稳定保留在内存中 -
lfu-decay-time太短（比如 1 分钟），突发流量会让冷 key 计数器快速归零，被误淘汰；业务如果是小时级热度变化，设成 60 或 120 更合理 - 这两个参数必须在
maxmemory-policy volatile-lfu或allkeys-lfu生效后才起作用，单独改没用
maxmemory 设置不当会让 LFU 彻底失效
很多人配完 volatile-lfu 就以为万事大吉，结果压测时发现冷热 key 淘汰完全随机——问题往往出在 maxmemory 没设，或设得太高。
Redis 6.0 的 LFU 实现依赖采样和计数器更新，这些动作只在内存逼近 maxmemory 时频繁触发。如果 maxmemory 是 0（默认值），或者设为机器总内存的 90%，LFU 的淘汰逻辑几乎不执行，实际退化成 noeviction 或随机行为。
正确做法：
- 物理内存 16GB 的实例，
maxmemory建议设为 10～12GB，留出至少 20% 给复制缓冲区、AOF rewrite、系统开销 - 必须配合
maxmemory-samples 10（默认值），不建议调高；LFU 本身采样逻辑比 LRU 更重，盲目加大样本数反而增加 CPU 开销 - 运行时验证：
INFO memory查看used_memory和maxmemory是否接近，INFO stats看evicted_keys是否持续增长
为什么高并发下 LFU 比 LRU 更容易“卡住”热点
LRU 的近似实现靠随机采样 + 时间戳比较，单次操作成本低；LFU 要维护每个 key 的访问频次、做对数增长、定时衰减，CPU 和内存压力都更高。在 QPS 过万、key 数千万的场景下，容易出现：
- 大量 key 的计数器挤在同一个对数值（比如都是 255），导致淘汰时无法区分真实热度
-
lfu-decay-time触发时，后台线程集中衰减，引发短暂延迟毛刺 - 客户端频繁
GET同一个 key，但 Redis 没来得及更新计数器，造成“假冷门”被误删
这不是配置错误，而是 LFU 的固有代价。真正需要 LFU 的场景，是那些有明显长尾分布、且能容忍毫秒级波动的业务——比如商品详情页缓存，而不是秒杀库存这类强一致性要求的路径。
