短结论：不会因为惰性删除而"堆积无穷多的过期 key"，但会造成两类隐患，需要重点关注。
核心原因是：
即使 Redis（或华为云分布式 Redis）采用 惰性删除 + 定期删除 ，真正过期的 key 最终都会被逐步清理掉，不会无限堆积，但中间阶段可能导致：
- 瞬时过期 key 堆积 → 内存升高（但不会无限）
- 若定期删除力度不足 → 到达 maxmemory 后开始大量淘汰 → 影响业务性能
🔍 一、原理分析：惰性删除会不会导致"过期堆积"？
Redis 处理过期 key 有两个机制：
1）惰性删除（Lazy Expire）
只有当：
- 访问该 key（GET/SET/DEL/HGET/EXISTS...）
系统才发现该 key 已过期并立即删除。
👉 意味着 长期不访问的 key，如果过期了不会立即删除，会残留在内存中。
2）定期删除（Active Expire Cycle）
Redis 会每秒多次扫描少量 key 的 TTL 桶：
- 按随机 + 分桶抽样策略扫描
- 每次扫描最多 25% 的 key 被判定为过期
👉 若过期 key 特别多，可能清理不过来，会有短暂堆积。
📌 所以最终结论是：
✔ 不会无限堆积
因为 Redis 持续在后台清理，并且你一旦访问它，它也会立即删掉。
✔ 但会有"短期堆积"（典型现象：内存只涨不跌）
尤其是以下场景：
- TTL 数量非常大（千万级）
- 导入大量带 TTL 的 key（日志、session、缓存等）
- 某些 key 从不访问（惰性删除无法触发）
- 应用大量写入新 key → Redis 来不及清理旧 key
→ 你会看到"过期 key 越来越多"、"内存升高但 key 已过期"这样的现象。
这不是泄漏，只是清理速度慢。
🧪 二、那华为云分布式 Redis，会更严重吗？
分布式 Redis（企业级）基本上都是强制开启惰性删除机制。
✔ 它不会导致无限堆积
✔ 但会导致"GC 不及时，短时堆积"
华为云官方也会建议：
大量带 TTL 的 key，TTL 不能太集中 。
否则某个时间段会暴涨内存。
⚠ 三、会导致哪些实际生产问题？
① 内存上涨，但 key 明明已经过期
（惰性删除 + 定期删除力度不够）
② 内存逼近 maxmemory → 大量 key 被淘汰 → 业务抖动
③ AOF/RDB 文件远大于实际存储数据量
因为文件中包含所有 key，包括过期但尚未删除的
④ 集群迁移、重平衡会变慢
因为它要迁移"看上去未过期但实际上已经过期"的 key
🛠 四、如何避免"过期堆积"问题？（工程可落地）
以下是大规模 TTL 应用（百万到亿级）的最佳实践：
✔ 1. 打散 TTL，随机加偏移
避免大量 key 同一时间过期。
SET key value EX 86400 + random(0,300)✔ 2. 开启更强的定期删除力度（重要）
Redis 自己：
activerehashing yes
hz 50（默认 10）华为云：
- 提工单可要求 提高 Active Expire 删除频率
- 一些实例类型提供激进 GC 模式
✔ 3. 使用更适合 TTL 的数据结构：带过期 SortedSet 统一管理
如果你的 TTL key 数量巨大（> 1000 万），推荐使用：
ZADD expire_zset key然后 worker 定时批量清除。
可以避免 Redis 过期处理瓶颈。
✔ 4. 如果需要强一致性删除：使用 Keyspace Notification 订阅事件
虽然 Redis 不保证 100% 事件可靠，但在华为云可以搭配 Stream 缓存，满足大部分场景。
🧭 五、什么时候会真的"堆积到影响业务"？
下面 3 个条件同时发生：
- 你每秒写入大量带 TTL 的 key（>10k/s）
- 每个 key TTL 都很短（例如 30 秒、60 秒）
- key 从不被回读（惰性删除无法触发）
这种情况非常常见于：
- 短期缓存
- 任务队列
- 瞬时 token
- 高频日志写入
→ 这个场景一定会出现堆积现象（但不是无限堆积）
只要你观察 Redis 内存曲线就能看到。
📌 最终给你的总结建议（工程落地方案）
如果你担心过期 key 堆积（你们是分布式 Redis，不好自己调 config），我建议：
🌟（必做）1. 打散 TTL（强烈推荐）
业务代码层面改一下最简单，也最有效。
🌟（看数据量）2. 如果 key 数量 > 1000 万，建议换批量过期设计划 ZSET 管理
避免把过期压力交给 Redis 内部 expire 机制。
🌟（可选）3. 找华为云支持要求提高 Active Expire 清理力度
企业分布式 Redis 都可以调。