Redis bigkey分析
一 现象
某个业务最近2个月每月1号凌晨0点都有业务高峰,但是业务所使用的 Redis 服务 cpu 负载100% ,无法对外提供服务进而影响整体业务访问。
二 分析
2.1 问题分析
因为该业务使用的是云Redis ,我们通过监控看 CPU,QPS ,带宽。
出现问题时系统的QPS 大约为 1200 左右,但是对应时刻的出口带宽竟然达到500MB/s ,猜测该业务使用的Redis 有bigkey。
2.2 验证猜测
因为对应的版本暂不支持日志审计功能。让驻场的同学抓取Redis的统计数据,如下
从统计数据中可以看到top 5 的key 均为大于1MB的可以,而且 第一个hash 类型的key 里面有10w级别的元素。因为Redis的单线程模型,0点时刻业务请求大量访问这些大key 势必造成 CPU 飙高,网卡流量暴涨。
2.3 解决
原因分析到位,剩下的就好办了,对于hash类型的结构,让客户侧的开发对打 key 进行拆分打散。优化之后的单个key 大约88Byte 。等9月1号凌晨观察效果。
三 Redis的 bigkey 有哪些影响
上面分析一个 bigkey的案例,接下来我们看看bigkey到底带来哪些副作用。bigkey 顾名思义是 value 占用的内存空间比较大的key,对于redis而言存在两种类型 :
- 字符串类型:value 大小大于特点值比如 5KB 的string 类型的key。
- 非字符串/集合类型: 比如存储非常多元素的hash, set ,zset,list类型,如本文案例的存储情况。
对于Redis的维护人员而言,bigkey就是 一个不稳定因素,时不时带稳定性风险。
3.1 影响性能
因为 Redis 单线程的工作机制,主线程处理所有key的增删改查。对bigkey的操作耗时增加将阻塞主线程处理其他业务请求,进而影响整体吞吐量。
3.2 影响带宽
前面的案例即是一个例子,单个key 7MB ,如果每秒100次查询,则带来700MB 的带宽,虽然现在大部分是万兆网卡,业务请求量再大一些,网卡也有被打满的风险。
3.3 数据倾斜
对于分片的redis集群,存在bigkey 会导致单个分片数据量远大于其他节点,整体不均衡。如果一个分片空间容量满了,对系统造成不可访问,而且也不能随意扩容,因为不拆分key的情况下扩容,单个分片还是存在数据倾斜。更惨的是,数据量比较大,那么访问就增加,容易形成热点。热点不都是因为数据倾斜导致,数据倾斜会大概率导致热点。
3.4 影响主从同步
Redis Server 的输出大小通常是不可控制的。存在bigkey的时候,就会产生体积庞大的返回数据。另外也有可能因为执行了太多命令,导致产生返回数据的速率超过了往客户端发送的速率,导致服务器堆积大量消息,从而导致输出缓冲区越来越大,占用过多内存,甚至导致系统崩溃。Redis 通过设置client-output-buffer-limit 来保护系统安全。
此时如果主从配置 sentinel,sentinel 会让 slave 继续向 master 发起全量同步请求,然后 buffer 又溢出同步失败,如此反复,会形成复制风暴,这会耗费 master 大量的 CPU、内存、带宽资源,也会让 master 产生阻塞的风险。
案例 https://blog.csdn.net/damanchen/article/details/101075757
四 如何解决大key?
其实就是一个字 "拆"。
- 对于字符串类型的key,我们通常要在业务层面将value的大小控制在10KB左右,如果value确实很大,可以考虑采用序列化算法和压缩算法来处理,推荐常用的几种序列化算法:Protostuff、Kryo或者Fst。
- 对于集合类型的key,我们通常要通过控制集合内元素数量来避免bigKey,通常的做法是将一个大的集合类型的key拆分成若干小集合类型的key来达到目的。
来自 yangyidba公众号