概述

针对雪崩、击穿、穿透问题，前提都是在高并发情况下，如果你做的场景流量在mysql数据库承载范围内，那么你并不需要关心这些问题。你只要保证你使用缓存，保证缓存与数据库数据一致性即可。所以今天讨论的是在高流量情况，如何应对使用缓存中一些常见的问题。

缓存雪崩

   背景:大量缓存同时过期,直接访问数据库刷新缓存数据,访问量超过mysql并发处理阈值,导致mysql长时间
   无响应,导致依赖mysql服务都长时间不可用,无响应,服务超时.
   
   解决方案:
       1.错开缓存过期时间,设置业务满足的过期时间之后,再加个过期时间的随机数
       
       2.采用服务降级,核心业务允许访问,非核心业务直接返回预定义信息直接返回
   
  背景: redis单台机器部署,直接宕机了,那么很明显,这个时候缓存全部失效,直接大量请求到mysql,在redis没
       恢复之前,这些大量请求是长期存在的,和上面允许部分先刷缓存慢慢恢复服务(短时间)还有点不一样
       
   解决方案:    
       1.redis高可靠集群部署,当主节点宕机,哨兵直接切换新节点(从节点),缓存瞬间全部恢复
       
       2.熔断,限流

缓存击穿

   背景:热点数据,也就是单条数据访问量非常高,只要缓存一过期,马上有大量访问请求到数据库,导致缓存击穿.
       比如微博热搜数据,如果缓存一过期,那么将承受巨大流量
       
   解决方案: 
   
   1.对于热点数据直接不设置缓存数据即可.    
   2.加锁，拦截不必要的请求
      

缓存穿透

  背景: 非正常用户故意发起缓存中不存在的数据,那么必然不会中缓存,并且开启多线程刷你接口,一般这种都是
       恶意请求,并且持续高流量发起攻击,导致mysql承受巨大流量压力,影响正常业务访问数据库
       
 解决方案:
       1.对于明显不存在的数据,在缓存中设置一个空值,这样直接走缓存,保护了数据库
       
       2.在应用程序代码中,做合法参数校验
       
       3.使用布隆过滤器,用来判断真实存在的数据,不存在的直接返回错误信息即可

总结

上述情况都是在高流量的情况才会发生的,如果流量不大,不存在会影响服务不可用的情况