缓存穿透，缓存击穿，缓存雪崩 以及缓存的一致性解决方案

缓存架构图

缓存穿透

缓存穿透是指查询一个一定不存在的数据，缓存和数据库中都不存在，像一个子弹一样连穿透2层挡板，由于缓存是不命中时被动写的，而又出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。高并发时，可能DB就会出现宕机，要是有人利用不存在的key频繁攻击我们的应用，这就是系统漏洞。

解决方案

1. 如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟，此方法简单粗暴，如果有黑客短时间用大量不存在的key去攻击，缓存系统内存不足会执行LRU淘汰策略 淘汰掉正常在使用的值
2. 采用布隆过滤器（缓存和数据库之间），将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

缓存击穿

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

1. 使用互斥锁(mutex key): 这种解决方案思路比较简单，就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了。如果是单机，可以用synchronized或者lock来处理，如果是分布式环境可以用分布式锁。
2. 提前"使用互斥锁(mutex key)"：在value内部设置1个超时值(timeout1), timeout1比实际的redis timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。
3. 永远不过期：
4. 资源保护：netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效或者缓存服务器宕机，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案

1. 可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件
2. 用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上
3. redis高可用，主从+哨兵

缓存的一致性

策略一：先更新缓存，再更新数据库

问题: 线程1更新缓存——>线程1更新数据库失败，会导致缓存数据不一致

策略二：先更新数据库，再更新缓存

问题：线程2 更新数据库——>线程1更新数据库——>线程1更新缓存——>线程2 更新缓存，会导致数据不一致

策略三：先删除缓存，再更新数据库

问题：线程1删除操作——> 线程2读取操作——>线程1更新数据库——>线程2将读取值写入缓存，会导致数据不一致

策略四：先更新数据库，再删除缓存

问题：线程1 读取缓存—未命中—>线程1读取数据库——>线程2更新数据库——>线程2 删除缓存——>线程1设置缓存，会导致数据不一致

现实中一般采取该方法，因为一般读操作比写操作时间短，为了保险做延迟双删，延迟时间大于一次读取时间

正确使用好redis知识小结

• 事前:redis高可用，主从+哨兵，redis cluster，避免全盘崩溃
• 事中:本地ehcache缓存（redis和数据库之间）+hystrlx 限流+降级，避免mysql被打死
• 事后：redis持久化RDB+AOF一旦重启从磁盘上加载数据尽快恢复缓存数据