开启maxmemory后cpu飙升主因是淘汰策略的采样逻辑持续运行，尤其maxmemory-samples设过大时，每次随机采样大量key进行lru/lfu评估，属纯cpu密集型操作。
为什么开启maxmemory后CPU反而飙升
Redis在配置了maxmemory并启用淘汰策略（如allkeys-lru）后，CPU使用率突然升高，不是因为内存满了才开始淘汰，而是**淘汰逻辑本身在持续运行**——尤其是当maxmemory-samples设得过大时，每次淘汰前都要随机采样大量key做近似LRU/LFU评估，这个过程是纯CPU密集型操作。
典型表现：即使内存使用率长期低于maxmemory阈值（比如只用了60%），只要写入/更新持续发生，Redis就会周期性触发淘汰检查；而默认maxmemory-samples是5，某些业务为“提高淘汰准确性”调到20甚至50，导致每轮采样耗时翻数倍，evictionPoolPopulate函数在perf top中占比陡增。
maxmemory-samples参数的实际影响
该参数控制Redis在执行近似淘汰时，每次从候选key池中随机采样的数量。它不改变淘汰结果的“最终正确性”，只影响决策速度与精度之间的权衡：
-
maxmemory-samples 1：极快，但淘汰可能“误杀”冷数据（精度低） -
maxmemory-samples 5：官方默认，平衡点，90%以上场景足够稳定 -
maxmemory-samples 20+：采样更“准”，但单次淘汰检查CPU开销可能增长3–5倍，尤其在key总数超百万时
注意：maxmemory-samples只对lru/lfu类策略生效，volatile-ttl等策略不依赖采样，不受影响。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何验证是否是samples导致的CPU问题
不能只看INFO memory里的maxmemory和used_memory，要抓实时淘汰行为：
- 执行
redis-cli info stats | grep evicted_keys，若该值在无明显内存压力时仍持续增长，说明淘汰过于活跃 - 用
redis-cli --stat观察evicted_keys和instantaneous_ops_per_sec是否强相关（比如OPS涨10%，evicted_keys涨30%） - 临时降低采样数：
CONFIG SET maxmemory-samples 3，观察top -p $(pgrep redis-server)中CPU是否回落——这是最直接的因果验证
如果降为3后CPU明显下降且淘汰仍可控，基本可锁定问题。
调低samples后的实际注意事项
调小maxmemory-samples不是“降级”，而是回归合理设计边界：
- 它不会导致内存溢出——淘汰机制仍存在，只是选key的策略更“粗糙”，但对绝大多数缓存场景，LRU近似效果差异微乎其微
- 避免设为1：极端低值可能让淘汰变成“随机驱逐”，失去缓存局部性优势
- 配合
maxmemory-policy一起看：若用的是noeviction，该参数完全无效；若用volatile-lru，采样只发生在带过期时间的key上，压力更小 - 线上调整后，建议用
SLOWLOG GET 10确认是否有新增慢命令——极低samples下极少引发慢日志，但需排除其他干扰
真正容易被忽略的点：很多人改完maxmemory-samples就以为万事大吉，却忘了持久化重写（AOF rewrite）或主从全量同步也可能在同一时段触发CPU尖峰，务必用INFO persistence和INFO replication交叉比对时间戳。
