🍁 作者:知识浅谈,CSDN签约讲师,CSDN原力作者,后端领域优质创作者,热爱分享创作
💒 公众号:知识浅谈
📌 擅长领域:后端全栈工程师、爬虫、ACM算法
🔥 联系方式vx:zsqtcc
前段时间,看到这个BigKey的问题,因为理解的模糊不清的不太舒服,于是就有了下文的总结。
正菜来了🛴🛴🛴
BigKey的具体表现是redis中的key对应的value很大,占用的redis空间比较大,本质上是大value问题。
常几个常见的例子:
● 对于String类型的value值,值超过5MB(数据值过大);
● 对于List类型的value值,含有的成员数量为20000个(成员数量多);
● 对于ZSet类型的value值,含有的成员数量为10000个(成员数量多);
● 对于Hash格式的value值,含有的成员数量1000个,但所有成员变量的总value值大小为100MB(成员总的体积过大);
针对BigKey进行拆分
通过将BigKey拆分成多个小Key的键值对,并且拆分后的对应的value大小和拆分成的成员数量比较合理,然后进行存储即可,在获取的时候通过get不同的key或是用mget批量获取存储的键值对。
清理无效的数据
这个主要是针对像是list和set这种类型,在使用的过程中,list和set中对应的内容不断增加,但是由于之前存储的已经是无效的了,需要定时的对list和set进行清理。
压缩对应的BigKey的value
可以通过序列化或者压缩的方法对value进行压缩,是其变为较小的value,但是如果压缩之后如果对应的value还是特别大的话,就需要使用拆分的方法进行解决了。
监控Redis中内存,带宽,增长率
通过监控系统,监控redis中的内存占用大小和网络带宽的占用大小,以及固定时间内的内存占用增长率,当超过设定的阈值的时候,进行报警通知处理。
温馨提醒:这个有点多,请仔细看下去
相对于BigKey,热Key也是一个值得关注的点。
热key:对于Redis中的某个Key接收到的QPS、显著高于其它Key,我们称之为热Key,常见的热Key如
热key产生的问题:热Key因为频繁的访问。占用大量的Redis CPU时间使其性能变差并影响其它请求;
热key的解决方案:可以使用使用读写分离架构,如果热Key的产生来自于读请求,那么读写分离是一个很好的解决方案。在使用读写分离架构时可以通过不断的增加从节点来降低每个Redis实例中的读请求压力。
对于BigKey的问题的原因:也就是键值对中对应的value比较大,对于BigKey问题的发现可以通过第三方工具或者自带的命令进行扫描发现,通过拆分,压缩,清理等方法对这些大value进行处理即可。