redis集群不负责过期管理，各节点独立清理；需调高hz（建议100）和active-expire-effort（建议10），并排查被动删除盲区、验证多节点清理效果，注意系统定时器精度与cpu争抢问题。

Redis集群里过期Key不自动删干净？别怪集群，先看单节点配置

Redis集群本身不管理过期逻辑，每个节点独立执行过期清理。所谓“集群没删Key”，八成是某个分片（shard）上 hz 太低、或 active-expire-effort 不够，导致后台扫描太懒散。

默认 hz 10 意味着每秒最多做10次过期扫描，每次只检查少量样本（默认20个key）。如果过期Key密集、QPS又高，很容易积压——你看到的“大量过期Key残留”，其实是还没轮到它被扫描到。

• hz 建议调到 100（上限），但注意：值越高，CPU占用越明显，尤其在小内存/高负载节点上可能引发抖动
• 必须在每个集群节点的 redis.conf 里改，改完 redis-cli -p <port> config rewrite</port> 或重启生效
• 别只调 hz，顺手把 active-expire-effort 10（默认1）也加上，它控制每次扫描时检查的数据库数量，对多DB场景更关键

为什么改了hz还是有Key没删？检查是否命中“被动删除”盲区

Redis过期靠两套机制：主动扫描（hz驱动） + 被动删除（访问时触发）。集群环境下，被动删除容易失效——比如某个Key过期了，但没人再查它，又没被主动扫到，就一直挂着。

常见盲区场景：

Redis Skill - 高性能缓存管理

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

下载

• 业务用 SCAN 遍历key，但跳过了已过期key（Redis 7+才默认在SCAN中过滤过期key；老版本会返回，但GET返回nil）
• 使用了 keys * 这种阻塞命令，它不触发过期检查，且在集群里根本不能用（报 CROSSSLOT 错误）
• 客户端缓存了key存在性判断（比如先 EXISTS 再 GET），而 EXISTS 在key过期瞬间仍返回1，导致后续逻辑跳过清理

集群模式下如何安全验证过期Key清理效果？

不能只看单个节点的 INFO keyspace，因为key分布不均。得逐节点确认，且避开slot迁移干扰。

• 用 redis-cli -c -h <host> -p <port> info keyspace</port></host> 分别查每个master节点，重点看 db0:keys=100,expires=5 这类字段里的 expires 数是否持续下降
• 临时启用 redis-cli --stat 观察 expired_keys 计数器每秒增量，比肉眼看INFO更灵敏
• 避免在slot迁移期间测——迁移中节点会暂停主动过期任务，INFO stats 里 expired_keys 可能停涨

hz调太高反而卡住？留意Linux定时器精度和CPU争抢

hz 100 看似合理，但在某些云主机或容器环境里，系统级定时器精度不足（比如 CLOCK_MONOTONIC 实际分辨率只有10ms），会导致Redis频繁忙等，反吞CPU。

• 用 cat /proc/sys/kernel/timer_migration 查是否禁用timer migration（应为0）；cat /proc/timer_list | head -20 看当前jiffies精度
• 观察 INFO cpu 中 used_cpu_sys 是否异常飙升，若 > 0.8（单核）且伴随延迟毛刺，大概率是 hz 和系统调度打架
• 保守方案：先设 hz 50 + active-expire-effort 5，再根据 expired_keys 每秒处理量微调

真正难搞的是那种写入后立刻过期、又几乎不读的key——它完全依赖主动扫描。这时候光调参数不够，得从源头控制：比如用 PEXPIREAT 替代 EXPIRE 避免时钟漂移误差，或者干脆用 Stream + 消费者TTL替代短时缓存。