Redis缓存穿透、缓存存穿和缓存雪崩

         Redis缓存的使用，极大的提升了应用程序的性能和效率 特别是数据查询方面。同时，它也带来了一些问题。其中，最要害的问题就是数据一致性问题，从严格意义上讲，这个问题是无解的。如果对数据的一致性要求很高，那么就不能使用缓存! 另外就是一些典型的问题，缓存穿透，缓存雪崩和缓存击穿。目前，业界也有比较流行的解决方案。

缓存穿透(redis和db都查不到)

概念

        缓存穿透的概念其实很简单，用户想要查询一个数据，发现redis数据库没有，也就是所谓的没有命中缓存，于是向数据库查询，发现也没有，于是查询失败。但当用户请求很多时，直接请求数据库，这会给数据库造成很大的压力，这时候就相当出现了缓存穿透。

示意图

视缓存于无物

---

解决方案

布隆过滤器

        是一种数据结构，对所有可能有查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。。

1. 缓存空对象

        当存储层没命中后，及时返回的是空对象，也将其缓存起来，同时会这是一个过期时间，之后再访问这个数据将会从缓存中获取。保护了底层存储数据源

2. 出现的问题
         1. 如果控制能够被缓存起来，这就意味着缓存需要更多的空间来存储更多的键，因为当中可能会有很多的空值键。
         2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗的不一致，这对需要保持一致性的业务有影响。

---

缓存击穿(访问量大、热点key过期)

概念

         是指某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。
         当某个key在过期的瞬间，有大量的请求并发访问。这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并放回缓存，会使数据库压力过大。

解决方案

设置热点数据永不过期

         从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题。

加互斥锁

         分布式锁，基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。使用分布式锁保证对于每个key同时只有一个线程去查询后台服务，其他线程没有获得分布式锁的权限，因此等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

---

缓存雪崩(集中失效)

概念

         是指在某一时间段、缓存集中过期失效、Redis宕机。由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

示意图

同一时间、大面积key过期失效

        其实集中的key过期、倒并不是非常致命的、比较致命的缓存雪崩、是缓存服务器某个节点宕机或者断网。因为自然形成的雪崩、一定是在某个时间段集中创建缓存、这个时候、数据库也是可以顶住压力的。无非对数据库产生周期性的压力。而缓存服务节点的宕机、对数据库服务器造成的压力是不可预知的、很有可能瞬间就吧数据库压垮。

解决方案

Rredis高可用

        这个思想的含义是、既然redis有可能会挂掉、那么我多增加几台redis、这样其中一台即使挂掉其他的还能正常工作。说白了就是搭建redis集群。

缓存降级

        当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

        降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

        在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；

        比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

缓存预热

        缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
        缓存预热解决方案：
        （1）直接写个缓存刷新页面，上线时手工操作下；
        （2）数据量不大，可以在项目启动的时候自动进行加载
        （3）定时刷新缓存；

缓存更新

        除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰。
        常见的策略有两种:
        (1）定时去清理过期的缓存；
        (2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
        两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。