Redis核心技术与实战【学习笔记】 - 4.Redis 切片集群

前言

如果 Redis 要存 5000 万个键值对,每个键值对大约 512B,那么该如何选择主键的内存容量呢?

粗略估算下,所有键值对需要内存空间大约是 25GB。我们很自然的想到第一个方案,选择一台 32GB 的内存的主机来部署 Redis。

因为32GB 的内存可以保存所有数据,且还有7GB 预留,足以保证系统正常运行。同时,还可使用 RDB 持久化数据,确保 Redis 实例故障后,还能从 RDB 回复数据。

但是,在使用 Redis 进行持久化时, Redis 会 fork 子进程来完成,而 fork 操作的耗时和 Redis 的数据量成正比。所以在使用 RDB 对 25GB 进行持久化时,由于数据量较大,fork 创建子进程时阻塞的主进程,导致 Redis 的响应有时会非常慢。

显然,第一个方案不可行,我们须寻找其他的方案。 Redis 的切片集群方案是一个靠谱的方案。虽然切片集群比较麻烦,但是它可以保存大量数据,而且对 Redis 主线程的阻塞影响小。

切片集群也叫分片集群,是指启动多个 Redis 实例组成一个集群,然后按照一定的规则,把收到的数据分成多份,每一份用一个实例来保存。

如上面的例子,可以把 25GB 的数据平均分成 5 份,这样每个实例只需要保存 5GB 的数据。
Redis核心技术与实战【学习笔记】 - 4.Redis 切片集群_第1张图片


如何保存更多数据?

前言总,我们提到了使用大内存主机和切片集群方案,它们对应着 Redis 应对数据增多的两种方案:

  • 横向扩展:升级单个 Redis 实例的资源配置,包括加内存、加磁盘、使用高配 CPU。
  • 纵向扩展:横向增加当前 Redis 实例的个数。

首先横向扩展的好处是实施简单、直接,不过有两个潜在问题:

  1. 第一个问题,当使用 Redis 对数据进行持久化时,如果数据量增加,需要的内存也会增加,主线程 fork 子进程时可能会阻塞。不过,如果不需要持久化 Redis 数据,那么,纵向扩展会是一个不错的选择。
  2. 第二个问题,纵向扩展会受到硬件和成本的限制。这很好理解,把内存从 32GB 扩展到 64GB 还算容易,但是要扩充到 1TB,就会面临硬件容量和成本上的限制了。

与纵向扩展相比,横向扩展是一个扩展性更好的方案,因为想要保存更多的数据,只用增加 Redis 实例的个数就行了。在面向百万、千万级别的用户时,横向扩展的 Redis 切片集群是一个非常好的选择

切片集群不可避免的涉及多个实例的分布式管理问题:

  • 数据切片后,在多个实例之间如何分布?
  • 客户端怎么确定想要访问的数据在哪个实例上?

数据切片及实例的对应分布关系

切配集群是一种保存大量数据的通用机制,从 Redis 3.0 开始,官方提供 Redis Cluster 方案,用于实现切片集群。Redis Cluster 方案中就规定了数据和实例的对应规则。

Redis Cluster 方案采用哈希槽(Hash Slot),来处理数据和实例之间的映射关系。在 Redis Cluster 方案中,一个切片集群共有 16384 个哈希槽,这些哈希槽就类似数据分区,每个键值对都会根据它的 key,被映射到一个哈希槽中。

映射过程分为两大步:

  1. 首先根据键值对的 key,按照 CRC16 算法计算一个 16 bit 的值;
  2. 然后再将这个 16 bit 的值对 16384 取模,得到 0~16383 范围内的模数,每个模数代表一个响应编号的哈希槽。

这些哈希槽是如何被映射到具体的 Redis 实例上呢?我们在部署 Redis Cluster 方案时,可以使用 cluster create 命令创建集群,此时 Redis 会 自动把这些槽平均分布到集群实例上。例如有 N 个 Redis 实例,那么,每个实例上的哈希槽数为 16384/N 个。

当日,我们也可以使用 cluster meet 命令手动创建实例间的连接,形成集群,再使用 cluster addslots 命令,指定每个实例上的哈希槽个数。

例如集群中不同 Redis 实例的内存大小不一样,如果均分哈希槽到各个实例上,内存小的实例就会有更大的容量压力。遇到这种情况,你可以根据不同的实例的资源配置清理,使用 cluster addslots 命令手动分配哈希槽。

画一张示意图来解释一下,数据、哈希槽、实例这三者的映射分布情况
Redis核心技术与实战【学习笔记】 - 4.Redis 切片集群_第2张图片

图中的切片集群有3个实例,同时设有 5 个哈希槽,,首先通过下面的命令手动分配哈希槽:

  • 实例 1 保存哈希槽 0 和 1;
  • 实例 2 保存哈希槽 2 和 3;
  • 实例 3 保存哈希槽 4;
redis-cli -h 172.16.19.3 -p 6379 cluster addslots  0,1
redis-cli -h 172.16.19.4 -p 6379 cluster addslots 2,3
redis-cli -h 172.16.19.5 -p 6379 cluster addslots 4

