Redis主线程对CPU频率敏感，必须设为performance策略以锁死最高基础频率，消除动态调频导致的P99延迟毛刺；ondemand/conservative会因升频滞后放大AOF重写或BGSAVE时的抖动，powersave严禁使用。
Redis 主线程对 CPU 频率敏感，尤其在高吞吐、低延迟场景下，Linux 默认的 ondemand 或 conservative 调频策略会在负载突增时滞后升频，导致单次命令处理时间拉长（比如从 50μs 涨到 300μs），叠加 AOF 重写或 BGSAVE 的子进程竞争，抖动会明显放大。这不是 Redis 配置能解决的问题，必须从内核调度层干预。
为什么 scaling_governor 会影响 Redis 延迟稳定性
Redis 单线程模型依赖稳定、可预期的 CPU 执行周期。当 governor 动态降频（如空闲时切到 800MHz），再突然收到批量请求，CPU 需要数毫秒完成频率爬升——这段时间内事件循环卡顿，redis-server 进程实际运行时间被压缩，表现为 P99 延迟毛刺、客户端超时增多。AOF 重写期间父进程持续拷贝命令到重写缓冲区，对 CPU 周期连续性要求更高，此时频率切换的代价会被成倍放大。
应设为 performance 还是 powersave
生产环境 Redis 实例必须设为 performance，这是唯一能保证全时可用最大主频的策略：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
performance：锁死当前 CPU 最高基础频率（不启用睿频也可），消除升频延迟；适用于 Redis 独占物理机或资源隔离明确的容器 -
powersave：强制最低频率，直接扼杀吞吐能力，严禁使用 -
ondemand/conservative：存在不可控升频延迟，实测在 4 核以上实例上会导致 10%+ 的 P99 延迟波动，不满足毫秒级 SLA
如何安全设置并验证生效
操作需分三步，缺一不可：
- 临时生效（验证用）：
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - 永久生效（推荐方式）：在
/etc/default/grub中修改GRUB_CMDLINE_LINUX，追加intel_idle.max_cstate=1 processor.max_cstate=1 cpupower frequency-set -g performance（Intel）或amd_pstate=passive（AMD），然后sudo update-grub && sudo reboot - 验证是否全局生效：
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort -u应只输出performance；再用cpupower frequency-info确认current policy和the governor "performance"同时存在
注意：若 Redis 运行在容器中，宿主机必须先完成上述设置，容器内无需重复；Kubernetes 环境需通过 initContainer 或节点初始化脚本统一配置，不能依赖 Pod 内部修改。
和 no-appendfsync-on-rewrite 的关系
两者作用域完全不同：no-appendfsync-on-rewrite 只控制父进程是否在 AOF 重写期间暂停落盘，对 CPU 频率无影响；而 scaling_governor 是操作系统级保障，确保无论是否在重写、BGSAVE 或高 QPS 下，CPU 都以稳定高频响应。前者治标（减少一次系统调用），后者治本（消除执行环境不确定性）。线上已出现过因仅开 no-appendfsync-on-rewrite 但未锁频，导致重写期间延迟仍突破 20ms 的案例。
