redis架构模式（6）数据倾斜

Posted 2023-04-23

参考技术A 数据倾斜通常分为两种情况，一是各实例上面的数据不均匀，个别实例数据量特别多；

二是某个实例上的热点数据多，导致的访问量倾斜。发生了数据倾斜，那么保存了大量

数据或者是保存了热点数据的实例的处理压力就会增大，速度变慢，甚至还可能会引起

这个实例的内存资源耗尽导致宕机风险。

如果某个实例上保存了bigkey，会导致这个实例的数据量及相应的内存资源消耗增加，

bigkey的操作容易导致主线程IO的阻塞，bigkey最好能够从业务层面避免掉，如果是

集合类型的bigkey，建议拆分成多个集合多实例保存，再根据业务逻辑做相应的映射。

solt分配不均，就根据具体的使用的中间件查看slot分布情况进而做具体slot迁移

hashtag指的是对key的部分用圈起来，例如dramaId:episode:1232变成

dramaId:episode:1232,在计算 key 的 CRC16 值时，只对HashTag花括号中的 

key内容进行计算,这有什么用处呢？就是key不一样但是hashtag内容一样的key

会被分配到同一个slot，它主要是用在 Redis Cluster 和 Codis中，支持事务操作

和范围查询。因为 Redis Cluster 和 Codis 本身并不支持跨实例的事务操作和

范围查询，当业务应用有这些需求时，就只能先把这些数据读取到业务层进行事务

处理，或者是逐个查询每个实例，得到范围查询的结果，所以我们可以使用 Hash Tag 

把要执行事务操作或是范围查询的数据映射到同一个实例上，这样就能很轻松实现

事务或范围查询，潜在的风险就是会导致大量的数据被分配到同一实例，导致数据

倾斜和集群负载不均衡，所以在hashtag和业务上的事务范围查询，得我们自己做

取舍，建议还是避免hashtag

在某个实例上的商品或者某些影视剧集突然火了，那么就导致这个实例的访问量突增，

好在热点数据通常只是读，所以我们可以采用热点数据多副本的方式应对，我们把热点

数据复制多份，然后把key加个前缀，使其分布在不同的slot，查询的时候做好相应逻辑，

那么即可把热点数据的压力分摊到多实例上

Redis学习笔记37——数据分布优化：如何应对数据倾斜

在切片集群中，数据会按照一定规则分布在不同的实例上进行保存。但是这很容易导致一个问题：数据倾斜。

数据倾斜分为两种：

1. 数据量倾斜：在某些情况下，实例上的数据分布不均衡，某个实例上的数据特别多。
2. 数据访问倾斜：虽然每个集群实例上的数据量相差不大，但是某个实例上的数据是热点数据，被访问得非常频繁。

数据量倾斜

成因

当数据量倾斜发生时，数据在切片集群的多个实例上分布不均衡，大量数据集中到了一个或几个实例上

这主要有三个原因：

1. 在某个实例上保存了 bigkey
2. Slot 分配不均
3. Hash Tag

bigkey导致倾斜

为了避免 bigkey 造成的数据倾斜，一个根本的应对方法是，我们在业务层生成数据时，要尽量避免把过多的数据保存在同一个键值对中。

此外，如果 bigkey 是集合类型，可以把 bigkey 拆分成很多个小的集合类型数据，分散保存在不同的实例上。

slot分配不均导致倾斜

如果集群运维人员没有均衡地分配 Slot，就会有大量的数据被分配到同一个 Slot 中，而同一个 Slot 只会在一个实例上分布，这就会导致，大量数据被集中到一个实例上，造成数据倾斜。

如果某一个实例上有太多的 Slot，我们就可以使用迁移命令把这些 Slot 迁移到其它实例上。

在 Redis Cluster 中，我们可以使用 3 个命令完成 Slot 迁移。

1. CLUSTER SETSLOT：使用不同的选项进行三种设置，分别是设置 Slot 要迁入的目标实例，Slot 要迁出的源实例，以及 Slot 所属的实例。
2. CLUSTER GETKEYSINSLOT：获取某个 Slot 中一定数量的 key。
3. MIGRATE：把一个 key 从源实例实际迁移到目标实例。

Hash Tag 导致倾斜

Hash Tag 是指加在键值对 key 中的一对花括号。这对括号会把 key 的一部分括起来，客户端在计算 key 的 CRC16 值时，只对 Hash Tag 花括号中的 key 内容进行计算。如果没用 Hash Tag 的话，客户端计算整个 key 的 CRC16 的值。

举个例子，假设 key 是 user:profile:3231，我们把其中的 3231 作为 Hash Tag，此时，key 就变成了 user:profile:3231。当客户端计算这个 key 的 CRC16 值时，就只会计算 3231 的 CRC16 值。否则，客户端会计算整个“user:profile:3231”的 CRC16 值。

使用 Hash Tag 的好处是，如果不同 key 的 Hash Tag 内容都是一样的，那么，这些 key 对应的数据会被映射到同一个 Slot 中，同时会被分配到同一个实例上。

但是，使用 Hash Tag 的潜在问题，就是大量的数据可能被集中到一个实例上

数据访问倾斜

通常来说，热点数据以服务读操作为主，在这种情况下，我们可以采用热点数据多副本的方法来应对。这个方法的具体

这个方法的具体做法是，我们把热点数据复制多份，在每一个数据副本的 key 中增加一个随机前缀，让它和其它副本数据不会被映射到同一个 Slot 中。这样一来，热点数据既有多个副本可以同时服务请求，同时，这些副本数据的 key 又不一样，会被映射到不同的 Slot 中。在给这些 Slot 分配实例时，我们也要注意把它们分配到不同的实例上，那么，热点数据的访问压力就被分散到不同的实例上了。

但是需要注意，热点数据多副本方法只能针对只读的热点数据。如果热点数据是有读有写的话，就不适合采用多副本方法了，因为要保证多副本间的数据一致性，会带来额外的开销。

对于有读有写的热点数据，我们就要给实例本身增加资源了，例如使用配置更高的机器，来应对大量的访问压力。

小结

造成数据倾斜的原因主要有三个：

1. 数据中有 bigkey，导致某个实例的数据量增加；
2. Slot 手工分配不均，导致某个或某些实例上有大量数据；
3. 使用了 Hash Tag，导致数据集中到某些实例上。
4. 热点数据的存在导致访问量倾斜