无水干货：缓存雪崩的解决思路

上次我们讨论了在分布式系统下的缓存架构体系&＃xff0c;从浏览器缓存到客户端缓存&＃xff0c;再到CDN缓存&＃xff0c;再到反向代理缓存&＃xff0c;再到本地缓存&＃xff0c;再到分布式缓存。整个链路中有非常多的缓存。

在整个缓存链路&＃xff0c;存在各种各样的问题&＃xff0c;常见的问题有缓存穿透、缓存击穿、缓存雪崩、缓存数据一致性问题等。不常见的问题有缓存倾斜、缓存阻塞、缓存慢查询、缓存主从一致性问题、缓存高可用、缓存故障发现与故障恢复、集群扩容收缩、大Key热Key等等。

今天我们就来聊聊&＃xff1a;缓存雪崩

缓存雪崩&＃xff0c;顾名思义&＃xff0c;是缓存崩了。如果这样理解的话&＃xff0c;那就错了&＃xff0c;请跟我来一探究竟吧。

老规矩&＃xff0c;先看一下本文大纲&＃xff1a;

• 什么是缓存雪崩
• 缓存雪崩的痛点有哪些
• 缓存雪崩的解决思路
• 总结

什么是缓存雪崩

我们知道&＃xff0c;缓存的工作原理是先从缓存中获取数据&＃xff0c;如果有数据则直接返回给用户&＃xff0c;如果没有数据则从慢速设备上读取实际数据并且将数据放入缓存。就像这样&＃xff1a;

缓存里面的数据有很多&＃xff0c;如果有一个key过期&＃xff0c;那么就需要回溯查询&＃xff0c;如果这个key是热点key&＃xff0c;慢设备压力剧增&＃xff0c;有可能导致慢设备宕机。就像这样&＃xff1a;

这便是我们之前说的&＃xff1a;缓存击穿

那如果是很多key都过期了&＃xff0c;那请求都会透过缓存层&＃xff0c;直奔慢设备了&＃xff0c;如果这些失效的key的请求之和很大&＃xff0c;那么慢设备压力剧增&＃xff0c;有可能导致慢设备宕机。就像这样&＃xff1a;

这便是我们今天的主题&＃xff1a;缓存雪崩

没错&＃xff0c;从上面的含义其实已经能够理解出一个区别&＃xff1a;

缓存击穿强调单Key过期&＃43;高并发&＃xff1b;

缓存雪崩强调多key过期&＃43;高并发。

&＃xff08;所以&＃xff0c;缓存雪崩不是缓存崩了&＃xff0c;是一大片大片的缓存数据都在同一时间都失效了&＃xff09;

雪崩&＃xff0c;实在是太可怕了。

缓存雪崩的痛点有哪些

1.热点数据扎堆过期
2.缓存层瞬间透明化
3.慢设备层有被击垮的风险
大家猜想一下&＃xff0c;为什么会瞬间有大量数据过期呢&＃xff1f;

有两个方向&＃xff0c;其一是大量数据同时放入缓存&＃43;过期时间设置的时间是一致的&＃xff1b;其二是大量数据放入缓存的时间点不一样&＃xff0c;但是过期时间是同一时间过期。

其一比较好理解&＃xff0c;给大家举几个场景就更好了理解了&＃xff0c;比如系统在启动的时候或者每天定时的对大量数据进行预热&＃xff0c;并且过期时间是一样的。又或者是大促&＃xff0c;商品在同一时刻开放&＃xff0c;大量的用户进行不同商品的访问&＃xff0c;这些商品数据几乎同时进入缓存&＃xff0c;并且过期时间是一样的。

其二不太容易理解&＃xff0c;给大家举个场景就好了。比如有一个给用户推送消息的需求&＃xff0c;但是一天只允许推送一次&＃xff0c;假设给张三同学早上8点推送&＃xff0c;那么可以将这条数据放入缓存&＃xff0c;过期时间为16小时&＃xff0c;再次给张三推送的时候检查缓存是否存在&＃xff0c;缓存存在则不允许推送了&＃xff0c;缓存不存在则允许推送。给李四同学下午14点推送了一条消息&＃xff0c;那么给李四同学放缓存的数据过期时间应该是10小时。这个场景就解释了在不同的时间点放入的数据&＃xff0c;它们的过期时间不一样&＃xff0c;但是都是在同一时刻过期&＃xff08;在这个例子中是每天0点过期&＃xff09;。

缓存雪崩的解决思路

1.从上述的其一来看&＃xff0c;是数据放入缓存的时间和过期时间一样&＃xff0c;所以最终大量数据同一时间过期。

所以&＃xff0c;我们从这一点来看&＃xff0c;我们可以改变数据放入缓存的的时间&＃xff0c;也可以选择修改数据的过期时间&＃xff0c;让过期时间不一致&＃xff0c;最终的目的是让数据分散在不同的时间点过期&＃xff0c;从而减少数据库的高并发压力。很显然&＃xff0c;修改数据的过期时间更简单一些&＃xff0c;让缓存时间在一定的区域随机取值&＃xff0c;很轻松就能解决了一个缓存雪崩的问题。www.linuxprobe.com

