maxmemory-samples影响cpu和淘汰速度，因其控制lru/lfu等策略的随机采样数量：值越大（如10）淘汰更准但cpu线性上升，值越小（如3）速度快却易误删热点；仅对采样型策略有效，设超15会显著抬升cpu负载。
为什么调 maxmemory-samples 会影响 CPU 和淘汰速度
因为 Redis 的 allkeys-lru、volatile-lfu 等策略不是全量扫描，而是每次从键空间里随机抽样若干个 key，再从中挑出最该淘汰的那个。抽样数就是 maxmemory-samples，默认是 5。值越大，选得越准（更接近理论 LRU/LFU），但每次淘汰前要检查更多 key，CPU 负载就越高；值太小，淘汰容易“误杀”热点数据，导致缓存命中率掉得快。
怎么设 maxmemory-samples 才不踩坑
没有通用最优值，得看你的业务特征和资源水位：
- 如果 Redis 常驻内存在
maxmemory * 0.85以下，压力不大，用默认5就够了 - 冷热分明、且缓存命中率明显偏低 → 可试
10，但必须同步监控used_cpu_sys和evicted_keys_per_sec - 写入突增、内存水位频繁触顶 → 先压到
3或4，快速释放空间，等峰值过去再调回来 - 千万别设成
15以上，实测在中高负载实例上，20会让redis-server单核 CPU 持续跑满
maxmemory-samples 对不同淘汰策略的实际影响
这个参数只对依赖抽样的策略起作用：
- 对
allkeys-lru、volatile-lru、allkeys-lfu、volatile-lfu、volatile-ttl有效 - 对
allkeys-random、volatile-random、noeviction完全无效——它们根本不采样 - 注意：
volatile-ttl虽然也采样，但它只查expires表，开销远小于 LRU/LFU，所以即使设到10，CPU 增长也不明显
如何验证调整是否生效
别只看配置值，要盯住两个指标：
- 运行
CONFIG GET maxmemory-samples确认已加载 - 用
INFO stats查evicted_keys和evicted_keys_per_sec：若调大后淘汰速率没升、但keyspace_hits明显增加，说明精度提升有收益 - 对比调整前后
latency doctor输出，重点关注eviction和command类延迟毛刺是否减少
真正难处理的从来不是参数本身，而是你没意识到：哪怕把 maxmemory-samples 设为 1，只要 maxmemory 被持续击穿，Redis 仍会在每次写入前执行 freeMemoryIfNeeded() —— 这个检查动作本身就有常量级开销。省 CPU 的本质，是让淘汰尽量不发生。
