Redis BigKey

文章系转载，方便整理和归纳，源文地址：https://zhuanlan.zhihu.com/p/259719757

一、什么是bigkey

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

字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey。
非字符串类型：哈希、列表、集合、有序集合，它们的big体现在元素个数太多。

二、危害

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

1.内存空间不均匀

这样会不利于集群对内存的统一管理，存在丢失数据的隐患。

2.超时阻塞

由于Redis单线程的特性，操作bigkey的通常比较耗时，也就意味着阻塞Redis可能性越大，这样会造成客户端阻塞或者引起故障切换，它们通常出现在慢查询中。

例如，在Redis发现了这样的key，你就等着DBA找你吧。

127.0.0.1:6379> hlen big:hash(integer)
2000000127.0.0.1:6379> hgetall big:hash
1) "a"
2) "1"

3.网络拥塞

bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个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，例如下面就是一次执行结果：

-------- summary -------
Biggest string found 'user:1' has 5 bytes
Biggest list found 'taskflow:175448' has 97478 items
Biggest set found 'redisServerSelect:set:11597' has 49 members
Biggest hash found 'loginUser:t:20180905' has 863 fields
Biggest zset found 'hotkey:scan:instance:zset' has 3431 members
40 strings with 200 bytes (00.00% of keys, avg size 5.00)
2747619 lists with 14680289 items (99.86% of keys, avg size 5.34)
2855 sets with 10305 members (00.10% of keys, avg size 3.61)
13 hashs with 2433 fields (00.00% of keys, avg size 187.15)
830 zsets with 14098 members (00.03% of keys, avg size 16.99)

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

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

建议在从节点执行，因为–bigkeys也是通过scan完成的。
建议在节点本机执行，这样可以减少网络开销。
如果没有从节点，可以使用–i参数，例如(–i 0.1 代表100毫秒执行一次)
–bigkeys只能计算每种数据结构的top1，如果有些数据结构非常多的bigkey，也搞不定，毕竟不是自己写的东西嘛
debug object

再来看一个场景：

你好，麻烦帮我查一下Redis里大于10KB的所有key

您好，帮忙查一下Redis中长度大于5000的hash key

是不是发现用–bigkeys不行了（当然如果改源码也不是太难），但有没有更快捷的方法，Redis提供了debug object ${key}命令获取键值的相关信息：

127.0.0.1:6379> hlen big:hash
(integer) 5000000
127.0.0.1:6379> debug object big:hash
Value at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625559 lru_seconds_idle:2
(1.08s)

其中serializedlength表示key对应的value序列化之后的字节数，当然如果是字符串类型，完全看可以执行strlen，例如：

127.0.0.1:6379> strlen key
(integer) 947394

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

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

debug object bigkey本身可能就会比较慢，它本身就会存在阻塞Redis的可能
建议在从节点执行
建议在节点本地执行
如果不关系具体字节数，完全可以使用scan + strlen|hlen|llen|scard|zcard替代，他们都是o(1)

3. memory usage

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

127.0.0.1:6379> memory usage big:hash
(integer) 318663444

下面我们来对比就可以看出来，当前系统就一个key，总内存消耗是400MB左右，memory usage相比debug object还是要精确一些的。

127.0.0.1:6379> dbsize
(integer) 1
127.0.0.1:6379> hlen big:hash
(integer) 5000000
#约300MB
127.0.0.1:6379> memory usage big:hash
(integer) 318663444
#约85MB
127.0.0.1:6379> debug object big:hash
Value at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625814 lru_seconds_idle:9
(1.06s)
127.0.0.1:6379> info memory
# Memory
used_memory_human:402.16M

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

4. 客户端

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

