原来缓存也会雪崩、击穿、穿透啊

在互联网时代，大流量、海量数据、高并发是每个企业都渴望又害怕的名词，渴望是因为它们代表着提供的服务用户愿意买单、有价值；害怕是因为一旦用户全上来了，系统不能正常为用户提供服务，让用户失望，最终选择离开。仅靠着超高配置的服务器资源，还是很难支撑高并发的场景。因此我们需要缓存。

缓存在计算机的世界里无处不在，在CPU中有一级二级三级缓存，在Linux操作心态中有TLB加速虚拟地址和物理地址的转化，在应用服务中有redis数据库进行数据缓存，在浏览器或app中有本地缓存。可以说缓存是非常重要了，有了它，整个世界仿佛都变美好了，刷网页很快就有数据的返回，再也不用一直苦苦等待了。

通过一个简单的例子来看看缓存是什么？我们知道数据都是存储在数据库里的，而数据库数据一般都存储在磁盘上。当用户请求从前端过来时，如果直接去访问获取磁盘的数据库数据，就会非常慢。如果有了缓存，在用户请求到达之后，业务线程就会先访问缓存，如果缓存命中就直接返回用户，如果没有命中，则继续请求磁盘数据库数据，获取后返回用户，同时将磁盘获取的数据结果回写到缓存系统，为下次请求做好准备。

可是这么强大的缓存系统，其实也存在很多问题呢，那便是缓存雪崩、缓存击穿、缓存穿透。不过也不要害怕，有问题就有解法，我们慢慢的往下看。

所谓缓存雪崩，指的是缓存数据同一时间大量失效，所有的请求全打到数据库，导致数据库在巨大压力下挂掉。比如在双十一的时候，用户都会打开淘宝买东西，有的人是真的有需要买的，有的人就是凑个热闹，不管怎么样，这时候首页的压力就非常大了，为了满足所有用户都可以访问到数据，阿里的程序员们将首页数据缓存到redis里，并设置redis失效时间是12小时。我们知道redis是内存数据库，那访问速度，杠杠的啊。数据缓存后用户们买的很开心，程序员们也很开心，系统都还好着呢…..慢慢的12个小时过去了，用户购物的热情不减啊，还是大量的用户请求在过来，然而首页redis缓存的数据全失效了，这时候redis里没有数据了，用户请求直接扑向数据库，数据库哪能扛得住啊，直接垮掉。

应对缓存雪崩，我们也有一些办法，比如随机设置key的失效时间，避免大量的key同时失效，比如不要设置过期时间或把过期时间设置得很长，再比如运行定时任务，随时监控缓存情况，在失效前刷新进新的缓存。

所谓缓存穿透，指的是缓存中没有缓存到该数据，从而导致请求直接到达数据库，数据库在巨大压力下挂掉。比如在双十一的时候，有黑客经过多次攻击测试发现混沌炸鸡（假设商品ID为-1）这个商品在网站上没有，于是便写了一个脚本，大量的去请求这个商品，redis缓存一看我只有炸鸡商品，不满足需求啊，于是就放到数据库那里了，所有的请求全放给数据库了，数据库说我也没有啊，但还是不断地被接受轮询，结果直接垮掉。

应对缓存穿透，我们也有一些办法，比如对于某些不存在的数据缓存在redis时设置为null，比如对请求参数进行校验，不合法的直接拦截，比如增加安全防护，定期扫描，有发现不正常的数据直接将该请求的IP地址加入黑名单。

所谓缓存击穿，指的是缓存的热点数据突然失效导致大量的请求都去访问数据库，数据库扛不住压力，直接挂掉。比如双十一的时候，iPhone12在凌晨00:00-01:00可1分钱抢购，哇，这个可是真便宜呢，程序员们也预测到了商品的火爆，于是将iPhone12的商品信息缓存到redis中，设置了1小时过期。iPhone12是新推出的商品，引起了一亿人的关注，男女老少全都蜂拥而至，只为了抢购一个iPhone，到了59分的时候，突然iPhone12在redis的数据过期了，这时候大量的请求都到了数据库，数据库直接垮掉了。

应对缓存击穿，我们也有一些办法，比如设置热点数据永不过期，比如给数据加锁，当有线程请求不到数据时，其它的用户线程也无法请求数据，直到第一个线程拿到数据后，去redis缓存起来，其它的线程仍然走缓存拿数据，比如服务降级，直接返回“商品太火爆了，系统暂时休息会儿”。

通过本文的介绍，相信你对缓存、缓存雪崩、缓存击穿、缓存穿透也有了对应的了解了吧。当你所在的业务因为高并发、大数据量准备启用缓存策略时，对于缓存可能带来的雪崩、击穿、穿透问题要做好防护措施，这样大家都可以开开心心的玩耍了～