2.当然了&＃xff0c;问题的产生是数据过期了&＃xff0c;所以还有一种解决方案是&＃xff1a;让你的数据永不过期&＃xff01;显然&＃xff0c;你的leader或者身为leader的你是不会这么玩的&＃xff0c;这个方案基本不可行。原因是就算让缓存数据在缓存永不过期&＃xff0c;那难道缓存敢保证100%保证可用吗&＃xff1f;不敢&＃xff0c;所以&＃xff0c;你还是需要准备planB&＃xff0c;做好缓存宕机或者缓存数据不存在的备案。

3.既然是因为并发访问导致&＃xff0c;我们是不是可以由高并发转换低并发&＃xff0c;称之为互斥锁&＃xff0c;或者分布式锁等&＃xff0c;总之&＃xff0c;加锁来保证高并发转换成低并发。

4.我们继续分析&＃xff0c;像这种热点数据&＃xff0c;是不是应该由热点服务器去完成&＃xff0c;对吧&＃xff1f;我们应该去做隔离机制&＃xff0c;如果你有一套实时热点发现系统&＃xff0c;再加上热点流量自动迁移到热点服务器&＃xff0c;就算有这些有什么用&＃xff0c;能解决问题吗&＃xff1f;答案是不能&＃xff0c;因为热点服务器仍然是需要防止缓存雪崩的&＃xff0c;方案在上面已经提到过了就不再赘述了。这里只是抛砖引玉&＃xff0c;浅谈环境隔离与实时热点发现。

5.继续&＃xff0c;既然是数据库承受不住了&＃xff0c;我们在知道问题的情况下&＃xff0c;可以对数据做离散分布&＃xff0c;让它均匀地分布在我们的分布式数据库中&＃xff0c;同时对数据库尽量的水平扩容&＃xff0c;常见的分库分表策略有32库32表&＃xff0c;64库64表&＃xff0c;128库128表......&＃xff0c;这样做的目的是让单台数据库压力变小&＃xff0c;从而防止缓存雪崩。

6.继续分析&＃xff0c;我们从现象来看&＃xff0c;是数据库宕机了&＃xff0c;原因是数据库接受到的瞬间请求太多了&＃xff0c;数据库扛不住压力所以就停止工作了。那我们是不是可以这么分析&＃xff0c;如果我们提前知道数据库能承受的最大阈值是多少&＃xff0c;并且提前设置好数据库的阈值或者服务的阈值&＃xff0c;如果瞬间流量来了&＃xff0c;我们把超过阈值的流量进行排队等待或者直接拒绝服务&＃xff0c;保证数据库的压力是不超过阈值的&＃xff0c;是不是也能解决缓存雪崩所带来的影响呢&＃xff1f;

那么这里面有涉及到几个数据&＃xff1a;数据库的阈值从何得知、服务的阈值从何得知、如何设置数据库或者服务的阈值。

答案是&＃xff1a;数据的阈值应该是压测后得出&＃xff0c;而设置阈值应该是在网关层进行限流处理&＃xff0c;所以你需要有这样的限流平台。

对于压测和网关&＃xff0c;我们后续会有专门的文章来讨论&＃xff0c;本期暂且不深入了&＃xff0c;敬请期待。可以关注我的公中号&＃xff1a;李哥技术

总结

其实缓存雪崩的理解很简单&＃xff0c;为什么说得这么复杂&＃xff0c;原因很简单&＃xff0c;就是不想让大家用背八股文一样的方式去记忆&＃xff0c;而是靠深入理解它的痛点然后逐步分析解决方案去记忆。

来总结一下吧。

概念&＃xff1a;缓存雪崩指的是大片大片的缓存数据同时过期失效&＃xff0c;再加上高并发的请求进入到慢设备&＃xff0c;慢设备压力剧增&＃xff0c;有可能导致慢设备宕机&＃xff0c;这便是缓存雪崩。

解决方案&＃xff1a;

1.修改数据放入缓存的时间&＃xff0c;或修改数据在缓存中的过期时间&＃xff1b;
2.让缓存数据永不过期&＃xff1b;
3.互斥锁&＃xff0c;由高并发转换成低并发&＃xff0c;保护DB&＃xff1b;
4.热点隔离&＃xff0c;实时热点发现系统&＃xff1b;
5.水平扩容数据库&＃xff0c;压力平摊&＃xff0c;保护DB&＃xff1b;
6.提前压测&＃xff0c;得出阈值&＃xff0c;限流处理&＃xff0c;保护服务与DB&＃xff1b;
好了&＃xff0c;本期缓存雪崩的解决思路就到这里了&＃xff0c;感谢阅读&＃xff01;