Redis作为主流内存数据库，依赖一组后台定期任务来完成过期键清理、哈希表重哈希、客户端超时检查等工作。这些任务的触发节奏由配置项hz控制，传统模式下hz是一个固定值，无法顺应业务流量波动。dynamic-hz的出现改变了这一点，它让Redis能依据当前连接的客户端规模，自行微调实际运行的定期任务频率。
一、什么是Redis的定期任务与hz参数
Redis服务器在事件循环中会周期性调用serverCron函数，这个函数负责执行多种维护性质的后台工作。具体包括主动淘汰即将过期的键值、对渐变式重哈希的字典推进、检查并关闭空闲客户端、更新统计信息等。这些工作的执行间隔并不是随意的，而是由hz参数决定，hz表示每秒serverCron被调用的基准次数。
在默认配置中hz设为10，意味着每秒尝试执行10次定期任务，每次执行会按比例处理一定量的键。如果hz调大，任务更频繁，过期数据清理更及时，但CPU占用也会上升；如果hz调小，则节省算力却可能积累过期键。对于访问量起伏明显的业务，固定hz很难同时兼顾效率和成本，这正是dynamic-hz要解决的问题。
二、dynamic-hz的工作机制
dynamic-hz是Redis从5.0版本开始提供的特性，当配置dynamic-hz yes开启后，Redis不再机械地使用静态hz值，而是以hz作为下限，根据connected_clients的数量动态提升实际频率。其计算逻辑大致为：当客户端数超过一定阈值，系统会将有效的hz按倍数放大，使得serverCron调用更密，后台任务吞吐量随之提高。
举例来说，若hz配置为10，且当前有数百个活跃连接，Redis可能将实际执行频率提升到20甚至更高，但不会无限制增长，内部有保护上限以避免过度消耗资源。当流量回落、客户端断开，频率又慢慢回归到基准hz。这种伸缩不需要人工干预，也不会引起服务重启，对线上业务完全透明。
三、如何开启与配置dynamic-hz
在redis.conf中可以通过两行配置控制该特性：
- dynamic-hz yes：启用动态调整功能。
- hz 10：设定基础频率，dynamic-hz以此为锚点做上下浮动。
若使用命令行临时调整，可执行CONFIG SET dynamic-hz yes以及CONFIG SET hz 10，改动立即生效但重启后丢失。生产环境建议写在配置文件里并配合监控，观察client连接数与CPU使用率的变化曲线，确认动态提升幅度符合预期。
需要注意的是，dynamic-hz仅影响serverCron类任务节奏，不改动命令执行线程模型，也不会让单条命令变快。它解决的是后台维护任务与前端负载不匹配的问题，因此更适合客户端数量波动大、过期键多的场景，比如秒杀活动前后的缓存层。
四、dynamic-hz带来的收益与边界
开启dynamic-hz后，最直观的好处是闲时省CPU、忙时少堆积。在没有请求的时候，Redis以基准hz运行，后台清理温和；当海量连接涌入，频率自动加大，过期键被更及时清除，哈希表重哈希推进更快，从而降低内存碎片与响应延迟。
不过它并非万能。如果实例本身CPU已经饱和，调高频率只会雪上加霜；若业务是少量长连接且流量平稳，dynamic-hz几乎不会触发上调，和关掉没差别。下表列出典型场景下建议：
| 业务特征 | 是否建议开启dynamic-hz | 说明 |
|---|---|---|
| 客户端数日内波动大 | 建议开启 | 能随峰谷自动调节后台任务 |
| 长连接且负载恒定 | 可不开启 | 动态调整空间小，收益低 |
| CPU已持续高位 | 不建议开启 | 避免频率上调加剧争抢 |
五、实践观察与调优建议
从社区实测看，电商大促期间开启dynamic-hz的集群，其过期键平均残留时间比固定hz实例缩短约三成，而日常时段的CPU占用基本持平。这说明该功能确实在需要的时候才多干活，不会全天候蛮干。运维上建议把hz设在10到20之间，既留足动态上浮余地，也防止基准过高。
另外，可借助INFO stats中的expired_stale_percentage与latest_fork_usec等指标侧面判断动态调整效果。若发现过期键清理始终滞后，可适当抬升hz基准；若CPU无故走高，则检查是否有异常连接数膨胀导致频率被推满。通过这类闭环观察，能让Redis在各类负载下都保持从容。
Redisdynamic-hz定期任务频率修改时间：2026-08-11 22:45:34