Redis中的缓存设计

缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常处于容错的考虑，如果从存储层查不到数据则不写入缓存层。缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。造成缓存穿透的基本原因有两个:

• 1.自身业务或者数据出现问题
• 2.一些恶意攻击、爬虫等造成大量空命中。

解决方案

1.缓存空对象

String get(String key) {
 
 // 从缓存中获取数据
 String cacheValue = cache.get(key);
 // 缓存为空
 if (StringUtils.isBlank(cacheValue)) {
  // 从存储中获取
  String storageValue = storage.get(key);
  cache.set(key, storageValue);
  
  // 如果存储数据为空，需要设置一个过期时间(300秒)
  if (storageValue == null) {
   cache.expire(key, 64 * 5);
  }
  
  return storageValue;
 } else {
  // 缓存非空
  return cacheValue;
 }
}

2.布隆过滤器

对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在
时，这个值可能不存在;当它说不存在时，那就肯定不存在.布隆过滤器就是一个大型的位数组和几个不一样的无偏hash函数。所谓无偏就是能够把元素的hash值算的比较均匀。向布隆过滤器中添加key时，会使用多个hash函数都会算得一个不同的位置。再把位数组的这几个位置都置为1，就完成了add操作。向布隆过滤器询问key是否存在时，跟add一样，也会把hash的几个位置都算出来，看看位数组中这几个位置是否都为1，只要有一个位为0，那么说明布隆过滤器中这个key不存在。如果都是1，这并不能说明这个key就一定存在，只是极有可能存在，因为这些位置为1可能是因为其他的key存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会很低。这种方法适用于数据命中不高、数据相对固定、实时性低(通常是数据集较大)的应用场景，
代码维护较为复杂，但是缓存空间占用很少

示例

布隆过滤器使用示例,需要引入Redisson依赖

<dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.6.5</version>
 </dependency>

// 初始化布隆过滤器
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
// 初始化布隆过滤器:预计元素为100000000L，误差率为3%
bloomFilter.tryInit(100000000L, 0.03);

// 把所有数据存入布隆过滤器
void init() {
 for (String key : keys) {
  bloomFilter.put(key);
 }
}

String get(String key) {
 // 从布隆过滤器这一级缓存判断下key是否存在
 Boolean exist = bloomFilter.contains(key);
 if (!exist) {
  return "";
 }
 
 // 从缓存中获取数据
 String cacheValue = cache.get(key);
 // 缓存为空
 if (StringUtils.isBlank(cacheValue)) {
  // 从存储中获取
  String storageValue = storage.get(key);
  cache.set(key, storageValue);
  
  // 如果存储数据为空，需要设置一个过期时间(300秒)
  if (storageValue == null) {
   cache.expire(key, 64 * 5);
  }
  
  return storageValue;
 } else {
  // 缓存非空
  return cacheValue;
 }
}

使用布隆过滤器需要把所有数据提前放入布隆过滤器，并且在增加数据时也要往布隆过滤器里放，布隆过滤器缓存过滤伪代码:
注意:布隆过滤器不能删除数据，如果要删除得重新初始化数据

缓存失效(击穿)

由于大批量缓存存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉，对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。

String get(String key) {
 // 从缓存中获取数据
 String cacheValue = cache.get(key);
 // 缓存为空
 if (StringUtils.isBlank(cacheValue)) {
  // 从存储中获取
  String storageValue = storage.get(key);
  cache.set(key, storageValue);
  // 设置一个过期时间(300~600之间的一个随机数)
  int expireTime = new Random().nextInt(300) + 300;
  if (storageValue == null) {
   cache.expire(key, expireTime);
  }
  return storageValue;
 } else {
  // 缓存非空
  return cacheValue;
 }
}

缓存雪崩

缓存雪崩指的是缓存曾支撑不住或宕掉后，流量会像奔逃的野牛一样，打向后端存储层。由于缓存层承载着大量请求，有效地保护了存储层，到那时如果缓存层由于某些原因不能提供服务(比如超大并发过来，缓存层支撑不住，或者由于缓存设计不好，类似大量请求访问bigkey，导致缓存能支撑的并发急剧下降)，于是大量请求都会打到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。

解决方案

预防和解决缓存雪崩问题，可以从三个方面着手:

• 1.保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster
• 2.依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据(例如电商商品属性，用户信息等)时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、控制或是错误提示信息；当业务应用访问的是核心数据(例如电商商品库存)时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取
• 3.提前演练。在项目上线前，演练缓存层宕机后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定

热点缓存key重建优化

开发人员使用"缓存+过期时间"的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害:

• 1.当前key是一个热点key(例如一个热门的娱乐新闻)，并发量非常大
• 2.重建缓存不能在短时间内完成，可能是一个复杂计算。例如复杂的SQL、多次IO、多个依赖等

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。要解决这个问题主要就是要避免大量线程同时重建缓存。我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

String get(String key) {
 
 // 从Redis中获取数据
 String value = redis.get(key);
 // 如果value为空，则开始重构缓存
 if (value == null) {
  String mutexKey = "mutex:key:" + key;
  if (redis.set(mutexKey, "1", "ex 180", "nx") {
   // 从数据源获取数据
   value = db.get(key);
   // 回写Redis,并设置过期时间
   redis.setex(key, timeout, value);
  } else {
   // 其他线程休息50毫秒重试
   Thread.sleep(50);
   return get(key);
  }  
 }

 return value;
      }

缓存与数据库双写不一致

解决方案

• 1.对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可
• 2.就算并发很高，如果业务上能容忍短时间内的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求
• 3.如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁
• 4.也可以阿里开源的canal通过监听数据库的binlog日志即时地去修改缓存，但是引入了新地中间件，增加了系统地复杂度
  

总结:

以上我们针对地都是读多写少的情况加入缓存提高性能，如果写多读多的情况又不能容忍缓存数据不一致，那就没必要加缓存了，可以直接操作数据库。当然，如果数据库扛不住压力，还可以把缓存作为数据读写的主存储，异步将数据同步到数据库，数据库只是作为数据的备份。

放入缓存的数据应该是对实时性、一致性要求不是很高的数据。切记不要为了用缓存，同时又要保证绝对的一致性做大量的过度设计和控制，增加系统复杂性