Redis 7.2 未优化 LRU 算法，仍沿用 Redis 4.0 起的近似 LRU：24 位 LRU 时钟 + maxmemory-samples 随机采样；稳定性提升源于 IO 多线程、jemalloc 5.3+ 和集群路由优化等底层改进。
Redis 7.2 并没有“进一步优化 LRU 算法”——它沿用了 Redis 4.0 以来的近似 LRU 实现，核心逻辑仍是 maxmemory-samples 随机采样 + LRU 时钟计数器。所谓“稳定性提升”，实际来自底层基础设施增强，而非 LRU 本身算法变更。
Redis 7.2 的 LRU 行为和 Redis 4.0–7.0 完全一致
LRU 在 Redis 中始终是近似策略：每个 key 持有一个 24 位（Redis 7.2 起）的 LRU 时钟字段，访问时更新；淘汰时随机抽取 maxmemory-samples 个 key（默认 5），选其中时钟值最小者淘汰。这个机制在 Redis 4.0 就已定型，7.2 未改动算法逻辑或采样逻辑。
容易踩的坑：
- 误以为 7.2 引入了“更准的 LRU”——实际只是内存模型和 I/O 层优化让采样过程更稳定，不是算法升级
- 盲目调大
maxmemory-samples（如设为 200）：会显著增加淘汰阶段 CPU 开销，在高并发写入+驱逐场景下反而引发延迟毛刺
真正影响 LRU 稳定性的三个底层变化
7.2 的稳定性提升来自与 LRU 协同工作的系统级改进，而非算法本身：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
IO_THREAD_DO_READS默认启用：网络读取多线程化，避免单个大请求阻塞整个事件循环，使 LRU 时钟更新更及时、更均匀 - 内存分配器升级为
jemalloc 5.3+：减少因内存碎片导致的malloc延迟抖动，让采样和淘汰动作的执行时间更可预测 - 集群分片路由延迟降低 30%：跨槽请求不再频繁触发本地缓存失效，间接减少因重试/重定向引发的非预期 key 访问，削弱 LRU 时钟污染
高并发下 LRU 不稳的典型现象及 7.2 缓解方式
常见错误现象：INFO memory 显示 mem_not_counted_for_evict 突增、evicted_keys 波动剧烈、缓存命中率在流量高峰时段断崖下跌。
根本原因不是 LRU 失效，而是：
- 主线程被慢命令（如
HGETALL大哈希）长时间占用，导致大量 key 的 LRU 时钟无法及时刷新 - 客户端连接数激增，触发连接池竞争，部分请求排队等待，造成“伪冷数据”被误判为久未访问
- 旧版本中
replica-serve-stale-data yes配合主从延迟，从节点返回过期响应后又回写，干扰本地 LRU 时序
7.2 的缓解手段是工程层面的：
- 通过
client-output-buffer-limit更精细控制输出缓冲区，防止某客户端拖垮全局响应节奏 - 启用
replica-lazy-flush yes，避免从节点在同步间隙集中刷盘，干扰淘汰线程调度 -
MEMORY USAGE支持按前缀统计，能快速定位是否某类 key（如 session:*）异常膨胀，挤占 LRU 采样空间
真正要注意的，从来不是“LRU 变强了”，而是“在更高吞吐下，时钟更新、采样执行、内存回收这三个环节的抖动被压得更低了”。一旦业务出现缓存抖动，优先查 latency doctor 和 INFO clients，而不是怀疑 LRU 算法本身。
