Redis性能优化

小咪咪 2022-12-23 07:27 251阅读 0赞

## 1.高并发电商架构 ##

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

## 2.缓存常见问题 ##

#### 2.1 缓存穿透 ####

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

问题原因:

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

解决方案:  
① : 缓存空对象

例:

// 从缓存中获取数据 
    String value = Redis.get(key);
    // 缓存为空 
    if (StringUtils.isBlank(value)) { 
    // 从存储中获取 
    String mysqlValue = MySQL.get(key);
    //设置成内存中
    Redis.set(key,mysqlValue);
    // 如果存储数据为空， 需要设置一个过期时间
    if (storageValue == null) { 
      Redis.expire(key, 60 * 5); 
       }
       return mysqlValue;
    }else{ 
    // 缓存非空 
    return value;
     }
    }

② : 布隆过滤器

布隆过滤器（Bloom Filter）是由布隆（Burton Howard Bloom）在1970年提出的。它实际上是由一个很长的二进制向量和一系列随机映射函数组成，布隆过滤器可以用于检索一个元素是否在一个集合中。

优点是空间效率和查询时间都远远超过一般的算法

缺点是有一定的误识别率（假正例False positives，即Bloom Filter报告某一元素存在于某集合中，但是实际上该元素并不在集合中）和删除困难，但是没有识别错误的情形（即假反例False negatives，如果某个元素确实没有在该集合中，那么Bloom Filter 是不会报告该元素存在于集合中的，所以不会漏报）。

注意：布隆过滤器不能删除数据，如果要删除得重新初始化数据。

基本特性:

*  布隆过滤器说某个值存在时，这个值可能不存在
 *  布隆过滤器说某个值不存在时，那就肯定不存在

基本原理:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center 1]  
布隆过滤器就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。

向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就 完成了 add 操作。

向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组 比较稀疏，这个概率就会比较少，如果这个位数组比较拥挤，这个概率就会提高。

这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为 复杂， 但是缓存空间占用很少。

Redisson实现布隆过滤器:

//构造Redisson
    Config config = new Config();
    config.useSingleServer().setAddress("redis://localhost:6379");
    RedissonClient redisson = Redisson.create(config);
    
    RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");
    //初始化布隆过滤器.参数:预计元素为100000000L,误差率为3%,根据这两个参数会计算出底层的bit数组大小
    bloomFilter.tryInit(100000000L,0.03);
    //向布隆过滤器中添加key
    bloomFilter.add("xxx");
    
    //判断key是否在布隆过滤器中
    Boolean flag = bloomFilter.contains("xxx");

布隆过滤器结合缓存空对象做Redis优化:

//初始化布隆过滤器 
    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 value = Redis.get(key);
    	// 缓存为空 
    	if (StringUtils.isBlank(value)) { 
    	// 从存储中获取 
    	String mysqlValue = MySQL.get(key);
    	//设置成内存中
    	Redis.set(key,mysqlValue);
    	// 如果存储数据为空， 需要设置一个过期时间
    	if (storageValue == null) { 
    	  Redis.expire(key, 60 * 5); 
    	   }
    	   return mysqlValue;
    	}else{ 
    	// 缓存非空 
    	return value;
    	 }
    	}
    }

#### 2.2 缓存失效(击穿) ####

由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉.

解决办法:

建议将数据的缓存过期时间设置为一个时间段内的不同时间。

#### 2.3 缓存雪崩 ####

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

预防方案:

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

## 3.Redis其他问题 ##

#### 3.1 热点缓存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 = MySQL.get(key);
    			// 回写Redis， 并设置过期时间
    			redis.setex(key, timeout, value);
    			// 删除key_mutex 
    			 redis.delete(mutexKey);
    		}// 其他线程休息50毫秒后重试
    		else { 
    			Thread.sleep(50);
    			get(key);
    		}
    	}
    	return value;
    }

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

线程执行时间相差过大而导致的不一致:

线程1写入一个数据库存等于30,然后去更新缓存.在次期间,线程2并发执行,写入库存等于20,并成功更新缓存.  
所以此时的情况是:数据库库存等于20,缓存库存等于20  
当线程1的更新缓存执行完毕后,缓存中的库存就成了30  
此时,数据库中库存等于20,缓存中库存等于30  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center 2]

读写并发不一致导致的双写不一致:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center 3]

解决方案:

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

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

#### 3.3 bigkey ####

产生:

一般来说，bigkey的产生都是由于程序设计不当，或者对于数据规模预料不清楚造成的  
例:

*  社交类：粉丝列表，如果某些明星或者大v不精心设计下，必是bigkey
 *  统计类：例如按天存储某项功能或者网站的用户集合，除非没几个人用，否则必是bigkey
 *  缓存类：将数据从数据库读取出来序列化放到Redis里的一个key下

带来的影响:

*  导致redis阻塞
 *  网络拥塞bigkey也就意味着每次获取要产生的网络流量较大,假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000MB的流量.
 *  过期删除.当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞Redis的可能性。

优化方案:

*  拆分.例如,big list可以拆分成 list1、list2、…listN
 *  取和删除元素时,不需要把所有的元素都取/删除.

#### 3.4 连接池参数优化 ####

参数解析:

