Redis（六）缓存设计缓存穿透存空对象布隆过滤器用redisson实现布隆过滤器缓存失效(击穿) 缓存雪崩热点缓存key重建优化缓存与数据库双写不一致

缺乏、安全感 2022-09-12 06:45 115阅读 0赞

### 文章目录 ###

*  前言
 *  缓存穿透
 *   *  存空对象
     *  布隆过滤器
     *  用redisson实现布隆过滤器
 *  缓存失效(击穿)
 *  缓存雪崩
 *  热点缓存key重建优化
 *  缓存与数据库双写不一致
 *   *  解决方案：

--------------------

# 前言 #

本章主要讲解使用缓存可能出现的问题，如何进行预防。

--------------------

# 缓存穿透 #

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

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

缓存穿透问题解决方案：

## 存空对象 ##

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, 60 * 5);
    	 }
    		 return storageValue;
    	 } else { 
    		 // 缓存非空
    		 return cacheValue;
    	}
     }

## 布隆过滤器 ##

对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_20_color_FFFFFF_t_70_g_se_x_16]

布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。  
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。  
向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个key 就一定存在，只是极有可能存在。因为这些位被置为 1 可能是因为其它的 key 存在所致。  
如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂， 但是缓存空间占用很少。

## 用redisson实现布隆过滤器 ##

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

public class BllomTest
    { 
        public static void main(String[] args) { 
            Config config = new Config();
            config.useSingleServer().setAddress("redis://192.168.200.139:6379");
            //构造Redisson
            RedissonClient redisson = Redisson.create(config);
            RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
            //初始化布隆过滤器：预计元素为100000000L,误差率为3%,根据这两个参数会计算出底层的bit数组大小
            bloomFilter.tryInit(100000L,0.03);
            //将zhuge插入到布隆过滤器中
            bloomFilter.add("antry");
            bloomFilter.add("niuniu");
    
            //判断下面号码是否在布隆过滤器中
            System.out.println(bloomFilter.contains("guojia"));//false
            System.out.println(bloomFilter.contains("niuniu"));//true
            System.out.println(bloomFilter.contains("antry"));//true
        }
    }

# 缓存失效(击穿) #

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

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，导致缓存能支撑的并发急剧下降)， 于是大量请求都会打到存储层， 存储层的调用量会暴增， 造成存储层也会级联宕机的情况。

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

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

# 热点缓存key重建优化 #

。开发人员使用“缓存+过期时间”的策略既可以加速数据读写， 又保证数据的定期更新， 这种模式基本能够满足绝大部分需求

但是有两个问题如果同时出现， 可能就会对应用造成致命的危害：

*  当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
 *  重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的SQL、 多次IO、 多个依赖等。  
    在缓存失效的瞬间， 有大量线程来重建缓存， 造成后端负载加大， 甚至可能会让应用崩溃。

要解决这个问题主要就是要避免大量线程同时重建缓存。

我们可以利用互斥锁来解决，此方法只允许一个线程重建缓存， 其他线程等待重建缓存的线程执行完， 重新从缓存获取数据即可。

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

# 缓存与数据库双写不一致 #

双写不一致情况  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_13_color_FFFFFF_t_70_g_se_x_16]  
读写并发不一致

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_20_color_FFFFFF_t_70_g_se_x_16 1]

## 解决方案： ##

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

以上我们针对的都是读多写少的情况加入缓存提高性能，如果写多读多的情况又不能容忍缓存数据不一致，那就没必要加缓存了，可以直接操作数据库。放入缓存的数据应该是对实时性、一致性要求不是很高的数据。切记不要为了用缓存，同时又要保证绝对的一致性做大量的过度设计和控制，增加系统复杂性！

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/30a3aafc97a94d3c9d3eaebf18e909e9.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_13_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/63af85061a0a40f7a8a32ccba059b08c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/002a318792054e108decc33fe45a862a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAVF9BbnRyeQ_size_11_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/308b9a6323914de289834975863545ba.png