Redis数据库的数据倾斜详解

发布时间：2024-03-31 03:16:18 来源：网络

.

一、定义引用百度百科的定义：对于集群系统，一般缓存是分布式的，即不同节点负责一定范围的缓存数据。我们把缓存数据分散度不够，导致大量的缓存数据集中到了一台或者

一、定义

引用百度百科的定义：

对于集群系统，一般缓存是分布式的，即不同节点负责一定范围的缓存数据。我们把缓存数据分散度不够，导致大量的缓存数据集中到了一台或者几台服务节点上，称为数据倾斜。一般来说数据倾斜是由于负载均衡实施的效果不好引起的。

二、危害

如果发生了数据倾斜，那么就会有某一台机器或几台保存了大量数据。轻则造成性能下降，处理请求速度骤降。重则造成Redis服务器崩溃，缓存服务不可用，将性能影响范围扩散到DB层，对后端服务造成不可估量的后果。

三、数据倾斜的分类及应对方案

1、写入倾斜

示例

如图，在某些情况下，实例上的数据分布不均衡，某个实例上的数据特别多。

在这里插入图片描述

分析及应对方案

1、bigkey导致倾斜

bigkey指的是某个 Redis 实例上保存了一个很大的 value （String 类型）或者是大量的集合元素（集合类型）的 key ，这个 key 就被称之为 bigkey ，而bigkey这种情况会导致集群中的某个实例的数据量很大，内存资源消耗也相应增加。

应对方案

在业务层生成数据时，要尽量避免把过多的数据保存在同一个键值对中。如果 bigkey 正好是集合类型，还有一个方法，就是把 bigkey 拆分成很多个小的集合类型数据，分散保存在不同的实例上。

2、Slot分配不均导致倾斜

介绍一下slot，slot全称HashSlot(哈希槽)，类似于数据分区，每个key都会根据Hash算法计算出它应该属于哪个哈希槽，最终落到那个哈希槽中。而 Redis Cluster 就是采用哈希槽的方式来处理数据和实例间的映射关系。事实上，在 Redis Cluster 分片集群中一共有16384 个 Slot。在这里插入图片描述这里的Hash算法市面上的方式一般是先计算hash值，然后将计算结果对slot个数取模，最终确定落到哪个slot上。而计算hash值的算法有很多，常用的像CRC16、CRC64、sha1等等运维在构建切片集群时候，需要手动分配哈希槽，并且把16384 个槽都分配完，否则 Redis 集群无法正常工作。由于是手动分配，则可能会导致部分实例所分配的slot过多，导致数据倾斜。

应对方案

使用CLUSTER SLOTS 命令来查看slot分配情况，使用CLUSTER SETSLOT，CLUSTER GETKEYSINSLOT，MIGRATE这三个命令来进行slot数据的迁移，具体内容不再这里细说，感兴趣的同学可以自行学习一下。

3.Hash Tag导致倾斜

Hash Tag 定义 :指当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。假设hash算法为sha1。

对user:{user1}:ids和user:{user1}:tweets，其hash值都等同于sha1(user1)。

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

所以，如果不合理使用Hash Tag，会导致大量的数据可能被集中到一个实例上发生数据倾斜，集群中的负载不均衡。

应对方案

按照需求合理使用Hash Tag，甚至可以考量是否需要用到Hash Tag。

2、读取倾斜（热key）

示例

一般来说，读取倾斜大多数都是热key问题导致的。如图所示，虽然每个集群实例上的数据量相差并没有很大，但是如果其中某个实例上的数据是热点数据，那台实例就会被访问得非常频繁。

在这里插入图片描述

产生热key的原因及危害

原因：用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。

在日常工作中一些突发的事件，例如：双十一期间某些热门商品在进行降价促销或秒杀时，这时某一件商品会被数万次点击浏览或者购买，会形成一个较大的需求量，这种情况下就很容易造成热点问题。

同理，被大量浏览的热点数据、明星直播等，这些典型的读多写少的场景也会产生热点问题。

危害：请求分片集中，超过单 Server 的性能极限。

在服务端读数据访问Redis时，往往会对请求key进行分片计算，此时中会将请求打到某一台 Server 上，如果热点过于集中，热点 Key 的缓存过多，访问量超过 Server 极限时，就会出现缓存分片服务被打垮现象的产生。当缓存服务崩溃后，此时再有请求产生，就会打到DB 上，这也就是我们常说的缓存穿透，如果没有合理的解决，数据库又没有扛住大量的穿透请求，则会进一步导致数据库雪崩现象。造成所有连接此数据库的系统服务不可用，上下游调用链中断，产生不可估量的后果。

分析及应对方案:

① 拆分热key

拆分热key，指的是把热点数据拆分成多份，在每份数据副本的 key 中增加一个随机后缀，让它和其它副本数据不会被映射到同一个 Slot 中。这里相当于把一份数据复制到多个实例上，通过Hash算法实现一个简陋的负载均衡。同样的，在读取的时候也要增加随机后缀，将对一个实例的读取压力，均摊到多个实例上。例如：我们在放入缓存时就将对应业务的缓存key拆分成多个不同的key。如下图所示，在写入缓存的过程中，我们首先将key拆成N份，比如某个请求进来的key名字叫做"hot_key"，那我们就可以把它拆成“hot_key_001”、“hot_key_002”、“hot_key_003”、“hot_key_004”…，当然了，每次更新和新增时都要记得去改动这N个key，这就是拆key。

在这里插入图片描述

对于Service端来讲，我们要尽可能的将访问流量分流的足够的均匀。如何给即将访问的热key上合理的加入后缀？说一下市面上常用的方案，根据本机的ip或mac地址做hash，之后的值与拆key的数量做取余，最终决定拼接成什么样的key后缀，从而打到哪台机器上。当然也有其他的解决方案，比如在服务启动时的一个随机数对拆key的数量做取余。伪代码如下:

public boolean getRandomHotKey(String hotKey,int count) {
        int random = new Random().nextInt(count);
        randomKey = hotKey + "_" + random;
        Object data = redis.get(randomKey);
        if (data == null){
            data = getFromDB(); 
            redis.set(randomKey,expireTime + random);
        }
    }

② 多级缓存+动态计算自动发现热点缓存

基本流程图

在这里插入图片描述

该方案主要是通过主动发现热点并对其进行本地缓存来解决热点 Key 的问题。对，你没有听错，就是在缓存上再架设一层缓存。具体来说，就是在 Proxy上增加本地缓存，本地缓存采用LRU算法来缓存热点数据，后端节点增加热点数据计算模块来返回热点数据。当然了，Client会访问SLB，并且通过SLB将各种请求分发至Proxy中，Proxy会按照基于路由的方式将请求转发至Redis中。

Proxy 架构的主要有以下优点：