Redis的Cluster集群数据倾斜

Redis的Cluster集群数据倾斜

前言

Redis的Cluster集群又被称为切片集群，Cluster的所有实例都是主节点，集群采用哈希槽（hash Slot）来处理实例之间的映射关系，在集群中总共有16384个哈希槽，默认形式是将16384个哈希槽分配给所有的节点，每个实例节点分配一段哈希槽类似数据分区，每个键值按照CRC16算法得到哈希值再将其对16384取模**CRC16（key）mod 16384 **通过最终的结果得到key值存在的哈希槽位置，结构图如下所示

这样做的好处是多个节点提供读写服务，同时采用Cluster数据分片没有冗余数据保存，还不需要配置哨兵集群可以由Cluster集群内部选举保证高可用，由此可见采用Cluster集群优势很大，但Cluster集群很容易导致一个问题数据倾斜。

数据倾斜一般分为两种情况

• **数据量倾斜：**实例的数据分配不均匀，导致某个实例上的数据特别多，导致该实例访问压力大。

• **数据访问倾斜：**实例数据分布均匀，但是热点数据集中在某个实例上，导致该实例数据访问压力大。

数据倾斜产生的后果就是实例处理请求的压力巨大，处理请求的速度慢，甚至可能导致实例崩溃，那么如何避免呢？这就要分析这两种情况产生的具体原因。

数据量倾斜

bigkey导致倾斜

bigkey产生的原因一般是value值很大（String类型）或者value保存大量的集合数据（集合类型）这样就会导致实例内存消耗过多，对bigkey的操作会导致实例IO线程阻塞，如果bigkey访问频繁那么将影响实例其它键值的访问，所以我们在业务中应该尽量避免bigkey的产生。

Slot哈希槽分配不均衡

Slot哈希槽可以自动分配或者手动分配，如果自动分配那么会均匀的分配给每一个实例，如下所示

但是生产集群环境机器不一定都是一样的配置，也就是说有些机器性能好可能会多分配点Slot哈希槽，有些机器性能差就需要少分配点Slot哈希槽，而在分配过程中我们可能不知道数据和哈希槽的对应关系，那么很可能就会将大量数据所属Slot哈希槽分配给同一个实例，这样就造成了数据倾斜。

Hash Tag导致数据倾斜

什么是Hash Tag呢？

Hash Tag是指加在键值对key的一对花括号，这对花括号会将key值的一部分括起来，客户端在计算key的CRC16哈希值时只会计算花括号内的内容，如果没有花括号会计算整个key值的CRC16值。

如key值为user:order:{1001}那么花括号内的被称为Hash Tag也就是1001，在计算key的CRC16时也就是计算1001的CRC16值而不是计算user:order:{1001}。

使用Hash Tag的特点就是不同的键值只要Hash Tag相同就能映射到同一个Slot哈希槽中，所以肯定会在一个实例里面。

Hash Tag一般用于什么场景呢？

==Redis Cluster的事务以及范围查询都不支持跨实例的==，如果查询的所需数据存在不同的实例中，那么带来的后果就是需要在业务代码中对实例进行逐一查询得到结果，这显然效率大打折扣，所以我们可以使用Hash Tag将业务所需数据集中到一个Slot哈希槽中，这样就能轻松实现事务以及范围查询。

如果盲目的使用Hash Tag就有可能造成大量数据堆积在一个实例上，从而导致数倾斜，这就要在效率以及数据倾斜上做取舍，如果因为Hash Tag造成数据倾斜，那么就应该优先避免数据倾斜，最好不要使用Hash Tag，因为事务和范围查询还能放在客户端处理，而数据倾斜可能造成实例不稳定。

数据访问倾斜

数据访问倾斜出现的根本原因就是存在热点数据，如电商秒杀商品信息，这种情况可能就是几个键值访问带来的实例压力，重新分配Slot哈希槽解决不了数据访问倾斜带来的问题，我们可以采用多副本的形式。

多副本是什么意思呢？就是将热点数据复制多份，每一份副本的key增加一个随机访问前缀，保证这个key和其它副本的数据不会映射到同一个slot哈希槽中。

什么意思呢？例如Cluster存在8个实例，业务的key为abc，0-7号实例的key分别对应0abc，1abc，2abc，3abc，… 7abc，在客户端查询这个key值abc时，通过产生一个0到7的随机数，与abc拼在一起再去请求redis。

不过我们需要注意的是slot哈希槽需要分配到不同的实例上才能达到效果，所以这个解决办法的中心思想就是将热点数据分散到每一个实例，分担压力。

使用这个解决办法的另一个要求就是数据需要只读，如果数据可写还需要增加维护每个副本带来资源消耗，显然是不合适的。