Redis大key问题
Posted _瞳孔
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis大key问题相关的知识,希望对你有一定的参考价值。
所谓的大key问题是某个key的value比较大,所以本质上是大value问题。
redis中有常见的几种数据结构,每种结构对大key的定义不同,比如(并不绝对,主要是根据value的成员数量和字节数来确定,业务可以根据自己的场景也确定标准):
- value是String类型时,size超过10KB
- value是ZSET、Hash、List、Set等集合类型时,它的成员数量超过1w个
大key有什么影响:我们都知道,redis的一个典型特征就是:核心工作线程是单线程。单线程中请求任务的处理是串行的,前面完不成,后面处理不了。影响总结如下:
- 执行大key命令的客户端本身,耗时明显增加,甚至超时
- 执行大key相关读取或者删除操作时,会严重占用带宽和CPU,影响其他客户端
- 大key本身的存储带来分布式系统中分片数据不平衡,CPU使用率也不平衡
- 大key有时候也是热key,读取操作频繁,影响面会很大
- 执行大key删除时,在低版本redis中可能阻塞线程
大key是如何产生的:大key的产生往往是业务方设计不合理,没有预见value的动态增长问题
- 一直往value塞数据,没有删除机制,迟早要爆炸
- 数据没有合理做分片,将大key变成小key
如何找到大key
- 增加内存&流量&超时等指标监控:由于大key的value很大,执行读取时可能阻塞线程,这样Redis整体的qps会下降,并且客户端超时会增加,网络带宽会上涨,配置这些报警可以让我们发现大key的存在。
- bigkeys命令:使用bigkeys命令以遍历的方式分析Redis实例中的所有Key,并返回整体统计信息与每个数据类型中Top1的大Key
- redis-rdb-tools:使用redis-rdb-tools离线分析工具来扫描RDB持久化文件,虽然实时性略差,但是完全离线对性能无影响。
- 集成化可视化工具:基于某些公有云或者公司内部架构的redis一般都会有可视化的页面和分析工具,来帮助我们定位大key,当然页面底层也可能是基于bigkeys或者rdb文件离线分析的结果。
如何解决大key问题:根据大key的实际用途可以分为两种情况:
- 可删除:如果发现某些大key并非热key就可以在DB中查询使用,则可以在Redis中删掉
- 当Redis版本大于4.0时,可使用UNLINK命令安全地删除大Key,该命令能够以非阻塞的方式,逐步地清理传入的Key。
- 当Redis版本小于4.0时,避免使用阻塞式命令KEYS,而是建议通过SCAN命令执行增量迭代扫描key,然后判断进行删除。
- 不可删除:
- 当vaule是string时,比较难拆分,则使用序列化、压缩算法将key的大小控制在合理范围内,但是序列化和反序列化都会带来更多时间上的消耗。
- 当value是string,压缩之后仍然是大key,则需要进行拆分,一个大key分为不同的部分,记录每个部分的key,使用multiget等操作实现事务读取。
- 当value是list/set等集合类型时,根据预估的数据规模来进行分片,不同的元素计算后分到不同的片。
以上是关于Redis大key问题的主要内容,如果未能解决你的问题,请参考以下文章