redis开启淘汰后cpu飙升大概率由maxmemory-samples过高、hz过大或过期key集中触发扫描所致；验证方法是观察evicted_keys是否在低峰期持续增长，再通过config set maxmemory-samples 3并监控cpu是否回落来确认因果关系。
Redis开启内存淘汰后CPU飙升，大概率不是淘汰逻辑本身出错，而是采样机制或清理节奏失控——maxmemory-samples设得太高、hz调得过猛、或大量Key集中过期触发高频扫描，三者任一都可能让CPU打满。
怎么确认是淘汰采样导致的CPU问题
别只看used_memory和maxmemory是否接近，那只能说明内存快满了，不能说明CPU高跟淘汰有关。关键要看淘汰行为是否在“无事生非”：
- 执行
redis-cli info stats | grep evicted_keys，如果该值在业务低峰期仍每秒增长几十甚至上百，说明淘汰太活跃 - 用
redis-cli --stat同时观察evicted_keys和instantaneous_ops_per_sec，若OPS没涨但evicted_keys猛增，基本可排除请求压力，锁定为淘汰驱动 - 临时执行
CONFIG SET maxmemory-samples 3，再用top -p $(pgrep redis-server)看CPU是否明显回落——这是最直接的因果验证
为什么调低maxmemory-samples能快速止血
maxmemory-samples控制Redis每次淘汰时随机采样的Key数量，默认是5。它不决定“淘汰谁”，只影响“找候选Key”的开销。采样数翻倍，扫描哈希桶+计算LFU/LRU得分的CPU消耗不是线性增长，而是近似平方级上升，尤其在大实例（100万+ keys）上更明显。
- 设为1：极省CPU，但淘汰精准度下降，可能误删较热的Key
- 设为3：生产环境通用安全值，90%以上场景下淘汰质量与CPU开销取得较好平衡
- 设为10或更高：仅在极少数对淘汰精准度要求极高、且CPU余量充足的离线分析场景才考虑
注意：CONFIG SET maxmemory-samples热生效，无需重启，改完立刻起效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
hz和lazyfree-lazy-expire必须配合调整
单纯压低采样数只能缓解表象；如果过期Key堆积严重（INFO keyspace里expires字段高达数十万），hz设得再低，定时任务仍要反复扫描——这时CPU高就不是淘汰的问题，而是过期清理卡住了。
- 先查
INFO cpu中used_cpu_sys是否同步飙升，再看INFO stats里expired_keys累计值是否远超业务写入量 -
CONFIG SET hz 100适合8核以上、QPS>5k的实例，但必须同步打开lazyfree-lazy-expire yes，否则大Key过期时仍会同步阻塞主线程 - 旧版本Redis（CONFIG SET hz，只能改
redis.conf并重启，这点容易被忽略
DEL大Key是隐形炸弹，UNLINK才是默认操作
很多团队在淘汰后手动补删残留Key，习惯性用DEL，结果发现CPU又飙了——这不是淘汰惹的祸，是DEL自己干的。对一个含50万成员的ZSET执行DEL，主线程会卡死几百毫秒，期间所有定时任务停摆，evicted_keys统计失真，CPU曲线还会出现尖刺。
- 用
MEMORY USAGE key或DEBUG OBJECT key确认Key体积，超过1MB就视为大Key - 一律改用
UNLINK key（Redis 4.0+），释放动作移交后台线程，主线程只做标记 - 批量清理时，避免
UNLINK *，改用SCAN分批+脚本调用UNLINK，防止后台线程积压
真正难处理的从来不是参数数字，而是过期Key分布是否均匀、大Key是否藏在业务逻辑深处、以及UNLINK之后后台线程的lazyfree_pending_objects指标是否持续积压——这些细节不盯住，调再多次hz也只是隔靴搔痒。
