redis 6.2 修复了 lfu 计数器高并发溢出缺陷，使 allkeys-lfu 和 volatile-lfu 策略回归预期；旧版因非原子递增导致计数截断归零，高频 key 被误淘汰；6.2 仅增加 counter

Redis 6.2 并没有“优化淘汰逻辑”本身，而是修复了 LFU 计数器在高并发下的溢出缺陷——它让 LFUIncrAndReturn 函数真正可靠，从而让 allkeys-lfu 和 volatile-lfu 策略的淘汰结果回归预期。

为什么 LFU 淘汰在 6.2 之前经常“不准”

LFU 的核心是靠每个 key 的访问频次做淘汰决策，但 Redis 把这个频次存在 robj.lru 字段的低 6 bit 里，最大只能存 0–63。问题出在旧版 LFUIncrAndReturn 函数：它读取当前 counter、+1、再写回，全程非原子。多个请求同时命中同一个 key 时，可能都读到 62，各自 +1 后全写成 63；更糟的是，其中一个写完 63 后，另一个仍基于旧值 62 继续递增，导致写入 64 → 实际存为 0（高位截断）。于是高频 key 的计数突然归零，被误判为冷数据提前淘汰。

这种现象在缓存热点集中、QPS 高的场景下非常明显，比如秒杀商品详情页反复查同一个 key，OBJECT FREQ 返回值跳变，allkeys-lfu 淘汰顺序混乱。

LFUIncrAndReturn 补丁只加了一行判断

6.2 的修复极其轻量，就是在递增前加了显式上限检查：

Redis Skill - 高性能缓存管理

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

下载

if (counter <p>这行 <code>if (counter  是关键：它确保即使多个线程/协程并发读到同一值，也不会越过 63。后续的随机概率递增（<code>rand() % (counter + 1) == 0</code>）逻辑完全保留，衰减机制、对数计数器设计、<code>lfu_log_factor</code> 参数行为全部不变。</code></p><p>注意：这不是用原子操作替代，因为 Redis 主线程仍是单线程，但 <code>LFUIncrAndReturn</code> 可能被主线程（如 <code>lookupKeyRead</code>）和后台 bio 线程（执行 <code>LFUDecrAndReturn</code> 衰减）同时调用，属于跨线程竞争，而非多核争抢。</p><h3>选 <code>lfu</code> 策略时必须配 <code>lfu-log-factor</code>
</h3><p>修复计数器溢出只是让 LFU “不崩”，不代表它自动变准。默认 <code>lfu-log-factor 10</code> 对大多数业务偏激进——低频 key 很快涨到 10，之后增长极慢；而真实热点可能需要更高敏感度。你得根据实际访问分布调：<br>
- <code>lfu-log-factor 1</code>：接近线性计数，适合区分细粒度频次（如 5 次 vs 12 次）<br>
- <code>lfu-log-factor 100</code>：极度平滑，只保留“绝对热”和“绝对冷”的区分<br>
- 查看效果：用 <code>OBJECT FREQ key</code> 观察一段时间内数值变化节奏，别只看最终值</p><p>另外，<code>allkeys-lfu</code> 和 <code>volatile-lfu</code> 的区别不在算法，而在候选集：前者扫所有 key，后者只扫带 <code>EXPIRE</code> 的 key。如果你的 key 大部分没设过期时间，选 <code>volatile-lfu</code> 基本无效。</p><p>真正容易被忽略的点是：LFU 的“频率”不是绝对次数，而是带时间衰减的概率计数。哪怕修复了溢出，刚写入的 key 和持续被访问一周的 key，<code>OBJECT FREQ</code> 返回值也可能一样——因为衰减会抹平时间差。要验证 LFU 是否按你预期工作，得用稳定流量压测至少一个衰减周期（默认 1 分钟），而不是看单次命令返回值。</p>