hz参数主要影响过期key定期扫描、主动内存碎片整理、集群心跳检测及aof重写轮询频率；不影响惰性删除、命令处理与网络i/o，建议生产环境设为100–200并配合expireat错峰过期。

hz参数到底影响哪些后台任务

hz 控制 Redis 每秒执行定时任务的次数，默认是 10。它不直接影响命令处理、网络 I/O 或持久化主线程，但直接决定以下后台行为的响应节奏：

• 过期 key 的定期扫描（每次只检查部分 slot，不是全量）
• 主动内存碎片整理（activedefrag 开启时）
• 集群节点心跳检测与故障探测的调度粒度
• 某些版本中 AOF 重写触发条件的轮询频率（非核心，但有间接影响）

注意：hz 调高不会让「惰性删除」变快——客户端访问一个已过期 key 时仍会当场删掉，这部分逻辑完全独立。

设成多少才合理：看 CPU 资源和 key 过期模式

盲目设 hz 500 是最常见错误。上限虽为 500，但实际建议值严格受限于两个现实约束：

• 服务器 CPU 核心数 ≥ 8 且负载常年低于 40%：可设 hz 200，对过期集中场景（如批量 token 设置相同 TTL）效果明显
• CPU 核心数 ≤ 4 或存在其他高负载进程（如日志采集、监控 agent）：必须压到 hz 100，再高会导致 latest_fork_usec 显著上升，RDB fork 变慢甚至失败
• 若业务大量使用短生命周期 key（例如每秒写入数万、TTL ≤ 5s），hz 即使设到 200 也难根治内存峰值——这时应优先改用 EXPIREAT 错开过期时间，而非硬调 hz

验证是否生效，别只信 CONFIG GET hz，要观察 INFO stats 中的 expired_keys 增速是否更平滑，以及 mem_fragmentation_ratio 是否下降。

Redis Skill - 高性能缓存管理

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

下载

动态修改 vs 配置文件：哪些情况必须重启

CONFIG SET hz 100 在 Redis ≥ 5.0 上可热生效，但有三个硬限制：

• 集群模式下，该命令只作用于当前节点，其他节点需单独执行，不会自动同步
• 如果正在执行 BGSAVE 或 BGREWRITEAOF，新 hz 值要等当前后台任务结束才真正参与调度
• Redis 版本 redis.conf 并重启；而 8.2.3 版本虽支持，但 CVE-2025-62507 修复后对高频定时任务做了额外校验，不建议在未升级前贸然设 >100

生产环境推荐永久配置：在 redis.conf 中明确写 hz 100，避免因运维误操作或容器重建丢失设置。

比调 hz 更关键的协同动作

单靠 hz 是修修补补。真正压住内存峰值，得配合应用层控制：

• 用 EXPIREAT 替代 EXPIRE，把过期时间戳加随机偏移（如 unixtime + 10 + rand(0,5)），打散过期洪峰
• 对高频写入的临时数据（如风控 token），改用本地缓存（Caffeine）+ 分布式一致性校验，而不是全扔 Redis
• 开启 activedefrag yes 后，hz 实际也会影响碎片整理节奏——但此时更关键的是调 active-defrag-cycle-min 和 active-defrag-threshold-lower，而非无脑拉高 hz

最容易被忽略的一点：hz 调高后，若没同步加大 client-output-buffer-limit replica，主从同步大流量期间可能因缓冲区填满触发断连——因为更多定时任务挤占了网络线程调度窗口。