Redis 热 key 与 TTL 的处理清单

Redis 在项目里跑起来之后，缓存命中率看着不错，并不代表系统就稳了。到 2021 年很多内容和后台服务都会碰到两个更现实的问题：某几个 key 被打得特别热，以及 TTL 设得过于随意，导致缓存失效节奏非常难看。

这两个问题不先处理，Redis 很容易从“缓冲层”变成“抖动放大器”。

热 key 先判断是不是业务设计造成的

首页配置、热门榜单、站点导航、全局权限字典，这些天然就容易成为热点。与其等 Redis 撑不住再救火，不如先识别出哪些数据天生会被高频读取，再决定是否做本地缓存、副本分流或结果拆分。

热点不是意外，很多时候是业务结构决定的。

TTL 不要全站一个数字走天下

最常见的偷懒方式，就是所有缓存统一 300 秒。这样配置简单，但不同数据的波动频率、可容忍延迟和重建成本都不一样，统一 TTL 往往并不合理。

更实际的办法，是按数据类型分层，比如配置类更长、列表类适中、热点详情配合主动失效。

同一时间大量过期是很危险的

如果很多 key 用同样 TTL、又是在相近时间写入，它们可能会同时失效，引发回源尖峰。对读流量高的后台服务来说，这种抖动经常比单次 miss 更麻烦。

所以在 2021 年做缓存时，我会特别留意是否需要加一点过期抖动，让失效时间分散开。

热点重建路径要尽量轻

即使做好 TTL 设计，也不能假设热点永远不会失效。一旦重建需要查多表、拼很多字段、顺手再调几个外部接口，热点 miss 的代价就会被放大。

真正稳妥的做法，是把热点缓存对应的数据准备路径也尽量做轻。

小结

Redis 的热 key 和 TTL 管理，本质上是在管理系统波峰。先识别热点，再分层设置 TTL，并避免同批量失效，这套清单对 2021 年的大多数内容系统都很实用。