如何处理缓存失效、缓存穿透、缓存并发等问题

缓存失效：

　　引发这个缘由的主要因素是高并发下，咱们通常设定一个缓存的过时时间时，可能有一些会设置5分钟啊，10分钟这些；并发很高时可能会出在某一个时间同时生成了不少的缓存，而且过时时间在同一时刻，这个时候就可能引起——当过时时间到后，这些缓存同时失效，请求所有转发到DB，DB可能会压力太重。

　　处理方法：

　　　　一个简单方案就是将缓存失效时间分散开，不要因此缓存时间长度都设置成5分钟或者10分钟；好比咱们能够在原有的失效时间基础上增长一个随机值，好比1-5分钟随机，这样每个缓存的过时时间的重复率就会下降，就很难引起集体失效的事件。

   缓存失效时产生的雪崩效应，将全部请求所有放在数据库上，这样很容易就达到数据库的瓶颈，致使服务没法正常提供。尽可能避免这种场景的发生。

缓存穿透：

　　出现场景：指查询一个必定不存在的数据，因为缓存是不命中时被动写的，而且出于容错考虑，若是从存储层查不到数据则不写入缓存，这将致使这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

　　当在流量较大时，出现这样的状况，一直请求DB，很容易致使服务挂掉。

     处理方法：

　　　　方法1.在封装的缓存SET和GET部分增长个步骤，若是查询一个KEY不存在，就已这个KEY为前缀设定一个标识KEY；之后再查询该KEY的时候，先查询标识KEY，若是标识KEY存在，就返回一个协定好的非false或者NULL值，而后APP作相应的处理，这样缓存层就不会被穿透。固然这个验证KEY的失效时间不能太长。

　　　　方法2.若是一个查询返回的数据为空（无论是数据不存在，仍是系统故障），咱们仍然把这个空结果进行缓存，但它的过时时间会很短，通常只有几分钟。

　　　　方法3.采用布隆过滤器，将全部可能存在的数据哈希到一个足够大的bitmap中，一个必定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

缓存并发：　

　　出现场景：当网站并发访问高，一个缓存若是失效，可能出现多个进程同时查询DB，同时设置缓存的状况，若是并发确实很大，这也可能形成DB压力过大，还有缓存频繁更新的问题。

　　处理方法：对缓存查询加锁，若是KEY不存在，就加锁，而后查DB入缓存，而后解锁；其余进程若是发现有锁就等待，而后等解锁后返回数据或者进入DB查询。