redis 7.0未重构淘汰算法，而是通过精准内存统计、渐进式驱逐节奏和减少锁竞争降低延迟抖动；旧版因同步阻塞驱逐导致写入卡顿，新版改用采样与分步删除实现稳定回收。
Redis 7.0 并未重构淘汰（eviction）算法本身，而是通过更精细的内存统计、更可控的驱逐节奏和更少的锁竞争，显著降低了 maxmemory 触发时的写入延迟抖动。
为什么旧版淘汰会卡写入？
在 Redis 6.x 及之前，当 used_memory 接近 maxmemory 时，每次写入命令都可能触发“同步驱逐”：Redis 必须在当前主线程中立即扫描、评估、删除若干 key，直到内存回落到安全水位。这个过程是阻塞的，且扫描开销不可预测——尤其遇到大 Hash 或 Sorted Set 时，单次 SET 可能延迟飙升至百毫秒级。
常见现象包括：
-
instantaneous_ops_per_sec突然跌落，latency_percentiles_usec第 99 分位跳变明显 -
evicted_keys在INFO stats中持续增长，但used_memory波动剧烈 - 日志中频繁出现
Evicting keys...（仅限 debug 日志级别）
maxmemory-policy 的实际执行节奏变了
Redis 7.0 引入了 eviction-samples 和 eviction-step 两个隐式调控参数（不暴露在配置文件中，由源码逻辑控制），让驱逐行为从“贪心扫光”转向“渐进释放”：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每次写入触发驱逐时，只采样固定数量（如 16 个）候选 key，而非全库遍历
- 每轮最多删除
eviction-step（通常为 1）个 key，避免单次操作耗时过长 - 若一轮后仍超限，下一次写入再继续，把压力摊薄到多个请求周期
这使得 allkeys-lru 或 volatile-lfu 等策略在高负载下不再“一锤定音”，而是形成稳定、可预期的内存回收节奏。
内存统计更准，驱逐更“省力”
旧版 Redis 的 used_memory 是估算值，尤其在 jemalloc 分配器下容易虚高；而 Redis 7.0 借助 jemalloc 5.3+ 的 mallctl 接口，直接读取真实分配字节数，并将 allocator_frag_ratio 纳入驱逐决策参考：
- 当
mem_fragmentation_ratio > 2.0且used_memory接近上限时，优先触发MEMORY DEFRAG而非盲目删 key -
INFO memory中新增used_memory_dataset字段，排除元数据开销，让淘汰策略真正作用于“有效数据” - 避免因碎片误判导致的过度驱逐——你删掉的 key，很可能本就不该占那么多内存
真正要注意的不是“怎么配”，而是“怎么观察”
新版驱逐机制是否生效，不能只看 evicted_keys 是否增长，而要交叉验证：
- 用
redis-cli INFO stats | grep -E "(evicted|expired)_keys"对比两者增速：若expired_keys远高于evicted_keys，说明过期键清理足够及时，驱逐压力小 - 检查
latency_percentiles_usec的 P99 和 P999：7.0 下这两项在内存临界点应保持平滑，突刺减少 60% 以上 - 运行
redis-cli --bigkeys --memkeys 100后关注key_size_avg：平均键大小 > 1KB 时，即使总 key 数不多，驱逐开销仍可能超标
最易被忽略的一点：Redis 7.0 的驱逐优化高度依赖 jemalloc —— 如果你用的是系统默认 malloc 或未启用 jemalloc-bg-thread，那上面所有改进几乎归零。
