1、什么是bigkey
在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）能够存储大约40亿个(2^32-1)个元素，但实际上中若是下面两种状况，我就会认为它是bigkey。java
- 字符串类型：它的big体如今单个value值很大，通常认为超过10KB就是bigkey。
- 非字符串类型：哈希、列表、集合、有序集合，它们的big体如今元素个数太多。
2、危害
bigkey能够说就是Redis的老鼠屎，具体表如今：redis
1.内存空间不均匀
这样会不利于集群对内存的统一管理，存在丢失数据的隐患。数据库
2.超时阻塞
因为Redis单线程的特性，操做bigkey的一般比较耗时，也就意味着阻塞Redis可能性越大，这样会形成客户端阻塞或者引发故障切换，它们一般出如今慢查询中。json
例如，在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。网络
3、怎么产生的？
通常来讲，bigkey的产生都是因为程序设计不当，或者对于数据规模预料不清楚形成的，来看几个：数据结构
(1) 社交类：粉丝列表，若是某些明星或者大v不精心设计下，必是bigkey。异步
(2) 统计类：例如按天存储某项功能或者网站的用户集合，除非没几我的用，不然必是bigkey。
(3) 缓存类：将数据从数据库load出来序列化放到Redis里，这个方式很是经常使用，但有两个地方须要注意:
- 第一，是否是有必要把全部字段都缓存
- 第二，有没有相关关联的数据
例如遇到过一个例子，该同窗将某明星一个专辑下全部视频信息都缓存一个巨大的json中，形成这个json达到6MB，后来这个明星发了一个官宣
4、如何发现
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的危害
5、如何删除
若是发现了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); // 删除多个field
jedis.hdel(bigKey, fields); // 游标为0时中止
if(cursor.equals("0")) {
break;
} } // 最终删除key
jedis.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; } // 最终删除key jedis.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;
} } // 最终删除key
jedis.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;
} } // 最终删除key
jedis.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;
}
// 最终删除key
jedis.del(bigKey);
}
6、如何优化
1.拆分
big list： list一、list二、...listN
big hash：能够作二次的hash，例如hash%100
日期类：key20190320、key2019032一、key_20190322。
2.本地缓存
减小访问redis次数，下降危害，可是要注意这里有可能所以本地的一些开销（例如使用堆外内存会涉及序列化，bigkey对序列化的开销也不小）
七、总结：
因为开发人员对Redis的理解程度不一样，在实际开发中出现bigkey在所不免，重要的能经过合理的检测机制及时找到它们，进行处理。做为开发人员应该在业务开发时不能将Redis简单暴力的使用，应该在数据结构的选择和设计上更加合理，例如出现了bigkey，要思考一下可不能够作一些优化(例如二级索引)尽可能的让这些bigkey消失在业务中，若是bigkey不可避免，也要思考一下要不要每次把全部元素都取出来(例若有时候仅仅须要hmget，而不是hgetall)，删除也是同样，尽可能使用优雅的方式来处理。
因为篇幅限制，更多的Redis介绍小编放在下面的文档里了，须要获取完整文档用以学习的朋友们能够转发+关注，私信领取，还有更多java源码、笔记、资料哦！