redis清理过期数据依赖惰性删除（访问时检查）和定期删除（定时随机扫描）双机制，无需手动干预；flushall会无差别清空所有数据，破坏集群一致性且掩盖过期配置缺陷，不可用于清理过期键。
直接清空集群所有数据不是清理过期缓存，而是暴力重置；真正“清理过期数据”靠的是 Redis 自身的惰性+定期删除机制，你几乎不需要手动干预——除非内存持续上涨且 TTL 大量返回 -1（说明没设过期）或 used_memory_human 接近 maxmemory_human。
为什么不能用 FLUSHALL 清理“过期数据”
FLUSHALL 和 FLUSHDB 会无差别删除所有 key，不管是否过期、是否重要。在集群环境下，它还会触发跨节点同步阻塞，导致短暂不可用。更关键的是：它根本没解决“过期键未释放”的问题——那些已过期但尚未被访问或扫描到的 key，本来就能被自动回收，删了反而掩盖了配置缺陷（比如漏设 EXPIRE）。
- 集群中执行
FLUSHALL需要对每个 master 节点单独调用，redis-cli --cluster不支持该命令 - 若使用
redis-cli -c连接集群，输入FLUSHALL会被路由到某个哈希槽所在节点，仅清空该节点数据，造成不一致 - 生产环境误操作后无法回滚，
RDB/AOF若未开启或延迟写入，数据彻底丢失
检查过期键堆积的真实信号
先确认是不是真有过期键堆积，而不是业务缓存本身增长过快。连任一 master 节点执行：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -h node1 -p 7001 INFO memory | grep -E "(used_memory_human|maxmemory_human|mem_fragmentation_ratio)"
再查过期键规模：
redis-cli -h node1 -p 7001 INFO stats | grep expired_keys
-
expired_keys累计值持续上升 → 定期删除正常工作 -
expired_keys停滞不动，但used_memory_human持续涨 → 可能大量 key 未设过期时间，或hz参数过低（默认 10），建议调至 20～50（需重启） -
mem_fragmentation_ratio > 1.5且内存不降 → 可能存在大 Key 未释放，用redis-cli --bigkeys定位
集群下真正有效的“清理”动作
Redis 集群本身不改变过期策略逻辑，但你要在每个 master 节点上分别验证和调优：
- 确保所有节点开启了主动过期：
redis-cli -h node1 -p 7001 CONFIG GET active-expire-effort（默认 1，可设为 2 或 3 加速扫描） - 检查
hz设置：CONFIG GET hz，若长期低于 10，且 CPU 有余量，可CONFIG SET hz 25（无需重启，立即生效） - 避免在集群中用
KEYS *扫描全量 key —— 会阻塞单节点，改用SCAN+UNLINK组合清理特定前缀（如temp:*），例如：redis-cli -h node1 -p 7001 --scan --pattern "temp:*" | xargs -r redis-cli -h node1 -p 7001 UNLINK
- 如果必须批量删过期相关 key，优先用
EXPIREAT或PEXPIREAT提前标记，再靠惰性删除自然释放，比事后补救更安全
最容易被忽略的配置点
集群节点的 maxmemory-policy 必须显式设置，不能依赖默认的 noeviction。一旦内存触顶，noeviction 会让写请求直接失败，而 volatile-lru 或 allkeys-lru 至少能保服务可用。这个策略不参与“过期清理”，但它决定了当过期键清理跟不上写入速度时，系统如何求生——而这恰恰是多数人等到 OOM 才意识到的问题。
