Redis 3.0 的 eviction pool 是一个固定长度为16的数组，用于淘汰前暂存采样键的近似空闲时间和键名，通过多轮随机采样、保序插入与top-K筛选，提升冷热识别鲁棒性，避免单次采样误驱逐热点key。
Redis 3.0 的 eviction pool 是什么
它不是链表，也不是哈希表，而是一个固定长度的 evictionPoolEntry 数组（默认大小为 16），用于在淘汰前暂存采样键的“近似空闲时间”和键名。这个池子不参与日常访问，只在触发内存淘汰时被重置、填充、排序。
为什么用池子而不是实时维护 LRU 链表
因为 Redis 是单线程，且每秒可能处理数十万次访问。若每次 GET 或 SET 都要调整全局访问顺序，会引发严重锁竞争和缓存行失效。池机制把开销从“每次访问”转移到“每次淘汰”，把高频低代价操作（采样）和低频高代价操作（排序+淘汰）解耦。
- 避免了为每个 key 维护双向链表指针带来的额外 16 字节内存开销
- 绕开了频繁内存移动导致的 CPU cache miss 问题
- 池子本身是栈式复用结构：每次淘汰后清空重填，无 GC 压力
池子如何降低优秀键被误驱逐的概率
关键在于“多轮采样 + 池内保序”。Redis 不只采一次样，而是在一次淘汰周期内，反复执行“随机选 maxmemory-samples 个 key → 计算 idle = server.lruclock - o->lru → 插入池中并保持 top-K 有序”这一过程，直到池满或达到最大尝试次数（EVICT_MAX_TRIES，默认 100 次）。
- 即使某次采样恰好漏掉热点 key，后续多次采样仍有机会把它捞进来
- 池子按
idle降序排列，但插入时只保留最大的 N 个值，相当于做了“滑动窗口最大值”过滤 - 真正被淘汰的，是池顶那个
idle最大的 key —— 它经过了最多轮次的“幸存考验”，比单次随机采样可靠得多
实际配置与调优注意点
maxmemory-samples 默认为 5，看似很小，但配合池的多轮填充逻辑，实际等效采样量远高于此。盲目调大它反而可能让池子过早收敛到局部极值，尤其在访问模式存在周期性倾斜时。
- 当缓存命中率突然下降且
evicted_keys指标激增，先检查是否因maxmemory-samples过小导致池无法覆盖真实冷热分布 - 调高该值（如设为 10）会增加单次淘汰的 CPU 时间，实测在 16 核实例上平均增加 8–12μs，需结合
INFO stats中的eviction_slow_log_entries判断是否引入瓶颈 - 池子大小不可运行时修改，它由编译期常量
EVPOOL_SIZE（=16）决定，硬编码在evict.c中
池机制的本质，是用可控的少量重复计算，换取对“最近未使用”这一模糊概念更鲁棒的逼近 —— 它不追求理论最优，只确保绝大多数情况下，那个刚被 GET 过三次的 key，不会在下一秒就消失。
