Redis内存未立即下降是因为采用惰性+定期双机制清理过期key，定期清理受hz参数控制；hz越大扫描越频繁但CPU开销越高，默认10，调至100可加速清理，超100收益递减且可能引发高CPU。
为什么DEL或EXPIRE后内存没立刻下降
Redis 的内存释放不是即时同步的，尤其在大量 key 过期或被删除时，used_memory 可能长时间不回落。这不是内存泄漏，而是因为 Redis 采用惰性+定期双机制清理过期 key：惰性清理只在访问 key 时检查过期，而定期清理由后台周期任务执行，其频率受 hz 参数控制。
hz 参数如何影响过期键扫描速度
hz 决定了 Redis 每秒执行多少次定时任务（默认 10），包括过期 key 扫描、LRU/LFU 淘汰候选池更新、AOF 缓冲刷写等。值越大，扫描越频繁，过期 key 被及时发现并释放的概率越高；但也会增加 CPU 占用，尤其在高负载实例中可能挤占命令处理时间。
- 默认
hz 10：每 100ms 做一次扫描，每次最多检查 20 个数据库中的 key，且每个库只随机抽样 20 个 key —— 在大实例（如 100w+ 过期 key）下，清理严重滞后 - 调高到
hz 100：扫描间隔缩短至 10ms，抽样频次和总量显著提升，能更快触达待淘汰 key - 但注意：
hz不是线性加速器 —— 超过 100 后收益递减，且可能使redis-server进程 CPU 使用率持续高于 30%
调整 hz 前必须确认的三件事
盲目调高 hz 可能引发新问题，需先验证当前瓶颈是否真出在过期扫描上：
- 先查
INFO stats中的expired_keys和evicted_keys是否持续增长，若两者长期为 0，说明根本没触发淘汰逻辑，调hz无意义 - 确认
maxmemory已启用且接近上限 —— 若内存充足，Redis 根本不会主动驱逐，hz对淘汰无影响 - 检查
INFO memory中的mem_fragmentation_ratio，若 >1.5 且used_memory_rss远高于used_memory，说明内存碎片严重，此时调hz不解决释放缓慢，反而加重碎片分配压力
生产环境调整 hz 的安全操作方式
不建议直接修改配置文件重启，应先热更新验证效果：
- 临时生效（立即生效，重启后失效）：
CONFIG SET hz 100 - 观察 5 分钟内
INFO stats中expired_keys的增量速率是否明显加快，同时监控instantaneous_ops_per_sec是否下跌超过 15% - 若有效且无副作用，再写入
redis.conf并CONFIG REWRITE持久化；否则回退：CONFIG SET hz 10 - 特别注意：集群模式下，每个节点需单独设置，
hz不同步，也不能通过CONFIG GET/SET跨节点批量操作
真正卡住内存释放的，往往不是 hz 太低，而是 key 设计不合理（比如批量写入百万级 EXPIREAT 时间戳相近的 key）—— 这种集中过期风暴，再高的 hz 也救不了，得从上游控制过期时间离散化。
