(一)相关定义与背景
1.大key定义:
所谓的大key问题是某个key的value比较大,所以本质上是大value问题
- String类型的Key,它的值为5MB(数据过大)
- List类型的Key,它的列表数量为20000个(列表数量过多)
- ZSet类型的Key,它的成员数量为10000个(成员数量过多)
- Hash格式的Key,它的成员数量虽然只有1000个但这些成员的value总大小为100MB(成员体积过大)
在实际业务中,大Key的判定仍然需要根据Redis的实际使用场景、业务场景来进行综合判断。通常都会以数据大小与成员数量来判定。
一般认为string类型控制在10KB以内,hash、list、set、zset元素个数不要超过10000个。
2.大key产生:
大key的产生往往是业务方设计不合理,没有预见vaule的动态增长问题
- redis数据结构使用不合理,易造成Key的value过大,如使用String类型的Key存放大体积二进制文件型数据
- 业务上线前规划设计不足,没有对Key中的成员进行合理的拆分,造成个别Key中的成员数量过多
- 没有对无效数据进行定期清理,造成如HASH类型Key中的成员持续不断的增加。即一直往value塞数据,却没有删除机制,value只会越来越大
- 使用LIST类型Key的业务消费侧发生代码故障,造成对应Key的成员只增不减
在实际业务中,可能会发生的大key场景:
社交类:粉丝列表,如果某些明星或者大v不精心设计下,必是bigkey;
统计类:例如按天存储某项功能或者网站的用户集合,除非没几个人用,否则必是bigkey;
缓存类:将数据从数据库load出来序列化放到Redis里,这个方式非常常用,但有两个地方需要注意,第一,是不是有必要把所有字段都缓存,第二,有没有相关关联的数据。
3.实际业务背景
现有场景后管系统导入商品相关业务:
对导入商品的excel数据通过EasyExcel工具解析,然后对解析出来的商品信息统一组装到一个大对象,并且放入到redis当中,同时未设置缓存失效时间。
导入的excel表格数据直接关系到商品对象的大小,这就存在excel表格数据非常多的场景下,封装的商品对象就越大,导致每次只要上传大量数据,redis中就会存在大key,对redis并发能力形成潜在影响,由于redis是单线程运行的,如果一次操作的value很大会对整个redis的响应时间造成负面影响,导致IO网络拥塞。
运维反馈:
XXX_IMPORT_XXX相关key已经超过10kb+
List类型的key将近200kb大小
复现环节:
PURCHASE_IMPORT_IDXXX:
测试环境使用Another Redis Desktop Manager工具复现 发现excel导入1条数据152B,4条数据将近500B(如下图),由此可以推断出excel如果导入100条成功数据,其value大小基本约等于10KB,深挖其代码逻辑发现只做了对excel一次性导入不能大于200条,且excel文件大小不能大于5MB前置校验,故而完全可能导致存在10KB~20KB大key
STOCKCHECK_IMPORT_IDXXX:
redisTemplate.opsForList().rightPush(KEY + UUID, Object);采用默认redisTemplate模板类把list数组集合添加进Redis,不断的往后添加list元素且没有失效时间
其中一个list元素就占有将近1.5kb,且如上个大key一样只做了一次性导入不能大于200条,且excel文件大小不能大于5MB前置校验,所以完全存在200KB的超大key产生,采用默认的序列化方式,将等于null的属性也序列化出来就是需要改进的地方
4.造成的影响
总结用几个词概况来说:阻塞请求,网络拥塞,内存增大并且分配不均,过期删除,主从同步切换影响,从而进一步最终会导致我们的线程阻塞,并发量下降,客户端超时,服务端业务成功率下降等。
- 客户端执行命令的时长变慢,Big Key对应的value较大,我们对其进行读写的时候,需要耗费较长的时间,这样就可能阻塞后续的请求处理
- Redis内存达到maxmemory参数定义的上限引发操作阻塞或重要的Key被逐出,甚至引发内存溢出(Out Of Memory)
- 集群架构下,某个数据分片的内存使用率远超其他数据分片,无法使数据分片的内存资源达到均衡
- 读取单value较大时会占用服务器网卡较多带宽,自身变慢的同时可能会影响该服务器上的其他Redis实例或者应用
- 对大Key执行删除操作,易造成主库较长时间的阻塞,进而可能引发同步中断或主从切换
(二)优化方案
根据大key的实际用途可以分为两种情况:可删除和不可删除。
1.删除大key
首先考虑删除大key,如果发现某些大key并非热key就可以在DB中查询使用,则可以在Redis中删掉:
- Redis 4.0及之后版本:您可以通过UNLINK命令安全地删除大Key甚至特大Key,该命令能够以非阻塞的方式,逐步地清理传入的Key。 Redis UNLINK 命令类似与 DEL 命令,表示删除指定的 key,如果指定 key 不存在,命令则忽略。 UNLINK 命令不同与 DEL
命令在于它是异步执行的,因此它不会阻塞。 UNLINK 命令是非阻塞删除,非阻塞删除简言之,就是将删除操作放到另外一个线程去处理。- Redis 4.0之前的版本:建议先通过SCAN命令读取部分数据,然后进行删除,避免一次性删除大量key导致Redis阻塞。 Redis Scan 命令用于迭代数据库中的数据库键。 SCAN 命令是一个基于游标的迭代器,每次被调用之后, 都会向用户返回一个新的游标,
用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数, 以此来延续之前的迭代过程。
根据运维反馈及实际业务场景,主要xxxIMPORT大key分为两种场景:
(1)字符串类型:PURCHASE_IMPORT_IDXXX
(2)List类型:STOCKCHECK_IMPORT_IDXXX 、STOCKADJUST_IMPORT_IDXXX等等
序号 | 接口名称地址 | 业务场景 | 缓存key | 缓存时间 | 缓存内容 | 获取缓存后处理 |
---|---|---|---|---|---|---|
1 | … | 新建采购单-导入商品 | PURCHASE_IMPORT_XXX | 永久生效 | 字符串类型:导入excel商品数据(包括本身自带excel商品,动态数据:查询数据库商品信息,库存、金额等) | 导入后接口返回展示 |
2 | … | 新建入库单-导入商品 | STOCKCHECK_IMPORT_XXX | 永久生效 | list类型:导入excel商品数据(包括本身自带excel商品,动态数据:查询数据库商品信息,库存、金额、部门、仓库等) | 导入后接口返回展示 |
3 | … | … | … | … | … | … |
优化方案:
根据调研的实际场景,之前的大key业务用途范围比较窄,只有导入商品的时候页面回显商品信息,可以考虑上线的时候,晚点直接删除原来所有XXX_IMPORT_IDXXX 的大key,后续继续产生的大key代码,采取下面两种方案优化(压缩和拆分大key)
2.压缩大key
实际业务List类型:STOCKCHECK_IMPORT_XXX等大key采用默认的序列化方式,可以采用压缩法
考虑到使用合适的序列化框架、压缩算法:
- 当vaule是string时,比较难拆分,则使用序列化、压缩算法将key的大小控制在合理范围内,但是序列化和反序列化都会带来更多时间上的消耗
- 当value是string,压缩之后仍然是大key,则需要考虑进行拆分
3.拆分大key
实际业务字符串类型:PURCHASE_IMPORT_XXX大key内部实现逻辑使用ProtoStuff序列化框架实现,考虑到此框架序列化效率非常高,压缩后的格式是二进制文件,内存大小已经相当于最优选择,所以考虑采取拆分手段
- 将一个Big Key拆分为多个key-value这样的小Key,并确保每个key的成员数量或者大小在合理范围内,然后再进行存储,通过get不同的key或者使用mget批量获取。
- 当value是list/set等集合类型时,根据预估的数据规模来进行分片,不同的元素计算后分到不同的片。
4.本地缓存(Caffeine )
可以考虑本地缓存(Caffeine )》Redis》数据库 ,本期文档不实现此方案
(三)实现细节
根据实际业务,主要xxxIMPORT大key的两种场景,技术方案选型落地:
- 字符串类型:PURCHASE_IMPORT_XXX采用拆分key方案。
- list类型:STOCKCHECK_IMPORT_XXX等采用压缩key方案,观察其压缩后大小,如果压缩之后仍然是大key,考虑进一步拆分。
1.PURCHASE_IMPORT_XXX大key处理伪代码(拆分)
监听类:
public class ProductListener extends AnalysisEventListener<ExportExcelVo> {
//省略上面重复代码
//拆分key大小
@Value("${product.splitSize}")
private String splitSize;
//导入商品信息
private List<List<Product>> productList = new ArrayList<>();
/**读取整个Excel完毕后调用*/
@Override
public void doAfterAllAnalysed(AnalysisContext analysisContext) {
//必要校验并组装商品信息数据ProductVO
//重点!
handleMultipleValue(ProductVO);
}
/**拆分多k-v*/
public void handleMultipleValue(ProductVO vo){
Map<String, ProductRO> map= new HashMap<>();
//将必要返回的商品总数量、金额等信息统一封装成keys0
map.put("keys0" + KEY + UUID,ProductRO.builder().adjustNum(po.getAdjustNum())
.priceSum(po.getPriceSum()).build());
//将商品对象内部的list根据实际业务拆分每个key最多包含splitSize条数据
productList = ListUtils.partition(po.getProductList(), splitSize);
for(int i = 1; i <= productList.size(); i++){
ProductRO stock = ProductRO.builder().productList(productList.get(i-1)).build();
map.put("keys" + i + KEY + UUID, stock);
}
//pipeline管道批量添加到redis中并设置10分钟失效
redisHelper.putMultiCacheWithExpireTime(valueMap, 60 * 10L);
//注意此处使用RedisTemplate.opsForValue().multiSet(map)不支持失效时间的设置...又是不断增加key
//虽然可以通过redisTemplate.expire(key, timeout, TimeUnit.SECONDS);循环的去设置map中key失效时间,但不是原子性操作没有意义
}
}
Controller实现:
@RestController
public class ProductFileExcelController {
@PostMapping(value = "api/product/uploadFile")
public Result uploadFile(@RequestParam("file") MultipartFile file) {
ProductListener listener = new ProductListener ();
EasyExcel.read(file.getInputStream(), ExportExcelVo.class, listener).sheet().doRead();
//之前逻辑这里直接取缓存返回
//return Result.success(redisHelper.getCache(key));
//重点!修改后:
List<Product> productList = new ArrayList<>();
ProductRO stock = redisHelper.getCache("keys0" + KEY + UUID, ProductRO.class);
for(int i = 1; i <= productPurchaseDTOListener.getProductList().size(); i++){
ProductRO stockList = redisHelper.getCache("keys" + i + KEY + UUID, ProductRO.class);
productList.addAll(stockList.getProductList());
}
stock.setProductList(productList);
return Result.success(stock);
}
}
Redis工具类实现:
@Component
public class RedisHelper {
@Autowired
private RedisTemplate<String, String> redisTemplate;
//获取key
public <T> T getCache(final String key, Class<T> targetClass) {
byte[] result = (byte[])this.redisTemplate.execute(new RedisCallback<byte[]>() {
@Override
public byte[] doInRedis(RedisConnection connection) throws DataAccessException {
return connection.get(key.getBytes());
}
});
return result != null && result.length != 0 ? ProtoStuffSerializerUtil.deserialize(result, targetClass) : null;
}
//使用管道批量添加
public <T> void putMultiCacheWithExpireTime(Map<String, T> map, final long expireTime) {
this.redisTemplate.executePipelined(new RedisCallback<String>() {
@Override
public String doInRedis(RedisConnection connection) throws DataAccessException {
map.forEach((key, value) -> {
connection.setEx(key.getBytes(), expireTime,
ProtoStuffSerializerUtil.serialize(value));
});
return null;
}
});
}
}
//拆分效果如下图,key0XXX是商品对象公共信息,总金额,数量等
//key1-key5是将10条excel数据拆分成5个key-value 每个key包含2条数据 平均200-300b
上述方法是将大key拆分成多个key-value,这样分拆的意义在于分拆单次操作的压力,将操作压力平摊到多个redis实例中,降低对单个redis的IO影响;
适用于当前的业务场景(该对象需要每次都整存整取),除此之外还有别的拆分方法,比如该对象每次只需要存取部分数据,也可以拆分多个key-value
方案二:将这个存储在一个hash中,每个field代表一个具体的属性,使用hget,hmget来获取部分的value,使用hset,hmset来更新部分属性,此处不做这方面的伪代码实现,有兴趣的小伙伴可以自行研究~~
2.STOCKCHECK_IMPORT_XXX大key处理伪代码:(压缩)
方案一
RedisSerializer使用JdkSerializationRedisSerializer(默认值),需要被序列化Class实现Serializable接口,且主要是不方便人工排查数据,有很多属性为null的值,这些属性的序列化和反序列化完全没有意义,只需要序列化属性值不为空的对象就行,这样不仅能降低机器序列化与反序列化时产生的CPU,减少时间,还能减少Redis内存使用,减少网络开销。所以需要根据实际大key的业务场景可以自定义RedisTemplate序列化方式。
网上有很多这方面的博客,写的很详细可以参考,这里只贴出轮子部分核心代码和结果(采用Jackson2JsonRedisSerializer,也可以使用FastJsonRedisSerializer同样的效果)
@Configuration
public class RedisConfig {
/**
* 修改redisTemplate的序列化方式
* @param factory
* @return
*/
@Bean(name = "redisTemplate")
public RedisTemplate<K, V> redisTemplate(LettuceConnectionFactory factory) {
//创建RedisTemplate对象
RedisTemplate<K, V> template = new RedisTemplate<K, V>();
template.setConnectionFactory(factory);
//设置key的序列化方式
template.setKeySerializer(keySerializer());
template.setHashKeySerializer(keySerializer());
//设置RedisTemplate的Value序列化方式Jackson2JsonRedisSerializer;默认是JdkSerializationRedisSerializer
template.setValueSerializer(valueSerializer());
template.setHashValueSerializer(valueSerializer());
template.afterPropertiesSet();
return template;
}
private RedisSerializer<String> keySerializer() {
return new StringRedisSerializer();
}
private RedisSerializer<Object> valueSerializer() {
Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<Object>(Object.class);
ObjectMapper om = new ObjectMapper();
// 指定要序列化的域,field,get和set,以及修饰符范围,ANY是都有包括private和public
om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
// 指定序列化输入的类型,类必须是非final修饰的,final修饰的类,比如String,Integer等会抛出异常
om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL);
// 解决时间序列化问题
om.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
// 对象属性值为null时,不进行序列化存储
om.setSerializationInclusion(JsonInclude.Include.NON_NULL);
om.registerModule(new JavaTimeModule());
jackson2JsonRedisSerializer.setObjectMapper(om);
return jackson2JsonRedisSerializer;
}
}
//实现后可以看到采用自定义的序列化方式,不仅可以只序列化不为null的属性,且压缩后一条数据大小由原来1.5KB->500B,内存大小接近原来的1/3
//但是由于excel最大可以导入200条数据,按照每条500B换算下来也接近100KB的大key,完全不符合我们的预期,所以考虑的压缩后接着拆分多个k-v
//或者采用更高效的序列化方式
方案二(继续优化)
采取ProtoStuff框架来进一步压缩list类型的key
监听类:
public class ProductListener extends AnalysisEventListener<ExportExcelVo> {
//value库存信息
private List<ProductStockPO> stockPOList = new ArrayList<>();
/**读取整个Excel完毕后调用*/
@Override
public void doAfterAllAnalysed(AnalysisContext analysisContext) {
//必要校验并封装库存信息ProductStockPO
//redisTemplate.opsForList().rightPush(KEY+UUID, ProductStockPO);
//重点!修改后
//添加到redis中并设置10分钟失效
redisHelper.putListCacheWithExpireTime(KEY+UUID, ProductStockPO,60 * 10L);
}
}
Controller实现:
@RestController
public class ProductFileExcelController {
@PostMapping(value = "api/stock/uploadFile")
public Result uploadFile(@RequestParam("file") MultipartFile file) {
ProductListener listener = new ProductListener ();
EasyExcel.read(file.getInputStream(), ExportExcelVo.class, listener).sheet().doRead();
//之前逻辑这里直接取缓存返回
//return Result.success(redisTemplate.opsForList().range(KEY+UUID, 0, -1););
//重点!修改后:
return Result.success(redisHelper.getListCache(KEY+UUID));
}
}
Redis工具类实现:
@Component
public class RedisHelper {
@Autowired
private RedisTemplate<String, String> redisTemplate;
//获取list
public <T> List<T> getListCache(final String key, Class<T> targetClass) {
byte[] result = (byte[])this.redisTemplate.execute(new RedisCallback<byte[]>() {
@Override
public byte[] doInRedis(RedisConnection connection) throws DataAccessException {
return connection.get(key.getBytes());
}
});
return result != null && result.length != 0 ? ProtoStuffSerializerUtil.deserializeList(result, targetClass) : null;
}
//添加list
public <T> boolean putListCacheWithExpireTime(String key, List<T> objList, final long expireTime) {
final byte[] bkey = key.getBytes();
final byte[] bvalue = ProtoStuffSerializerUtil.serializeList(objList);
boolean result = (Boolean)this.redisTemplate.execute(new RedisCallback<Boolean>() {
@Override
public Boolean doInRedis(RedisConnection connection) throws DataAccessException {
connection.setEx(bkey, expireTime, bvalue);
return true;
}
});
return result;
}
}
//发现采用Protostuff序列化框架的确可以更加高效的压缩我们的list数据,压缩1条等比150B,比原始的1.5KB缩小了将近10倍
//但是我们会发现,即使采取了如此高效的压缩手段还是达不到我们的预期,导入200条数据后大小也是相当于20KB,依然是个大key,这不得让我们进一步的考虑拆分...
方案三(压缩+拆分)
监听类:
public class ProductListener extends AnalysisEventListener<ExportExcelVo> {
//存放拆分后数据
private List<List<ProductStockPO>> list = new ArrayList<>();
//重复代码逻辑
@Override
public void doAfterAllAnalysed(AnalysisContext analysisContext) {
//必要校验
list = ListUtils.partition(stockPOList, 2);
Map<String, List<ProductStockPO>> valueMap = new HashMap<>();
for(int i = 1; i <= list.size(); i++){
valueMap.put("keys" + i + KEY + UUID, list.get(i-1));
}
//pipeline管道批量添加到redis中并设置10分钟失效
redisHelperConfig.putMultiListCacheWithExpireTime(valueMap,60 * 10L);
}
}
Controller实现:
@RestController
public class ProductFileExcelController {
@PostMapping(value = "api/stock/uploadFile")
public Result uploadFile(@RequestParam("file") MultipartFile file) {
ProductListener listener = new ProductListener ();
EasyExcel.read(file.getInputStream(), ExportExcelVo.class, listener).sheet().doRead();
List<ProductStockPO> stockList = new ArrayList<>();
for(int i = 1; i <= stockCheckDTOListener.getList().size(); i++){
List<ProductStockPO> list = redisHelperConfig.getListCache("keys" + i + KEY + UUID, ProductStockPO.class);
stockList.addAll(list);
}
return Result.success(stockList);
}
}
Redis工具类实现:
@Component
public class RedisHelper {
@Autowired
private RedisTemplate<String, String> redisTemplate;
//使用管道批量添加list
public <T> void putMultiListCacheWithExpireTime(Map<String, List<T>> map, final long expireTime) {
this.redisTemplate.executePipelined(new RedisCallback<String>() {
@Override
public String doInRedis(RedisConnection connection) throws DataAccessException {
map.forEach((key, value) -> {
connection.setEx(key.getBytes(), expireTime,
ProtoStuffSerializerUtil.serializeList(value));
});
return null;
}
});
}
}
//发现采取压缩后进一步拆分5条数据拆分成3个key,其中2条数据的大小为300B左右,按照最大导入200条数据来算,可以拆分成10key,
//每个key包含20条数据将近3KB大小,符合预期,具体可以拆分多少按照自己实际业务场景来估算
(四)Redis开发规范
1.键值设计
key名设计
(1)【建议】: 可读性和可管理性
以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id
product:stockstock:1
(2)【建议】:简洁性
保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如:
user:{uid}:friends:messages:{mid}简化为u:{uid}🇫🇷m:{mid}。
(3)【强制】:不要包含特殊字符
反例:包含空格、换行、单双引号以及其他转义字符
value设计
(1)【强制】:拒绝bigkey(防止网卡流量、慢查询)
string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。
反例:一个包含200万个元素的list。
非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,
会触发del操作,造成阻塞,而且该操作不会不出现在慢查询中(latency可查))。
(2)【推荐】:选择适合的数据类型。
例如:实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist,但也要注意节省内存和性能之间的平衡)
反例:
set user:1:name tom
set user:1:age 19
set user:1:favor football
正例:
hmset user:1 name tom age 19 favor football
【推荐】:控制key的生命周期,redis不是垃圾桶。
建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期),不过期的数据重点关注idletime。
2.命令使用
1.【推荐】 O(N)命令关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】:禁用命令
禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan的方式渐进式处理。
3.【推荐】合理使用select
redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰。
4.【推荐】使用批量操作提高效率
原生命令:例如mget、mset。
非原生命令:可以使用pipeline提高效率。
但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)。
注意两者不同:
- 原生是原子操作,pipeline是非原子操作。
- pipeline可以打包不同的命令,原生做不到
- pipeline需要客户端和服务端同时支持。
5.【建议】Redis事务功能较弱,不建议过多使用
Redis的事务功能较弱(不支持回滚),而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)
6.【建议】Redis集群版本在使用Lua上有特殊要求:
1.所有key都应该由 KEYS 数组来传递,redis.call/pcall 里面调用的redis命令,key的位置,必须是KEYS array, 否则直接返回error,“-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array”
2.所有key,必须在1个slot上,否则直接返回error, “-ERR eval/evalsha command keys must in same slot”
反例:
– 库存KEY
local stockNumKey = KEYS[1]
– 库存数量
local stockNum = redis.call(“get”, stockNumKey)
正例:
– 库存数量
local stockNum = redis.call(“get”, KEYS[1])