BigKey带来的问题

1. 客户端执行命令的时延变大：对大Key进行的慢操作会导致后续的命令被阻塞，从而导致一系列慢查询。

2. 引发操作阻塞：Redis内存达到maxmemory参数定义的上限引发操作阻塞或重要的Key被逐出，甚至引发内存溢出（Out Of Memory）。

3. 容易造成集群分片不均的情况：集群架构下，由于集群采用的是分片设计理念，每个具体的Key只能分布到某一个具体的分片节点上，某个数据分片的内存使用率远超其他数据分片，无法使数据分片的内存资源达到均衡。

4. 导致实例流控：对大Key高频率的读会使得实例出方向带宽被占满，产生大量命令超时或者慢查询，导致流控，致使自身服务变慢，同时易波及相关的服务。

5. 导致主备倒换：对大Key执行危险的DEL操作可能会易造成主库较长时间的阻塞，进而可能引发同步中断或主备倒换。

业务场景

比如互联网系统中需要保存用户最新 1万 个粉丝的业务，比如一个用户个人信息缓存，包括基本资料、关系图谱计数、发 feed 统计等。微博的 feed 内容缓存也很容易出现，一般用户微博在 140 字以内，但很多用户也会发表 1千 字甚至更长的微博内容，这些长微博也就成了大 key

问题实质：

• String本身比较大
• set,hash内个数比较大

具体现象

系统会往Redis里存一个大Key（value值大小有400MB多），Redis是集群版，8GB 8节点的，实际存储时只会将这个key放到一个节点中，这样这一个节点成为了整个系统的瓶颈。而且扩容也无法解决该问题。如图是存储逻辑图

解决思路

主要解决思路就是：平均流量。就是将原来打到一个节点上的流量分摊到所有节点上，提升Redis的性能。

按业务逻辑拆分

比如我们Redis存储的数据是全国的数据集合，那么按照省行政区进行拆分，这样一个Key就能分成34个key。进一步细化还可按照市来拆分，这样会有300多个key，分布到Redis集群上更加均匀

小key可以加后缀：省id，查询时先判定是哪一个省，再拼接key查。