【HBZ分享】Redis的Bigkey问题

什么是Bigkey

1. 当一个String类型的key的值很大的时候，通常超过10KB，甚至达到MB,GB的级别。 称之为bigkey
2. 当一个hash, list,set, zset 存储元素个数达到1000个以上时，称之为bigkey

Bigkey会引发什么问题？

1. 内存空间不均匀，不利于充分利用各节点系统内存资源。比如3个节点，某个节点突然存储个bigkey，导致这个节点内存占用很大，而其他节点内存占用很少

2. IO和带宽阻塞：Redis单线程操作bigkey通常比较耗时，所以阻塞redis可能性很大。并且假设一个bigkey是1M，客户每秒访问量为1000，那么每秒产生1000M的流量，普通的千兆网卡才128M/s，直接超大延迟甚至不可用了

3. 过期删除：如果bigkey还设置了过期时间，那么此时执行删除如果使用主线程，则会阻塞redis，影响其他命令的正常执行。

引发Bigkey的原因是什么？

1. 大概率是开发人员程序设计不当，对于数据规模预料不清楚造成的
   (1). 社交App: 通篇采用一样的数据存储结构，不区分使用，大V列表和新手列表一样都用list或hash存储，不做任何区分，导致了bigkey(看下面解决方案有相关解决)
   (2). 电商软件：列表页数据只需要展示几个关键字段即可，然而开发人员把整个商品所有信息详情都存到缓存了，导致该key变成了bigkey。
   (3). 业务缓存：整个对象序列化成字符串放到String类型缓存，而不是采用更好的数据结构，比如hash， list等，并且不管这个字段用不用得到都存进去了，也会导致bigkey

如何发现bigkey？

1. 通过redis命令

   // 进入redis容器
   docker exec -it [容器名] /bin/bash
   // 授权并查看各个类型有多少个key， 以及占用空间大小
   redis-cli -a [密码] --bigkeys
   

2. 客户端统计
   (1). 封装jedis客户端， 存储前判断下对象的大小和元素个数，超过对应设置的阈值，就打印相关log
   (2). 结合ELK采集和可视化监控展示

如何解决Bigkey？

1. 删除bigkey操作时：
   (1). bigkey删除不推荐使用del key命令， 推荐用lazy del, 即unlink命令
   原因: 即使用异步延迟释放key内存，把key释放操作放在Background I/O单独的子线程处理，减少删除key对redis主线程的阻塞

2. 选择合适的数据结构
   (1). 多字段对象不要采用String存储, 比如使用hash存储就很好
   (2). 获取的时候使用mget， 只获取需要的key，而不是全量获取

3. 优化数据存储架构
   (1). 比如将大V和新手进行等级表示，比如0-1万粉丝的level = 1，1-10万的level = 2等等…
   (2). 如果是大V用户，可以将大V用户单独存储，或者给另外一个缓存空间，不要和其他普通用户混到一起
   (3). 比如大V可以存到mangoDB，或其他缓存中，小V用户可以正常存储即可
   (4). 因为大V粉丝毕竟还是少数，所以区别对待一下是可以的，不会造成太多的麻烦