Redis如何防止雪崩？
 

 什么是Redis缓存雪崩：
 
Redis不可能把所有的数据都缓存起来(内存昂贵且有限)，所以Redis需要对数据设置过期时间，并采用的是惰性删除+定期删除两种策略对过期键删除。如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。这就是Redis缓存雪崩。缓存雪崩会造成数据库直接崩溃，从而导致整个系统瘫痪。
 
如何防止Redis缓存雪崩：
 
（1）在缓存的时候给时间加上一个随机值，设置不同的缓存过期时间，减少缓存在同一时间过期的概率。
 
（2）或者设置缓存永不过期，数据有更新再主动更新。
 
 
 
Redis如何防止穿透？
 

 什么是Redis缓存穿透：
 
在数据库中，正常的数据库表ID都是从1开始的（正数），但是可能有黑客想要进行破坏，所以每次发送的请求ID值都是负数。而Redis缓存中并没有ID为负数的键，导致Redis缓存失效，所有请求都去请求数据库了，而数据库也没有这个负的ID值，所以每次都是返回空，导致Redis也不会记录。所以这个不存在的数据每次请求都能够越过Redis直接请求数据库，使得Redis缓存失去了意义。
 
这就是缓存穿透，如果大量的请求数据在缓存中不命中，导致请求直接走数据库，就有可能导致数据库崩溃，导致整个系统瘫痪。
 
如何防止Redis缓存穿透：
 
1、由于请求的参数是不合法的（每次都请求不存在的参数），所以我们可以使用布隆过滤器（BloomFilter）或者压缩filter提前拦截，不合法的请求就不能请求到数据库层。
 
2、如果通过某一个key去查询数据，而对应的数据库中不存在该数据，则可以将此key对应的value设置为一个默认的值，比如说null，并设置一个缓存的失效时间，这样，在缓存失效之前，所有的这个key的请求都会被Redis缓存挡住了。后面如果此key对应的数据在数据库中存在时，缓存失效之后，再通过此key再去访问数据，就能拿到新的value了。
 
 
 
Redis如何防止击穿？
 

 什么是Redis缓存击穿（热点key）：
 
缓存中的某一个key（比如说一个促销商品），在某个时间点过期的时候，刚好在这个时间点有大量的这个key的请求发送过来，这时就会有大量的请求直接访问数据库，可能会把数据库搞崩溃，从而导致系统瘫痪。
 
如何防止Redis缓存击穿：
 
（1）在对数据库查询的时候使用互斥锁，如果缓存过期了，在大量的请求中就只能有一个线程能够拿到查询数据库的锁，而其他的请求只能进入等待状态，等该线程进行完查询操作后，把拿到的数据写入Redis缓存中，从新设置缓存过期时间，这样其他的请求又会请求到Redis缓存，避免了数据库的崩溃。
 
（2）根据情况可以设置热点key永不过期,配合定时任务更新cache,或者数据有更新再主动更新。

 
 
 
  
面试：你懂什么是分布式系统吗？Redis分布式锁都不会？>>>   
 
 
 
 
###redis的缓存击穿？
 
 
缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，但是出于容错的考虑，如果从存储层查不到数据则不写入缓存层，如图 11-3 所示整个过程分为如下 3 步：
 
 
缓存层不命中
存储层不命中，所以不将空结果写回缓存
返回空结果
 
缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。
 
 
 
 
缓存穿透模型
 
 
缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。
 
 
造成缓存穿透的基本有两个。第一，业务自身代码或者数据出现问题，第二，一些恶意攻击、爬虫等造成大量空命中，下面我们来看一下如何解决缓存穿透问题。
 
 
缓存穿透的解决方法
 
 
1）缓存空对象
 
 
如下图所示，当第 2 步存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，保护了后端数据源。
 
 
 
 
缓存空值应对穿透问题
 
 
缓存空对象会有两个问题：
 
 
第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
 
 
第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
 
 
下面给出了缓存空对象的实现伪代码：
 
 
 
 
2）布隆过滤器拦截
 
 
如下图所示，在访问缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦截。例如： 一个个性化推荐系统有 4 亿个用户 ID，每个小时算法工程师会根据每个用户之前历史行为做出来的个性化放到存储层中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可以将所有有个性化推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户 ID 不存在，那么就不会访问存储层，在一定程度保护了存储层。
 
 
开发提示：
 
 
有关布隆过滤器的相关知识，可以参考：https://en.wikipedia.org/wiki/Bloom_filter
 
 
可以利用 Redis 的 Bitmaps 实现布隆过滤器，GitHub 上已经开源了类似的方案，读者可以进行参考：
 
 
https://github.com/erikdubbelboer/Redis-Lua-scaling-bloom-filter
 
 
 
 
使用布隆过滤器应对穿透问题
 
 
这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。
 
 
两种方案对比
 
 
前面介绍了缓存穿透问题的两种解决方法 ( 实际上这个问题是一个开放问题，有很多解决方法 )，下面通过下表从适用场景和维护成本两个方面对两种方案进行分析。
 
 
缓存空对象和布隆过滤器方案对比
 
 
 
 
###redis的缓存雪崩？
 
 
从下图可以很清晰出什么是缓存雪崩：由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。 缓存雪崩的英文原意是 stampeding herd（奔逃的野牛），指的是缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储。
 
 
 
 
缓存层不可用引起的雪崩
 
 
预防和解决缓存雪崩问题，可以从以下三个方面进行着手。
 
 
1）保证缓存层服务高可用性。
 
 
和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。
 
 
2）依赖隔离组件为后端限流并降级。
 
 
无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部 hang 在这个资源上，造成整个系统不可用。降级在高并发系统中是非常正常的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。
 
 
在实际项目中，我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管理，比如如何关闭资源池，开启资源池，资源池阀值管理，这些做起来还是相当复杂的，这里推荐一个 Java 依赖隔离工具 Hystrix(https://github.com/Netflix/Hystrix)，如下图所示。
 
 
 
  
 
    
  
 
 
 

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。
 
另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。本篇文章，并不是要更加完美的解决这三个问题，也不是要颠覆业界流行的解决方案。而是，从实际代码操作，来演示这三个问题现象。之所以要这么做，是因为，仅仅看这些问题的学术解释，脑袋里很难有一个很形象的概念，有了实际的代码演示，可以加深对这些问题的理解和认识。
 
缓存穿透
 
缓存穿透，是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。
 
Redis缓存流程
 
代码流程
 
参数传入对象主键ID根据key从缓存中获取对象如果对象不为空，直接返回如果对象为空，进行数据库查询如果从数据库查询出的对象不为空，则放入缓存（设定过期时间）想象一下这个情况，如果传入的参数为-1，会是怎么样？这个-1，就是一定不存在的对象。就会每次都去查询数据库，而每次查询都是空，每次又都不会进行缓存。假如有恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮数据库。即便是采用UUID，也是很容易找到一个不存在的KEY，进行攻击。
 
小编在工作中，会采用缓存空值的方式，也就是【代码流程】中第5步，如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。
 
下图是错误的写法：如果存了null，通过同一个key，从缓存获取到的还是null，这时候还会走数据查询。
 
 
以下是正确的写法：
 
// 全局空对象
    private static final String NULL_STRING = new String();
    // 读取缓存中的数据
    String value = myCacheClient.get(id);
    if(value == NULL_STRING){
        return null;
    }

    if(value == null){
        // value为null时查询数据库
        value = queryDB();
        // 不存在是存入空String对象
        if(value == null){
            // 此处之所以存NULL_STRING对象而不是存null，是因为如果存了null，通过同一个key，从缓存获取到的还是null，这时候还会走数据查询。
            myCacheClient.put(id, NULL_STRING);
            return null;
        }
    }
    // 否则将Json串转换成对象并返回
    return JSON.parseObject(value, Goods.class);
 
缓存雪崩
 
缓存雪崩，是指在某一个时间段，缓存集中过期失效。
 
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。
 
小编在做电商项目的时候，一般是采取不同分类商品，缓存不同周期。在同一分类中的商品，加上一个随机因子。这样能尽可能分散缓存过期时间，而且，热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。
 
缓存时间加入suijiyinzi
 
其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。
 
缓存击穿
 
缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
 
小编在做电商项目的时候，把这货就成为“爆款”。
 
其实，大多数情况下这种爆款很难对数据库服务器造成压垮性的压力。达到这个级别的公司没有几家的。所以，务实主义的小编，对主打商品都是早早的做好了准备，让缓存永不过期。即便某些商品自己发酵成了爆款，也是直接设为永不过期就好了。
 
 原文：https://baijiahao.baidu.com/s?id=1619572269435584821&wfr=spider&for=pc

Redis雪崩效应以及解决方案
 
缓存雪崩产生的原因
 
 
 
缓存雪崩通俗简单的理解就是：由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期间（缓存正常从Redis中获取，如下图）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机，造成系统的崩溃。
 
 
 
 
缓存失效的时候如下图：
 
 
 
 
缓存失效时的雪崩效应对底层系统的冲击非常可怕！那有什么办法来解决这个问题呢？基本解决思路如下：
 
  第一，大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力但是与此同时又降低了系统的吞吐量。
 
 第二，分析用户的行为，尽量让缓存失效的时间均匀分布。
 
 第三，如果是因为某台缓存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。
 
 
 
解决方案
 
1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
 
  缓存失效时的雪崩效应对底层系统的冲击非常可怕！那有什么办法来解决这个问题呢？基本解决思路如下：
 
 第一，大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力但是与此同时又降低了系统的吞吐量。
 
 第二，分析用户的行为，尽量让缓存失效的时间均匀分布。
 
第三，如果是因为某台缓存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。
 
 
 
 
 
解决方案
 
 
 
1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
 
     注意:加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法。
 
2：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
 
3：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期（此点为补充）
 
 
 
架构如下所示时候：
 
 
如何攻击redis？
 
如果再redis中有1000个key，如果同一时间失效？   直接查数据库了 不再走redis了 ！ 大连查询请求过来，，，，产生了雪崩效应~
 
这时候使用 限流 服务降级、熔断 的方案  这三个方案是针对redis的上一层的
 
 
 
Redis雪崩效应的解决方案
 
1、可以使用分布式锁   单机版的话本地锁
 
2、消息中间件方式
 
3、一级和二级缓存 Redis+Ehchache
 
4、均摊分配Redis的key的失效时间
 
 
 
解释：
 
 1、  当突然有大量请求到数据库服务器时候，进行请求限制。使用所的机制，保证只有一个线程（请求）操作。否则进行排队等待（集群分布式锁，单机本地锁）。减少服务器吞吐量，效率低。
 
 
 
 加入锁！
 
 
 
 
保证只能有一个线程进入  实际上只能有一个请求在执行查询操作
 
也可以在此处进行使用限流的策略~
 
 
 
2、使用消息中间件解决
 
  这种方案是最靠谱的方案！
 
   消息中间件 可以解决高并发！！！
 
  如果大量的请求进行访问时候，Redis没有值的情况，会将查询的结果存放在消息中间件中（利用了MQ同步特性）
 
   查不到时候 走MQ  
 
 
 
 
 3、一级二级缓存参考： https://www.cnblogs.com/toov5/p/9892910.html
 
 
 
4、均摊分配redis key的失效时间 
 
     不让在同一时间失效，不同key失效时间不同 哈哈