Redis 4.0引入LFU后LRU还更新吗

Redis 4.0引入LFU并非取代LRU，而是与其共存互补：LRU仍是默认且持续优化的核心淘汰策略，适用于时间局部性强的短周期缓存场景；其底层实现虽保留24位lru字段带来的194天时间戳回绕与毫秒级精度限制，但通过提升采样数（maxmemory-samples默认升至10）、优化分布均匀性等方式在精度与性能间做出精妙权衡——这并非技术停滞，而是Redis在亿级键规模下，为内存效率、CPU开销与缓存行局部性所作出的清醒取舍。

Redis 4.0之后LRU是否被废弃？

没有。LRU不仅没被废弃，allkeys-lru 和 volatile-lru 仍是默认策略之一，且在 6.x、7.x 中持续获得底层优化。LFU是新增选项，不是替代项。两者共存，适用场景不同：LRU更适合访问时间局部性强的短周期缓存（如会话、临时令牌），LFU更适合识别长期稳定热点（如商品详情页、配置中心主键）。

LRU候选池采样逻辑在新版本有无变化？

有调整，但非重构。核心仍是随机采样 + 比较 lru 字段值，不过从 Redis 5.0 开始，maxmemory-samples 的默认值从 5 提升为 10；Redis 7.0 进一步优化了采样分布均匀性，避免极端偏斜导致误淘汰。你仍可通过 CONFIG SET maxmemory-samples 15 手动调高，但注意：超过 20 后性能收益趋缓，而 CPU 开销线性上升。

LRU的时间戳精度还受限于 24 位 lru 字段吗？

是的，至今未变。每个 redisObject 的 lru 字段仍是 24 位，存储的是毫秒级时间戳对 2²⁴ 取模结果（约 194 天周期）。这意味着：

• 若两个 key 的访问间隔超过 194 天，它们的 lru 值可能“回绕”后无法正确比较先后
• 高频写入场景下（如每秒数万次访问），同一毫秒内多个操作共享相同 lru 值，排序依赖采样随机性
• 该设计是明确的取舍：用精度换空间和速度，Redis 宁可接受少量误判，也不愿为每个 key 额外分配 8 字节时间戳

为什么改不了 lru 字段长度？

因为牵一发而动全身。Redis 的 redisObject 是高频复用的核心结构体，其大小直接影响内存碎片率与缓存行利用率。当前 16 字节紧凑布局（含 type、encoding、lru、refcount、ptr）已高度优化。扩展 lru 到 32 或 64 位，会迫使整个结构体对齐到 24 或 32 字节，实测在亿级 key 场景下内存占用增加 8%–12%，且破坏 CPU 缓存行局部性。这不是技术不能，而是权衡后主动不为。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis 4.0引入LFU后LRU还更新吗》文章吧，也可关注golang学习网公众号了解相关技术文章。