没有被废弃。lru在redis 4.0后仍为默认策略之一，6.x、7.x持续优化；lfu是新增而非替代选项；lru候选池采样逻辑微调但未重构，maxmemory-samples默认值从5升至10再优化分布；lru字段仍为24位，精度受限于194天周期与毫秒级取模，扩展会显著增加内存开销与降低缓存效率。
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 开销线性上升。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
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 缓存行局部性。这不是技术不能，而是权衡后主动不为。