protected Object readProtocolWithCheckingBroken() {Object o = null;try {o = Protocol.read(inputStream);        return o;}catch(JedisConnectionException exc) {UsefulDataCollector.collectException(exc, getHostPort(), System.currentTimeMillis());        broken = true;throw exc;}finally {if(o != null) {if(o instanceof byte[]) {byte[] bytes = (byte[]) o;if (bytes.length > threshold) {// 做很多事情，例如用ELK完成收集和展示}}}}
}

5. 监控报警

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

如果想知道具体的客户端，可以使用client list命令来查找

redis-cli client list
id=3 addr=127.0.0.1:58500 fd=8 name= age=3978 idle=25 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=26263554 events=r cmd=hgetall

6. 改源码

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

建议的最佳实践：

Redis端与客户端相结合：–bigkeys临时用、scan长期做排除隐患（尽可能本地化）、客户端实时监控。
监控报警要跟上
debug object尽量少用
所有数据平台化
要和开发同学强调bigkey的危害

五、如何删除

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

可以看到对于string类型，删除速度还是可以接受的。但对于二级数据结构，随着元素个数的增长以及每个元素字节数的增大，删除速度会越来越慢，存在阻塞Redis的隐患。所以在删除它们时候建议采用渐进式的方式来完成：hscan、ltrim、sscan、zscan。

如果你使用Redis 4.0+，一条异步删除unlink就解决，就可以忽略下面内容。

1. 字符串

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

del bigkey

2. hash

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

public void delBigHash(String bigKey) {Jedis jedis = new Jedis("127.0.0.1", 6379);// 游标String cursor = "0";while(true) {ScanResult<Map.Entry<String, String>> scanResult = jedis.hscan(bigKey, cursor, new ScanParams().count(100));// 每次扫描后获取新的游标cursor = scanResult.getStringCursor();     // 获取扫描结果List<Entry<String, String>> list = scanResult.getResult();        if(list == null || list.size() == 0) {continue;     }       String[] fields = getFieldsFrom(list);     // 删除多个fieldjedis.hdel(bigKey, fields);     // 游标为0时停止if(cursor.equals("0")) {break;} }   // 最终删除keyjedis.del(bigKey);
}
/*** 获取field数组 */
private String[] getFieldsFrom(List<Entry<String, String>> list) {List<String> fields = new ArrayList<String>();for (Entry<String, String> entry : list) {fields.add(entry.getKey());}return fields.toArray(new String[fields.size()]);
}

3. list

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

public void delBigList(String bigKey) {Jedis jedis = new Jedis("127.0.0.1", 6379);long llen = jedis.llen(bigKey);int counter = 0;int left = 100;while(counter < llen) {// 每次从左侧截掉100个jedis.ltrim(bigKey, left, llen);counter += left;}// 最终删除keyjedis.del(bigKey);
}

4. set

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

public void delBigSet(String bigKey) {Jedis jedis = new Jedis("127.0.0.1", 6379);// 游标String cursor = "0";while(true) {ScanResult<String> scanResult = jedis.sscan(bigKey, cursor, new ScanParams().count(100));// 每次扫描后获取新的游标cursor = scanResult.getStringCursor();       // 获取扫描结果List<String> list = scanResult.getResult();     if(list == null || list.size() == 0) {continue;}                jedis.srem(bigKey, list.toArray(new String[list.size()]));// 游标为0时停止if(cursor.equals("0")) {break;}   }   // 最终删除keyjedis.del(bigKey);}

5. sorted set

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

public void delBigSortedSet(String bigKey) {long startTime = System.currentTimeMillis();    Jedis jedis = new Jedis(HOST, PORT);   // 游标String cursor = "0";while(true) {ScanResult<Tuple> scanResult = jedis.zscan(bigKey, cursor, new ScanParams().count(100));// 每次扫描后获取新的游标cursor = scanResult.getStringCursor();       // 获取扫描结果List<Tuple> list = scanResult.getResult();      if(list == null || list.size() == 0) {continue;     }       String[] members = getMembers(list);       jedis.zrem(bigKey, members);        // 游标为0时停止if(cursor.equals("0")) {break;} }   // 最终删除keyjedis.del(bigKey);
}
public void delBigSortedSet2(String bigKey) {Jedis jedis = new Jedis(HOST, PORT);long zcard = jedis.zcard(bigKey);int counter = 0;int incr = 100;while(counter < zcard) {jedis.zremrangeByRank(bigKey, 0, 100);// 每次从左侧截掉100个counter += incr;}// 最终删除keyjedis.del(bigKey);
}

六、如何优化

1.拆分

big list： list1、list2、…listN

big hash：可以做二次的hash，例如hash%100

日期类：key20190320、key20190321、key_20190322。

2.本地缓存

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

7、总结：

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

Redis BigKey相关推荐

Redis BigKey优化与使用方式
一.什么是BigKey 在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash.list.set.zset)可以存储大约40亿个(2^32-1)个元素,但实际上中如果下面两种情况,我 ...
Redis BigKey介绍
本文已参与「掘力星计划」,赢取创作大礼包,挑战创作激励金. 一.什么是bigkey 在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash.list.set.zset)可以存储大约4 ...
redis bigkey 解决删除大key
大Key会带来的问题如果是集群模式下,无法做到负载均衡,导致请求倾斜到某个实例上,而这个实例的QPS会比较大,内存占用也较多:对于Redis单线程模型又容易出现CPU瓶颈,当内存出现瓶颈时,只能进行 ...
Redis常考点汇总
Redis基础什么是Redis? Redis是一个基于 C 语言开发的开源数据库(BSD 许可),被频繁用于分布式缓存,与传统数据库不同的是 Redis 的数据是存在内存中的(内存数据库),读写速度 ...
redis 必知必会
1.redis九种数据类型 1,string:最基本的数据类型,二进制安全的字符串,最大512M. 2,list:按照添加顺序保持顺序的字符串列表. 3,set:无序的字符串集合, ...
Redis知识点面试题总结
目录 1. 简单介绍一下 Redis 呗! 2. 分布式缓存常见的技术选型方案有哪些? 3. 说一下 Redis ,本地缓存和 Memcached 的区别和共同点 3. 1 共同点 3. 2 区别 : ...
京东前台PC首页系统技术详解
作者:平台研发王文官,来自:京东零售技术公众号前言京东零售系统在2018年实现前中台架构的调整与划分.中台实现基础服务组件开发,前台主要对接用户请求,通过对中台RPC数据的聚合,来满足用户多样化需 ...
6 种 MySQL 数据库平滑扩容方案剖析
更多内容关注微信公众号:fullstack888 1. 扩容方案剖析 1.1 扩容问题在项目初期,我们部署了三个数据库 A.B.C,此时数据库的规模可以满足我们的业务需求.为了将数据做到平均分配,我 ...
技术管理之如何协调加班问题
更多内容关注微信公众号:fullstack888 今天刚好跟一个前同事聊一些以前加班的事情,他跟我吐槽公司加班的问题,但我管理的技术部门一直没怎么加班.就想起来之前为了达成这件事做的一些努力,本来想细 ...
Redis进阶-如何发现和优雅的处理BigKey一二事
文章目录 PreView 模拟写入一个BigKey 如何发现BigKey redis-cli --bigkeys debug object 如何优雅的删除BigKey (lazy delete) 关于 ...