调高hz能加快过期键清理，因其提升redis每秒扫描过期key的频率，单位时间内检查更多slot，更快摘除已过期key；但仅加速扫描，不解决集中过期或内存碎片问题。

调高 hz 是最直接有效的手段，但不是万能解药——它只加速“扫描”，不解决“集中过期”或“内存碎片”问题。

为什么改 hz 能让过期键删得更快？

Redis 的定期删除不是全量扫库，而是靠 serverCron() 每秒触发 hz 次，每次调用 activeExpireCycle() 随机抽查部分带过期时间的 key。默认 hz 10 意味着每 100ms 扫一次，每次最多检查 20 个 key（每个 db 抽样 20 个 slot），在百万级过期 key 场景下，清理速度远跟不上过期速度。

• hz 100 将扫描间隔压缩到 10ms，单位时间内检查的 key 总量提升约 10 倍，显著提高过期 key 被抽中并摘除的概率
• 但注意：activeExpireCycle() 单次执行有 25ms 时间上限，且当抽样中超过 25% 过期时会重试——这意味着 hz 越高，重试越频繁，CPU 开销非线性增长
• 实测数据：在 50w 集中过期 key 场景下，hz 10 下内存回落需 8 分钟；hz 100 可压至 45 秒内（前提是无严重内存碎片）

哪些情况改了 hz 也没用？

盲目调高 hz 可能白忙活，甚至引发新问题。先确认这三件事：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 查 INFO stats 中的 expired_keys 是否持续增长 —— 若长期为 0，说明根本没触发过期逻辑，hz 再大也无效
• 确认 maxmemory 已启用且 used_memory 接近阈值 —— 内存充足时 Redis 不会主动淘汰，hz 对释放无影响
• 看 INFO memory 的 mem_fragmentation_ratio —— 若 >1.5 且 used_memory_rss 远高于 used_memory，说明是内存碎片卡住释放，此时调 hz 反而加重分配压力

生产环境怎么安全调 hz？

别直接改配置重启，先热更新验证效果：

• 临时生效：CONFIG SET hz 100（立即生效，重启失效）
• 观察 5 分钟：redis-cli info stats | grep expired_keys 看增量是否明显加快；同时盯紧 instantaneous_ops_per_sec，若下跌超 15%，说明 CPU 已被抢占
• 有效且稳定后，再写入 redis.conf 并执行 CONFIG REWRITE 持久化；否则立刻回退：CONFIG SET hz 10
• 集群模式下必须逐节点操作 —— CONFIG GET/SET 不跨节点同步，也不能批量执行

真正卡住释放的，往往不是 hz 太低

如果业务侧批量写入大量 EXPIREAT 时间戳高度集中的 key（比如整点统一设 1 小时 TTL），哪怕 hz 1000 也救不了——后台扫描再快，也赶不上那一秒涌进来的过期洪峰。

这种场景必须从上游控制：给 TTL 加随机扰动，例如 3600 + ThreadLocalRandom.current().nextInt(600)，把 1 小时 ±10 分钟的过期窗口打散。否则再调 hz，也只是在给一个注定堵死的管道加压。