redis缓存常见问题及解决方案

缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压 力。导致系统崩溃。
解决方案：

1. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线 程查询数据和写缓存，其他线程等待。
2. 做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为 短期，A2设置为长期 。
3. 将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值， 比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效 的事件。

缓存穿透
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如 DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫 做缓存穿透。
解决方案：

1. 对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理 缓存。
2. 布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据 会被这个 bitmap 拦截掉，从而避免了对 DB 的查询。

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

1. 永远不过期：物理不过期，但逻辑过期（后台异步线程去刷新）。
2. 使用互斥锁：当缓存失效时，不立即去 load db，先使用如 Redis 的 setnx 去设 置一个互斥锁，当操作成功返回时再进行 load db 的操作并回设缓存，否则重试 get 缓存的 方法。

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(60);
                      get(key);  //重试
              }
          } else {
    
    
              return value;      
          }
 }