Redis用于做缓存是非常棒的，内存数据库可比MySQL这些会产生IO读取的快乐不知道多少倍。但是Redis也还是会面临着如下几种问题：缓存穿透、击穿和雪崩；下面就简单分析下原因和解决方案。

1、缓存穿透

什么是缓存穿透呢，首先我们知道，我们用redis做缓存的大概逻辑如下：

根据KEY取Redis中读取，若是有值则直接返回，否则继续下一步
根据key去数据库中查找，若是有值，则将结果放入redis，然后返回，否则数据不存在

那么上面会面临什么问题呢？假如攻击者（这种情况一般是因为有攻击者来攻击，正常业务逻辑不会存在数据库中没有值的情况）直接大量调用该接口，随机构造key，然后这些key在我们的数据库中都没有对应值，这样子就会每次都直接访问到数据库，redis就失去了缓存的意义，给数据库造成了巨大的压力。因此，缓存穿透的大概意思是：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。

解决方案

1、我们知道，缓存穿透基本上都是有人在对系统进行攻击才会发生的，正常业务逻辑不会发生，所以根本上的解决方案是：实现API限流，防御DDOS攻击，接口频率访问控制。只有直接限制攻击者的访问频率，把不合法的攻击者假如到黑名单中，才是最根本有效的解决方案。

2、从数据库中查询不到值的时候，也将key写入redis，并且值设置为一个较短的有效期。这种方案其实是不靠谱的，首先这个只适用于相同的KEY，假如攻击者一直随机生成不同的key就拦不到了，并且会对正常的redis使用造成影响，不过还是会有一点点用的。

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

2、缓存击穿

缓存击穿是什么意思呢，这个其实是对于单个热点KEY的情况下，在高并发访问此“热点KEY”，但是该KEY过期了，此时会有大量的访问直接访问数据库，压垮我们的数据源。比如在抽奖秒杀等活动中，法发生的概率很高。

解决方案

这里我觉得最好的解决办法是采用分布式锁吧，击穿导致的是数据库被压垮，是因为都一起访问数据库，但是如果我们用分布式锁，限定只有一个请求去访问数据库，将值从数据库中读取回来放入redis中，然后其它请求就直接使用redis中的值啦，如下是redis实现分布式锁的一个代码例子，很简单的，主要是靠：setNx命令，当然也还可以用zookeeper。

public String get(key) {
      String value = redis.get(key);
      if (value == null) { //代表缓存值过期
          //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
      if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
               value = db.get(key);
                      redis.set(key, value, expire_secs);
                      redis.del(key_mutex);
              } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
                      sleep(50);
                      get(key);  //重试
              }
          } else {
              return value;      
          }
 }

3、缓存雪崩

什么是缓存雪崩呢？，与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。比如redis中的一批key同时间失效了，这样子就会全部key都得同时区请求数据库，最后压垮数据库。

解决办法

对key的失效时间进行随机化设置。既然是因为同时间失效，导致都同时去读取数据库，那么我们对key的失效时间假如一个随机数，比如1~5分钟失效，这样子就很小概率会出现同时失效的情况。

好了，我们大概也理解了redis的缓存穿透、击穿、雪崩，代码参考了博文：https://www.cnblogs.com/xichji/p/11286443.html