Redis开发规范解析(二)--老生常谈bigkey

发布于 2022-4-16 11:28
浏览
0收藏

去年我写过一个《阿里云Redis开发规范》,在网上转载很多,但其实说心里话,我并不认为写的多好,受制一些客观因素和篇幅,有些不够细致和深入,所以想在公众号里详细解析下,希望对大家有帮助。

 

本篇是第二篇:老生常谈的bigkey

 

原文


【强制】:拒绝bigkey(防止网卡流量、慢查询)

 

string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。

 

反例:一个包含200万个元素的list。

 

非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞,而且该操作不会出现在慢查询中(latency可查)),

 

解析

 

来看一段对话:这是之前公司同事问我的?他对我的答案很吃惊而且有点怀疑。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

希望通过本篇文章能够解答他的疑问。

 

一、什么是bigkey


在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash、list、set、zset)可以存储大约40亿个(2^32-1)个元素,但实际上中如果下面两种情况,我就会认为它是bigkey。

 

1.字符串类型:它的big体现在单个value值很大,一般认为超过10KB就是bigkey。

 

2.非字符串类型:哈希、列表、集合、有序集合,它们的big体现在元素个数太多。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

二、危害


bigkey可以说就是Redis的老鼠屎,具体表现在:

 

1.内存空间不均匀:这样会不利于集群对内存的统一管理,存在丢失数据的隐患,下图中的三个节点是同属于一个集群,键值个数也接近,但内存容量相差较多。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区2.超时阻塞:由于Redis单线程的特性,操作bigkey的通常比较耗时,也就意味着阻塞Redis可能性越大,这样会造成客户端阻塞或者引起故障切换,它们通常出现在慢查询中。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区例如,在Redis发现了这样的key,你就等着DBA找你吧。。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区3.网络拥塞:


bigkey也就意味着每次获取要产生的网络流量较大,假设一个bigkey为1MB,客户端每秒访问量为1000,那么每秒产生1000MB的流量,对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾,而且一般服务器会采用单机多实例的方式来部署,也就是说一个bigkey可能会对其他实例造成影响,其后果不堪设想。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

4. 过期删除


有个bigkey,它安分守己(只执行简单的命令,例如hget、lpop、zscore等),但它设置了过期时间,当它过期后,会被删除,如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes),就会存在阻塞Redis的可能性,而且这个过期删除不会从主节点的慢查询发现(因为这个删除不是客户端产生的,是内部循环事件,可以从latency命令中获取或者从slave节点慢查询发现)。

 

5. 迁移困难


当需要对bigkey进行迁移(例如Redis cluster的迁移slot),实际上是通过migrate命令来完成的,migrate实际上是通过dump + restore + del三个命令组合成原子命令完成,如果是bigkey,可能会使迁移失败,而且较慢的migrate会阻塞Redis。

 

三、怎么产生的?


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

 

(1) 社交类:粉丝列表,如果某些明星或者大v不精心设计下,必是bigkey。

 

(2) 统计类:例如按天存储某项功能或者网站的用户集合,除非没几个人用,否则必是bigkey。

 

(3) 缓存类:将数据从数据库load出来序列化放到Redis里,这个方式非常常用,但有两个地方需要注意,第一,是不是有必要把所有字段都缓存,第二,有没有相关关联的数据。

 

例如我之前遇到过一个例子,该同学将某明星一个专辑下所有视频信息都缓存一个巨大的json中,造成这个json达到6MB,后来这个明星发了一个官宣。。。这个我就不多说了,领盒饭去吧。

 

四、如何发现


1. redis-cli --bigkeys


redis-cli提供了--bigkeys来查找bigkey,例如下面就是一次执行结果:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

可以看到--bigkeys给出了每种数据结构的top 1 bigkey,同时给出了每种数据类型的键值个数以及平均大小。

 

--bigkeys对问题的排查非常方便,但是在使用它时候也有几点需要注意。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区2. debug object


再来看一个场景:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区是不是发现用--bigkeys不行了(当然如果改源码也不是太难),但有没有更快捷的方法,Redis提供了debug object ${key}命令获取键值的相关信息:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区其中serializedlength表示key对应的value序列化之后的字节数,当然如果是字符串类型,完全看可以执行strlen,例如:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