<table> 
 <thead> 
  <tr> 
   <th>序号</th> 
   <th>参数名</th> 
   <th>含义</th> 
   <th>默认值</th> 
   <th>推荐值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>maxTotal</td> 
   <td>资源池中最大连接数</td> 
   <td>8</td> 
   <td>需参考业务</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>maxIdle</td> 
   <td>资源池允许最大空闲的连接数</td> 
   <td>8</td> 
   <td>需参考业务</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>minIdle</td> 
   <td>资源池确保最少空闲的连接数</td> 
   <td>0</td> 
   <td>需参考业务</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>blockWhenExhausted</td> 
   <td>当资源池用尽后，调用者是否要等待。只有当为true时，下面的maxWaitMillis才会生效</td> 
   <td>true</td> 
   <td>建议使用默认值</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>maxWaitMillis</td> 
   <td>当资源池连接用尽后,调用者的最大等待时间(单位为毫秒)</td> 
   <td>-1：表示永不超时</td> 
   <td>不建议使用默认值</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>testOnBorrow</td> 
   <td>向资源池借用连接时是否做连接有效性检测(ping)，无效连接会被移除</td> 
   <td>false</td> 
   <td>业务量很大时候建议 设置为false(多一次 ping的开销)</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>testOnReturn</td> 
   <td>向资源池归还连接时是否做连接有效性检测(ping)，无效连接会被移除</td> 
   <td>false</td> 
   <td>业务量很大时候建议设置为false(多一次 ping的开销)</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>jmxEnabled</td> 
   <td>是否开启jmx监控，可用于监控</td> 
   <td>true</td> 
   <td>建议开启，但应用本 身也要开启</td> 
  </tr> 
 </tbody> 
</table>

参数优化:

maxTotal：最大连接数

需要考虑的因素:

*  业务希望Redis并发量
 *  客户端执行命令时间
 *  Redis资源：例如 nodes(例如应用个数) \* maxTotal 是不能超过redis的最大连接数 maxclients
 *  资源开销：例如虽然希望控制空闲连接(连接池此刻可马上使用的连接)，但是不希望因为连接池的频繁释放创建连接造成不必靠开销

maxIdle:资源池允许最大空闲的连接数  
minIdle:资源池确保最少空闲的连接数

maxIdle实际上才是业务需要的最大连接数，maxTotal是为了给出余量，所以maxIdle不要设置 过小，否则会有new Jedis(新连接)开销

**连接池的最佳性能是maxTotal = maxIdle**，这样就避免连接池伸缩带来的性能干扰。但是如果 并发量不大或者maxTotal设置过高，会导致不必要的连接资源浪费。一般推荐maxIdle可以设置 为按上面的业务期望QPS计算出来的理论连接数，maxTotal可以再放大一倍。

minIdle（最小空闲连接数），与其说是最小空闲连接数，不如说是"至少需要保持的空闲连接 数"，在使用连接的过程中，如果连接数超过了minIdle，那么继续建立连接，如果超过了 maxIdle，当超过的连接执行完业务后会慢慢被移出连接池释放掉

***连接池预热:***

如果系统启动完马上就会有很多的请求过来，那么可以给redis连接池做预热，比如快速的创建一 些redis连接，执行简单命令，类似ping()，快速的将连接池里的空闲连接提升到minIdle的数量

List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());
    
    for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) { 
    	Jedis jedis = null;
    	try { 
    		jedis = pool.getResource();
    		minIdleJedisList.add(jedis);
    		jedis.ping();
    	} catch (Exception e) { 
    		logger.error(e.getMessage(), e);
    	}finally { 
    		//注意，这里不能马上close将连接还回连接池，否则最后连接池里只会建立1个连接
    		//jedis.close();
    	}
    }
    
    //统一将预热的连接还回连接池
    for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) { 
    	Jedis jedis = null;
    	try{ 
    		jedis = minIdleJedisList.get(i);
    		 //将连接归还回连接池 
    		 jedis.close();
    	}catch (Exception e) {  			
    		logger.error(e.getMessage(), e); 
    	 } finally { 
    	  }
    
    }

#### 3.5 Redis对于过期键的清除策略 ####

1.  被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期 key
2.  主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
3.  当前已用内存超过maxmemory限定时，触发主动清理策略

主动清理策略在Redis 4.0 之前一共实现了 6 种内存淘汰策略，在 4.0 之后，又增加了 2 种策 略，总共8种：

###### 对设置了过期时间的key做处理： ######

1.  volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除
2.  volatile-random：就像它的名称一样，在设置了过期时间的键值对中，进行随机删除
3.  volatile-lru：会使用 LRU 算法筛选设置了过期时间的键值对删除
4.  volatile-lfu：会使用 LFU 算法筛选设置了过期时间的键值对删除

###### 针对所有的key做处理： ######

1.  allkeys-random：从所有键值对中随机选择并删除数据
2.  allkeys-lru：使用 LRU 算法在所有数据中进行筛选删除
3.  allkeys-lfu：使用 LFU 算法在所有数据中进行筛选删除

###### 不处理： ######

1.  noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作

LRU 算法（Least Recently Used，最近最少使用）:  
淘汰很久没被访问过的数据，以最近一次访问时间作为参考

LFU 算法（Least Frequently Used，最不经常使用）:  
淘汰最近一段时间被访问次数最少的数据，以次数作为参考。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/bd1e394994b04d7fa6ba23dd347f4cf5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/d712a983fce34406a3364f74da7a17f7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/7cfa1f294c7d436f80578a72cd88b99f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1ZWd1Y2hlbg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/b1efc15cfb774c7f8f03ff48c5326beb.png