一、什么是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)，删除也是一样，尽量使用优雅的方式来处理。

一、什么是bigkey

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

二、危害

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

1.内存空间不均匀

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

2.超时阻塞

例如，在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.网络拥塞

4.过期删除

5.迁移困难

三、怎么产生的？

一般来说，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

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. 客户端

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. 监控报警

如果想知道具体的客户端，可以使用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就可以了，来看一组数据：

如果你使用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介绍小编放在下面的文档里了，需要获取完整文档用以学习的朋友们可以转发+关注，私信领取，还有更多java源码、笔记、资料哦！

本文链接：https://my.lmcjl.com/post/1913.html

展开阅读全文

一、什么是bigkey

二、危害

1.内存空间不均匀

2.超时阻塞

3.网络拥塞

4.过期删除

5.迁移困难

三、怎么产生的？

四、如何发现

1. redis-cli --bigkeys

3. memory usage

4. 客户端

5. 监控报警

6. 改源码

五、如何删除

1. 字符串

2. hash

3. list

4. set

5. sorted set

六、如何优化

1.拆分

2.本地缓存

7、总结：

一、什么是bigkey

二、危害

1.内存空间不均匀

2.超时阻塞

3.网络拥塞

4.过期删除

5.迁移困难

三、怎么产生的？

四、如何发现

1. redis-cli --bigkeys

3. memory usage

4. 客户端

5. 监控报警

6. 改源码

五、如何删除

1. 字符串

2. hash

3. list

4. set

5. sorted set

六、如何优化

1.拆分

2.本地缓存

7、总结：

相关文章

4 评论

留下您的评论. Cancel reply