调高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，也只是在给一个注定堵死的管道加压。
