Redis 5.0 的 dynamic-hz 是一个自动调节 hz 值的开关，空闲时将 hz 降至 1，繁忙时恢复配置值（如 100），仅依据主线程调度空闲状态判断，并非感知业务负载的智能调频机制。
Redis 5.0 的 dynamic-hz 是什么，它真能自动调频？
不能。Redis 5.0 引入的 dynamic-hz 是一个开关，不是全自动调速器——它只是让 Redis 在空闲时把 hz 值动态降到 1，忙时再恢复配置值（如 100）。它不感知业务负载或过期键密度，只看服务器是否“空闲”（即最近一次 serverCron 执行后，主线程是否长时间没被调度）。所以别指望它解决大批量 key 同时过期的问题，那是设计层面要规避的。
怎么开启并验证 dynamic-hz 生效？
在 redis.conf 中设置：
dynamic-hz yes
然后重启或热重载配置：redis-cli config rewrite。验证方式不是查 config，而是观察 INFO 输出：
执行 redis-cli info stats | grep hz，你会看到类似：
configured_hz:100 current_hz:100
如果当前空闲，current_hz 可能降为 1；一旦有请求涌入、定时任务变频繁，它会快速回升。注意：这个值每秒最多变化一次，且仅当 dynamic-hz 为 yes 且 hz 配置值 > 1 时才启用。
hz 设太高，dynamic-hz 也救不了你
即使开了 dynamic-hz，若你把 hz 配成 500，空闲时虽能回落到 1，但只要稍有压力，current_hz 就会猛冲到 500，导致每秒扫描次数爆炸。这会直接引发两个后果：
- 每次
activeExpireCycle清理任务的timelimit会缩到极小（公式是1000000 * 25% / hz / 100），比如hz=500时单次上限仅 5ms，但扫描更频繁，CPU cache miss 增多，实际开销反而更高 - 大量随机采样（每次 20 key）叠加高频率，容易触发「过期键占比 > 25% → 重扫」的循环，在 key 密集过期时段放大卡顿
- Linux 调度器可能因 Redis 线程太“活跃”而降低其优先级，反而影响响应稳定性
所以生产环境仍建议把基础 hz 控制在 100–200，再开 dynamic-hz，才能让空闲节能、忙时够用。
真正影响过期清理效果的，其实是这三件事
dynamic-hz 只管频率调度，但清理效率取决于：
-
maxmemory-policy是否匹配场景：如果内存根本没打满，allkeys-lru根本不触发，过期键全靠activeExpireCycle清，此时hz和随机采样逻辑才是关键 - 过期时间是否做了随机偏移：哪怕
hz=200，若 10 万个订单 key 全设成EXPIREAT 1734718440（同一秒），照样会连续几十轮重扫，dynamic-hz切到 1 也无济于事 - 碎片率（
mem_fragmentation_ratio）是否过高：碎片大时，即使删了 key，RSS 也不降，看起来“内存没回收”，误以为是过期没清——其实清理早完成了，只是内存分配器没合并空闲块
动态 HZ 是锦上添花，不是雪中送炭。它缓解的是“长期低负载下无谓 CPU 消耗”，而不是“突发过期风暴”。后者得靠业务层控制 TTL 分布，这是最不可绕过的环节。
