Redis缓存穿透、击穿、雪崩、更新

正常状态下Redis做缓存时，请求会先落在Redis上，假设Redis中不存在或者缓存失效，则去数据库中进行查找，找到就更新缓存返回请求，找不到就返回空。

缓存穿透

上述时正常执行时，但是如果请求的数据根本不存在，即数据库中没有，Redis中肯定也不会缓存，Redis缓存对于这种请求相当于透明的（肯定不会起作用），最终请求会落在数据库上，查询的结果肯定为空，这就叫缓存穿透。当大量的这种请求落在数据库上，就可能会导致数据库的宕机，数据永远不存咋，请求永远落在数据库上。

解决方法：
1.请求数据不存在，也将其缓存到Redis中，只不过值为null而已。这样后续的请求就会在缓存中找到null值则直接返回，不会落在数据库上。需要注意将过期时间设置短一些，防止占用过多的内存。
2.在请求层面进行判断，对无效的请求值直接不发送请求，不过很多时候无法做出判断。
3.使用布隆过滤器过滤请求。布隆过滤器的本质是一个二进制数组，首先对每一个数据库中存在的值进行hash，将所有的hash进行或运算。对请求进行hash，判断该hash值的每个1在布隆过滤器中是否为1，任意一个不为1则判断非法。

缓存击穿

当某个key突然有大量的访问，但是这个值并不存在与缓存或者缓存失效时，请求最终会落在数据库上，可能会导致数据库的宕机。即存在于数据库中，但是不存在与缓存中（根本没有或者缓存过期），导致请求落在数据库上。

解决方案：
1.热点数据永不过期。既然可能时缓存过期导致的，那么热点数据一直在缓存中不失为一种解决方案。但是依旧可能会出现缓存击穿，即以前不是热点数据但某个瞬间突然大量访问，成为热点。
2.缓存预热，将可能的热点数据提前放到缓存中
3.使用互斥锁。既然可能时某个key的大量请求，那么让只让一个去数据库中查找，其他的请求等数据从数据库中放入缓存后，从缓存中读取。常用做法是使用mutex,利用Redis带成功操作返回值的操作SETNX，先设置key的key_mutex，如果成功则进入数据库访问，不成功则等待从缓存中读取。

  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;      
    }

缓存雪崩

当redis中的大量缓存同时失效，那么请求最终会落到数据库上，导致数据库宕机。缓存击穿和缓存雪崩的差异|：都是key不存在于redis中，从而导致请求落在服务器上，但是缓存击穿是某个热点key的大量并发访问，而缓存雪崩就是许多key的并发访问,每个key请求量可能并不大，但是key的数量变多了。

解决方案：
1.在缓存过期加个随机值，避免大量缓存同时失效。
2.设置二级缓存，二级缓存的过期时间比一级缓存的长。一级缓存失效后从二级缓存查找，二级缓存中也不存在再去数据库中查找。
3.加锁排队，所有的请求都入队排序
5.设置过期标志更新缓存，redis中有缓存数据和缓存标志。缓存数据的过期时间比缓存标志要长，当缓存标志过期后，依然可以得到缓存数据，并且在这段时间更新缓存数据过期时间和缓存标志。

int cacheTime = 30;
String cacheKey = "product_list";
//缓存标记
String cacheSign = cacheKey + "_sign";

String sign = CacheHelper.Get(cacheSign);
//获取缓存值
String cacheValue = CacheHelper.Get(cacheKey);
if (sign != null) {
    return cacheValue; //未过期，直接返回
} else {
    CacheHelper.Add(cacheSign, "1", cacheTime);
    ThreadPool.QueueUserWorkItem((arg) -> {
  //这里一般是 sql查询数据
        cacheValue = GetProductListFromDB(); 
      //日期设缓存时间的2倍，用于脏读
      CacheHelper.Add(cacheKey, cacheValue, cacheTime * 2);                 
    });
    return cacheValue;
}

缓存穿透、击穿、雪崩最后都造成了大量请求落在数据库上，可能导致数据库宕机。只是原因各有不同，但是解决的核心都是一样的，尽可能的把请求拦在数据库之外，或者控制访问数据库的并发量。对于具体的场景，采用合适的解决方案即可。

缓存更新

缓存更新的设计模式有四种：

Cache aside：查询：先查缓存，缓存没有就查数据库，然后加载至缓存内；更新：先更新数据库，然后让缓存失效；或者先失效缓存然后更新数据库；

Read through：在查询操作中更新缓存，即当缓存失效时，Cache Aside 模式是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载；

Write through：在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后由缓存自己更新数据库；

Write behind caching：俗称write back，在更新数据的时候，只更新缓存，不更新数据库，缓存会异步地定时批量更新数据库；