yd_282927746的论坛回复_云社区-华为云

先说结论：从库永远不会主动删除过期键，它只是"读到就当不存在"，真正的删除动作只发生在主库，然后以 DEL/UNLINK 命令同步给从库。一、主库怎么删过期键惰性删除：客户端访问某个 key 时，主库先检查 `expireIfNeeded`，过期了就删掉并返回 nil。定期删除：serverCron 里的 `activeExpireCycle` 每 100ms 跑一轮，从设置了 TTL 的字典里随机采样，删掉其中已过期的；单轮有时间和比例上限，扫不完就下一轮继续（这是"随机采样"而不是全量遍历，所以过期键可能存活很久）。二、从库的处理方式（关键差异）从库不执行 `activeExpireCycle`，也不会因为自己算着过期了就删除——因为从库的时钟、数据版本都可能和主库不一致，让它自己删会破坏主从一致性。从库收到读请求时，会用本地的 TTL 判断：逻辑上已过期就返回 nil（Redis 3.2 起的行为），但键在内存里仍然存在，直到主库的删除命令到达。主库删除时，会把 `DEL`（Redis 4.0+ 在 `lazyfree-lazy-expire yes` 下是 `UNLINK`）当作普通写命令传播给从库，从库照单执行——这才是从库上键真正消失的时刻。所以会出现一个容易误解的现象：从库上 `DBSIZE` / `KEYS` 还能看到这个键，但 `GET` 拿到的是 nil。这不是主从延迟 bug，是设计如此。三、"过期了还能读到旧值"什么时候会发生主库的过期删除是"惰性 + 采样"，如果一个键既没被访问到、也没被采样扫到，主库就一直没发 DEL，从库自然也就不会删。此时用 `RANDOMKEY`、`SCAN` 仍能看到它。所以不要把 Redis 的 TTL 当作业务上的强保证（比如"券到期一定不能再用"），业务侧要做二次校验，或者用逻辑过期字段 + 后台清理任务兜底。四、大量 key 同时过期怎么优化TTL 加随机抖动：写入时用 `EX 3600 + random(0, 600)`，把同一批数据的过期时间打散，避免整点雪崩。热点 key 永不过期：靠后台定时任务主动刷新值和版本号，读路径永远命中。逻辑过期 + 异步重建：值里存 `expireAt`，读到时若逻辑过期，先返回旧值并投递异步刷新任务（或用互斥锁 + 双重检查），避免大量请求同时回源数据库。开启异步删除：`lazyfree-lazy-expire yes`、`lazyfree-lazy-server-del yes`，把 DEL 变成 UNLINK，避免大 key 删除阻塞主线程；从库可以配 `replica-lazy-flush yes`。分批预热/分批下线：批量数据写入时按 hash 分片或时间窗分批，不要一次性写 10 万个同 TTL 的键。五、怎么确认是不是过期风暴`INFO stats` 里的 `expired_keys` 速率突然飙升 → 有集中过期；`INFO commandstats` 看 `del`/`unlink` 的 QPS；`SLOWLOG GET` 和 `LATENCY MONITOR` 看删除是否阻塞主线程；`INFO replication` 看 `master_repl_offset` 与从库 `slave_repl_offset` 的差值，判断复制是否被写命令拖慢。在华为云 DCS 上这套逻辑完全一致（DCS Redis 主从/集群版都是标准复制模型），额外可以用 DCS 控制台的慢查询分析、热 key 分析和实例监控里的"过期键"指标来定位。真要大批量清理，建议在业务低峰用 `SCAN` + `UNLINK` 分批删，别用 `KEYS` 和一次性 `FLUSHDB`。一句话总结：过期是主库的职责，从库只做"读时判定过期 + 被动执行删除"；防雪崩靠 TTL 打散和异步删除，别指望 TTL 做业务强一致。