在集群运行过程中,key1 和 key2 计算完 CRC16 值后,对哈希槽个数 5 取模,再根据各自的模数结果,就可以被映射到实例 1 和实例 3 上了。

另外,一定要注意!!!在手动分配哈希槽时,需要把 16384 个槽都分配完,否则 Redis 集群无法正常工作

现在我们知道,切片集群实现了数据到哈希槽、哈希槽再到实例的分配。但是,即使实例有了哈希槽的映射信息,客户端又是怎么知道要访问的数据在哪个实例上呢?

客户端如何定位数据?

一般来说,客户端和机器实例建立连接后,实例会把哈希槽的分配信息发给客户端。但是,在集群刚刚创建的时候,每个实例只知道自己被分配了哪些哈希槽,是不知道其他实例拥有的哈希槽信息的。

客户端为什么可以访问任何一个实例时,能获得所有的哈希槽信息的?

这是因为,Redis 实例会把自己的哈希槽信息发送给和他相连接的其他实例,来完成哈希槽分配信息的扩散。当实例之间相互连接后,每个实例就有所有哈希槽的映射信息了。

客户端收到哈希槽信息后,会把哈希槽缓存在本地。当客户端请求键值对时,会先计算键所对应的哈希槽,然后就可以给响应的实例发送请求。

还有一个要注意的问题:在集群中,实例和哈希槽的对应关系不是一成不变的,最常见的的变化有两个:

  • 在集群中,实例有新增或删除的, Redis 需要重新分配哈希槽信息。
  • 为了负载均衡,Redis 需要把哈希槽在所有实例上重新分配一遍。

此时,实例之间可以相互传递消息,获得最新的哈希槽分配信息,但是客户端无法感知这些变化。这就导致哈希槽的分配信息和最新的信息不一致,这该怎么办?

Redis Cluster 方案提供了一种重定向机制。当客户端把一个键值对的操作请求发送给一个实例时,如果这个实例上并没有这个键值对映射的哈希槽,那么这个实例就会给客户端返回 MOVED 命令响应结果,这个结果中就包含了新势力的访问地址。

Get hello:key
(error) MOVED 13320 172.16.19.5:6379

其中,MOVED 命令表示,客户端请求的键值对所在的哈希槽 13320 是在 172.16.19.5 实例上。这样一来,客户端就可以直接和 172.16.19.5 连接,并发送操作请求了。

举例说明下整个过程:

  1. 由于负载均衡, Slot 2 中的数据已经从实例 2 迁移到了实例 3
  2. 但是客户端仍然记录着“Slot 2 在实例 2”的信息,所以客户端会给实例 2 发送命令
  3. 实例 2 给客户端返回一条 MOVED 命令,把 Slot 2 的最新位置(即实例 3),返回给客户端
  4. 客户端就会再次向实例 3 发送请求,同时还会更新本地缓存,把 Slot 2 与实例的对应关系更新过来
    Redis核心技术与实战【学习笔记】 - 4.Redis 切片集群_第3张图片
    上述过程客户端给实例 2 发送命令时,Slot 2 中的数据已经全部迁移到了实例 3。在实际应用时,还可能存在一种情况:客户端向实例 2 发送请求,但此时, Slot 2 中的数据只有一部分迁移到了实例 3,还有部分数据没有迁移。在这种迁移部分完成的情况下,客户端会收到一条 ASK 报错信息,如下所示:
Get hello:key
(error) ASK 13320 172.16.19.5:6379
  1. 这个结果中的 ASK 命令就表示,客户端请求的键值对所在的哈希槽 13320,在 172.16.19.5 这个实例上,且哈希槽上正在迁移。
  2. 此时,客户端需要先给 172.16.19.5 这个实例发送一个 ASKING 命令,让这个实例允许执行客户端接下来发送的命令。
  3. 然后,客户端再向这个实例发送 GET 命令,以读取数据。

借助一个例子来解释下
Redis核心技术与实战【学习笔记】 - 4.Redis 切片集群_第4张图片
Slot 正在从实例 2 往实例 3 迁移,key1 和 key2 已经迁移过去,key3 和 key4 还在实例 2。此时,客户端向实例 2 请求 key2 后,就会收到实例 2 返回的 ASK 命令。
ASK 命令表示两层含义:

  1. 表名 Slot 数据还在迁移中;
  2. ASK 命令把客户端所请求数据的最新实例地址返回给客户端,此时,客户端需要给实例 3 发送 ASKING 命令,然后在再发送操作命令。

和 MOVED 命令不同,ASK 命令并不会更新客户端缓存的哈希槽分配信息。所以,在上图中,如果客户端再次请求 Slot 2 中的数据,它还是会给实例 2 发送请求。这也就是说,ASK 命令的作用只是让客户端能给新实例发送一次请求,而不像 MOVED 命令那样,会更改本地缓存,让后续所有命令都发往新实例。

你可能感兴趣的:(Redis核心技术学习,redis,学习,笔记)