这样你就可以用scan + debug object的方式遍历Redis所有的键值,找到你需要阈值的数据了。

 

但是在使用debug object时候一定要注意以下几点:

 

(1) debug object bigkey本身可能就会比较慢,它本身就会存在阻塞Redis的可能:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

(2) 建议在从节点执行

(3) 建议在节点本地执行

(4) 如果不关系具体字节数,完全可以使用scan + strlen|hlen|llen|scard|zcard替代,他们都是o(1)

 

3 memory usage


上面的debug object可能会比较危险、而且不太准确(序列化后的长度),有没有更准确的呢?Redis 4.0开始提供memory usage命令可以计算每个键值的字节数(自身、以及相关指针开销,具体的细节后面有文章会分析),例如下面是一次执行结果:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区下面我们来对比就可以看出来,当前系统就一个key,总内存消耗是400MB左右,memory usage相比debug object还是要精确一些的。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

如果你使用Redis 4.0+,你就可以用scan + memory usage(pipeline)了,而且很好的一点是,memory不会执行很慢,当然依然是建议从节点 + 本地 。

 

4.客户端


上面三种方式都有一个问题,就是马后炮,如果想很实时的找到bigkey,一方面你可以试试修改Redis源码,还有一种方式就是可以修改客户端,以jedis为例,可以在关键的出入口加上对应的检测机制,例如以Jedis的获取结果为例子:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区例如下面就是两个功能:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区5.监控报警


bigkey的大操作,通常会引起客户端输入或者输出缓冲区的异常,Redis提供了info clients里面包含的客户端输入缓冲区的字节数以及输出缓冲区的队列长度,可以重点关注下:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区如果想知道具体的客户端,可以使用client list命令来查找

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

6.改源码


这个其实也是能做的,但是各方面成本比较高,对于一般公司来说不适用。

 

我个人的最佳实践就是:


(1) Redis端与客户端相结合:--bigkeys临时用、scan长期做排除隐患(尽可能本地化)、客户端实时监控。

 

(2) 监控报警要跟上

 

(3) debug object尽量少用

 

(4) 所有数据平台化

 

(5) 要和开发同学强调bigkey的危害

 

五、如何删除


如果发现了bigkey,而且确认是垃圾是不是直接del就可以了,来看一组数据:

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区可以看到对于string类型,删除速度还是可以接受的。但对于二级数据结构,随着元素个数的增长以及每个元素字节数的增大,删除速度会越来越慢,存在阻塞Redis的隐患。所以在删除它们时候建议采用渐进式的方式来完成:hscan、ltrim、sscan、zscan。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区1. 字符串:


一般来说,对于string类型使用del命令不会产生阻塞。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区2. hash


使用hscan命令,每次获取部分(例如100个)field-value,在利用hdel删除每个field(为了快速可以使用pipeline)。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区3. list


Redis并没有提供lscan这样的API来遍历列表类型,但是提供了ltrim这样的命令可以渐进式的删除列表元素,直到把列表删除。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区4. set


使用sscan命令,每次获取部分(例如100个)元素,在利用srem删除每个元素。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区5. sorted set


使用zscan命令,每次获取部分(例如100个)元素,在利用zremrangebyrank删除元素。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

六、如何优化


1. 拆


big list: list1、list2、...listN

 

big hash:可以做二次的hash,例如hash%100

 

日期类:key20190320、key20190321、key_20190322。

Redis开发规范解析(二)--老生常谈bigkey-开源基础软件社区

2. 本地缓存


减少访问redis次数,降低危害,但是要注意这里有可能因此本地的一些开销(例如使用堆外内存会涉及序列化,bigkey对序列化的开销也不小)

 

总结:


由于开发人员对Redis的理解程度不同,在实际开发中出现bigkey在所难免,重要的能通过合理的检测机制及时找到它们,进行处理。作为开发人员应该在业务开发时不能将Redis简单暴力的使用,应该在数据结构的选择和设计上更加合理,例如出现了bigkey,要思考一下可不可以做一些优化(例如二级索引)尽量的让这些bigkey消失在业务中,如果bigkey不可避免,也要思考一下要不要每次把所有元素都取出来(例如有时候仅仅需要hmget,而不是hgetall),删除也是一样,尽量使用优雅的方式来处理。

标签
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