目录
目前我们项目中，涉及到计数和关联关系，会在redis中存储，我们都是作为单key去保存的， 比
如 用户 :博主 :关注状态 这样的字段会独立保存，但是在有的项目中可能会有人把所有的key，都
作为一个list或者hash对象去保存，那么如此一来， 这个key会非常大占用的内存空间也会很
大， 一旦修改或新增属性，那么会很卡， 甚至带来性能引发的风险问题。
在Redis中， 一个字符串最大为512MB， 一个二级数据结构 （比如hash、list、 set、zset） 可
以存储大约40亿个元素 ，但实际上中 如果下面两种情况， 我可以称之为BigKey：
字符串类型： 单个value值很大， 超过10KB可以认为就是BigKey
非字符串类型： hash、 list、 set、 zset， 它们的big体现在元素个数太多， 比如一个list中有
10万条记录 。 一个hash对象中有1万个属性。
BigKey会导致内存空间不均匀， 不利于集群对内存的统一管理， 可能存在数据丢失的风险。
此外， BigKey也可能导致请求超时或阻塞 。 因为操作BigKey的时间比较耗时， 那么redis基于
数据的一致性， 那么会阻塞， 如此请求容易超时， 导致触发故障。
BigKey越大， 那么每次get请求要产生的网络流量就会更大， 假设一个BigKey为1MB， 客户端
每秒访问量为1000， 那么每秒产生1000MB的流量， 对于普通云服务器来说， 可能就悲剧
了， 如果你采用单机集群的方式来部署， 那么一个BigKey可 能会对其他单实例造成惨烈影
响， 风险很大。
BigKey很大， 那么迁移就会很烦很恶心人， 比如集群hash slot， 会容易导致失败。
像我们现在类似社交类的应用， 或者以前的自媒体。涉及到粉丝的， 那么很容易出现
bigkey。 比如我们把粉丝关联存 redis， 以hash去存， 那么一个流量明星的粉丝， 肯定是一个
BigKey呀。
我们在平时开发过程中， 一定要注意BigKey的产生， key的命名一定要规范， 减少hash、
list、 set、zset的使用 。如果要使用， 那要做拆分， 或者求模拆分 。 比如把一个list哈希为10
份， 那么存取的时候根据用户id求模存取到不同的list中就行， 如此一个大key就被拆为10
份， 可以减少大体积 。 同时也分散了请求到10个key中进行查询。
此外， 如果你要删除bigkey进行重新优化， 建议半夜凌晨去处理， 因为用户请求会比白天少 。
而且尽量采用批量删除的方式会更好。