Redis热点Key过期咋防，热点和key那些事儿你得知道

说到Redis的热点Key问题,特别是当热点Key突然过期时引发的“缓存击穿”现象，这确实是很多系统在流量高峰期会遇到的头疼事，咱们今天就不绕弯子，直接聊聊怎么防，以及和热点Key相关的那些门道。

啥是热点Key？它为啥会“惹祸”？

热点Key就是在你的Redis缓存里,被访问次数特别多的那个或那几个Key，电商平台上某个秒杀活动的商品信息，或者某个顶流明星刚刚发布的一条新闻详情，所有的请求在短时间内都冲着它去，它就成了“热点”。

热点Key本身不是问题,问题是出在它“失效”的那一刻，想象一个场景：一个热点Key，秒杀商品_001”，它设置了1小时的过期时间，在这1小时内，成千上万的请求来查询这个Key，因为缓存里有数据，Redis轻松应对，数据库毫无压力，1小时到了，这个Key“啪叽”一下自动过期了，可就在这一刻，恰好有大量请求同时涌来，发现缓存里这个Key没了，这下糟了，所有这些请求都会直接冲到后面的数据库上去，要去数据库里重新查询这个秒杀商品的信息，数据库本来在休息，突然被海量查询请求猛击，很可能瞬间就被打趴下，导致服务不可用，这个过程，就是常说的“缓存击穿”。

怎么防止热点Key过期引发的“缓存击穿”？

核心思路就一条：别让大量请求在同一时刻穿透缓存去访问数据库，这里有几种常见的、接地气的做法：

1. 设置永不过期，但手动维护（来源：常见的缓存策略实践）

   • 做法：对于那些极其热点、我们知道会长期受欢迎的Key，干脆就别设置过期时间（TTL），让它永远待在缓存里。
   • 怎么更新？：数据总归是要变的，我们可以通过程序逻辑来手动更新它，在后台管理端，当管理员修改了这件秒杀商品的信息时，在更新数据库的同时，主动地去更新Redis里这个Key的值，或者，启动一个定时任务，定期从数据库拉取最新数据刷新到缓存中。
   • 好处：从根本上避免了因自动过期导致的“集体穿透”。
   • 注意点：需要额外的代码逻辑来保证缓存和数据库的数据一致性，并且如果这个Key后来不热了，可能会一直占用内存。

2. “锁”住第一个请求，让它去加载数据（来源：分布式锁应用场景）

   • 做法：当热点Key过期失效时，允许一个请求去数据库查询，但这个请求要“抢”到一把锁（可以用Redis的setnx命令实现一个简单的分布式锁），抢到锁的这个请求，辛苦一趟去数据库拉取数据，然后回填到Redis缓存里，在这个过程中，其他没抢到锁的请求怎么办呢？不要让它们傻等着或者直接去查数据库，可以让它们短暂休眠一下（比如几十毫秒），然后重新尝试从缓存读取，一旦第一个请求把数据加载好了，后续请求就能直接从缓存中拿到数据了。
   • 好处：保证了只有一个线程会去访问数据库，避免了数据库压力过大。
   • 注意点：锁的逻辑要写好，防止死锁；设置合理的重试次数和休眠时间，避免请求长时间阻塞。

3. “提前续命”，不让它突然死亡（来源：缓存延期策略）

   

   • 做法：不给Key设置固定的过期时间，而是给Key的值里存两个东西：实际的数据 + 一个逻辑过期时间戳，每次业务程序从缓存拿到数据后，先检查一下这个逻辑过期时间戳是否快到了（比如还剩1分钟），如果快到了，就主动去延长这个Key的物理过期时间（比如再续上1小时），或者直接异步更新数据，这样，Key在物理上几乎不会过期，由应用逻辑来控制它的生命周期。
   • 好处：实现了平滑过渡，在访问过程中就完成了续期或更新，用户体验无感知。
   • 注意点：逻辑稍微复杂一点，需要修改缓存数据结构和业务代码。

除了防过期，热点Key本身还有啥要注意的？

1. 热点Key可能压垮Redis单实例：即使不过期，如果某个Key太热，所有请求都打到了Redis集群中的某一个实例上（因为Key是通过哈希计算分配到特定节点的），会导致这个实例的CPU和网络带宽吃紧，成为瓶颈，这就是“热点Key倾斜”问题。

   • 应对办法：可以对热点Key进行本地缓存，在应用服务器本地（比如JVM内存中）也存一份热点Key的数据，并设置一个短的过期时间，这样大部分请求根本不用走到Redis，直接在本地就返回了，极大地减轻了Redis的压力，这可能会带来数据短暂不一致的问题，需要根据业务容忍度来权衡。

2. 如何提前发现热点Key？

   • 监控报警：必须要有完善的Redis监控，关注每个实例的QPS（每秒查询次数）和网络流量，如果某个实例的指标远高于其他实例，很可能就是有热点Key存在。
   • Redis自带命令：Redis 4.0及以上版本提供了redis-cli --hotkeys命令，可以帮你找出当前的热点Key，不过在生产环境使用可能会有一点性能影响。
   • 代理层或客户端统计：在一些复杂的架构中，可以在访问Redis的代理层或者在客户端代码里埋点，统计Key的访问频率，从而发现热点。

对付热点Key过期,核心是“错峰”和“缓冲”，要么让它永不过期由我们手动控制，要么用锁控制只有一个请求去加载，要么给它提前续命，而对付热点Key本身，还要警惕它造成的单点压力，可以考虑用本地缓存来分担，最关键的是，要有监控意识，能提前发现热点苗头，才能防患于未然，这些东西并不高深，但需要在实际项目中结合业务特点去灵活运用和不断调整。