Redis如何避免数据倾斜问题？

相信很多研究大数据的都会接触到“数据倾斜”这个令人头疼的问题。那么数据倾斜到底是什么，redis如何避免这类问题，我们一起来揭开它的神秘面纱。

数据倾斜是啥？

简单的讲，数据倾斜就是我们在计算数据的时候，数据不够分散，大量的数据集中到了一台或者几台机器节点上计算，从而导致这些节点负载多大，而其他节点处于空闲等待中，导致最终整体效率低下。

数据倾斜发生时的现象： 

1、绝大多数task执行得都非常快，但个别task执行的极慢。 
2、原本能正常执行的作业，某天突然爆出OOM（内存溢出）异常。观察异常栈，是我们写的业务代码造成的。

为什么会发生数据倾斜

我们以redis集群为例，redis集群部署方式大部分采用类Twemproxy的方式进行部署：即通过Twemproxy对redis key进行分片计算，将redis key进行分片计算，分配到多个redis实例中的其中一个。

这个时候如果有些redis key访问量远远高于其他的redis key， 导致大部分的访问流量在经过proxy分片之后，都集中访问到某一个redis实例上。我们也把这种访问量高的redis key称为hot key。hot key 通常在不同业务中，存储着不同的热点信息。比如

1.    商城秒杀系统中，最吸引用户眼球，性价比最高的商品信息

2.    知乎或者微博上的热榜

当某些redis key存储的数据量远大于其他key，导致经过分片之后，对应实例内存使用量远大于其他实例，从而内存不足，拖累整个集群的使用。我们把这种数据量较大的key称为big key。big key在不同业务上，通常体现为不同的数据，比如：

1.    论坛中的大型持久盖楼活动；

2.    聊天室系统中热门聊天室的消息列表；

redis基于LFU的hot key发现机制

Least Frequently Used——简称LFU，意为最不经常使用，是redis4.0新增的一类内存逐出策略。

在redis中每个对象都有24 bits空间来记录LRU或者LFU信息。当这24bits被用来记录LFU时，被分成两部分：高16位用来记录访问时间、低8位用来记录访问频率，简称counter（敲黑板：counter并不是一个简单的线性计数器，而是用基于概率的对数计数器来实现，这个感兴趣可以查阅资料了解下）

redis在每次对key进行读写时，会更新LFU的访问时间和counter。OK，接下来如何获取访问频率呢？？？redis提供了OBJECT FREQ子命令来获取LFU信息，但是要注意需要先把内存逐出策略设置为allkeys-lfu或者volatile-lfu，否则会返回错误。

那么redis怎么获取hot key呢？通过scan命令遍历所有key，通过OBJECT FREQ获取访问频率再进行排序，这样就可以得到hot key了。当然，如果只能通过这样的方式那呀太麻烦了。所以在redis 4.0.3 中直接提供了redis-cli的热点key发现功能，执行redis-cli时加上--hotkeys选项即可。

如何处理redis中的hot key问题

1、使用本地缓存

2、利用分片算法的特性，对key进行打散处理

给hot key加上前缀或者后缀，把一个hotkey 的数量变成 redis 实例个数N的倍数M，从而由访问一个 redis key 变成访问 N * M 个redis key。

N*M 个 redis key 经过分片分布到不同的实例上，将访问量均摊到所有实例。

如何处理redis中的big key问题

对big key存储的数据进行拆分：

1）如果big value 是个大json，通过mset的方式，将该key的存储内容分散各个实例中，减小big key对数据量倾斜造成的影响。

2）如果big value 是个大list，可以拆成将list拆成list_1、list_2、list3、listN。。。

结语

这是我的第一篇博客，也是我第一次接触redis数据倾斜，所以本文更多的是在总结归纳前人的观点，以后会开始认真地输出每一篇博客滴O(∩_∩)O哈哈~