返回
Featured image of post 分布式丛林探险系列之 Redis 集群模式

分布式丛林探险系列之 Redis 集群模式

时间终于来到了十二月,据说,《黑客帝国 4:矩阵重生》 将于本月在北美上映,正如同它的片名一样,黑客帝国系列在沉寂了十八年后,终于等来了一次矩阵重生的机会,不可不谓“有生之年”、“爷青回”。提及黑客帝国系列,这是一部公认的、具有划时代意义的科幻电影,除了精彩绝伦的打斗特效,最为影迷所津津乐道的,当属对于人和机器的关系这种颇具哲学意味的问题的探讨。在第二部中,The One 的部分代码被融合到了 Smith 身上,而这使得 Smith 发生变异,成为了可以自我复制的病毒。于是,我们在这里看到了 Neo 和 100 个 Smith 打斗的桥段,类似的桥段还有第三部里的雨中决斗。这些桥段或多或少地影响到了后来的电影,譬如,星爷的 《功夫》 里,阿星与斧头帮、火云邪神打斗的片段;吴京的第一部电影 《狼牙》 里,阿布雨夜大战黑衣人的片段等等。虽然,病毒的自我复制和分布式系统中的复制,是两个完全不同的概念,可当我们试图将电影和现实联系起来的时候,我们还是会不免会心一笑,因为 100 个 Smith ,大概就相当于一个 Smith 的集群;而吞噬了先知能力的 Smith ,大概就相当于这个集群中的 Leader。我们注意到,强如超人般的 Neo,一样架不住越来越多的 Smith ,最后不得不飞走,所谓:“双拳难敌四手”,这足以说明集群的重要性。好了,既然这里聊到了集群,那么我们这次来聊聊 Redis 中的集群模式。

Redis 集群概述

通过上一篇文章,我们了解到,主从复制的作用主要体现在数据冗余、故障恢复、负载均衡等方面。可很多时候,我们讲分布式,并不是说简单的复制就好啦!相信大家都听说过,水平扩展和垂直扩展这两个概念,特别是数据库的水平扩展,它天然地和分片(Sharding)联系在一起,这意味是我们希望在不同地数据库/表里存储不同地数据。此前,博主曾在 《浅议 EF Core 分库分表及多租户架构的实现》 一文里介绍过数据库的分库/表,作为类比,我们可以归纳出 Redis 集群模式的第一个特点,即:它本质上是一种服务器 Sharding 技术。因为纯粹的主从复制意味着,每台 Redis 服务器都存储相同的数据,显然这造成了资源的浪费,而让每台 Redis 服务器存储不同的数据,这就是 Redis 的集群模式。如下图所示,Redis 集群模式呈现出的一种网状结构,完全不同于主从复制间的单向流动:

Redis 集群模式示意图
Redis 集群模式示意图

从图中可以看出,6 台服务器组成了一个网状结构,任意两台服务器间都可以相互通信。也许,大家会好奇一个问题,为什么这里博主就画了 6 台服务器?其实,这一切都是有迹可循的,因为 Redis 官方规定:一个集群中至少需要有 3 个主服务器(Master)。所以,一个 Redis 集群至少需要 6 台服务器。如果从这个角度来审视集群的定义的话,你可以认为 Redis 集群就是由多个主从复制一起对外提供服务。此时,集群中的节点都通过 TCP 连接和一个被称为 Cluster Bus 的二进制协议来建立通信,这里的 Cluster Bus 你可以将其理解为 Kafka 或者 RabbitMQ 这样的支持“发布-订阅”(Pub-Sub)机制的东西,换句话说,集群中的每个节点都可以通过 Cluster Bus 与集群中的其它节点连接起来。节点们使用一种叫做 Gossip 的消息协议,据说,这是一种从瘟疫和社交网站上获得灵感消息传播方式。“六度分割”理论告诉我们,最多通过 6 个人你就能认识任何一个陌生人,同样地,最多通过 6 个节点你就可以把消息传递给任何一个节点。

Redis 集群模式与主从模式的联系
Redis 集群模式与主从模式的联系

目前,使用 Gossip 这一协议的项目有 Redis Cluster、ConsulApache Cassandra 等等, 关于这个协议以及“六度分割”理论更进一步的细节,大家可以通过搜索引擎来获取,对我们而言,我们只需要知道,Redis 集群需要借助这个协议来实现诸如发现新节点、发送 PING 包、发送集群消息这些功能,因为每个节点除了存储自身的数据以外,还需要记录集群的状态,需要知道哪些节点不可用,需要合适的时机推选出主节点。我们在主从复制这一篇文章中提到过故障恢复,这个概念在这里同样适用,如图所示,S1 是 M1 的从节点,它本身并不是为了扩展请求的并发量而存在的,它需要在主节点宕机的情况下能被提拔为主节点,所以,它主要起一个数据备份的作用。因此,Redis 集群中的读和写,实际上都是在M1、M2 和 M3 上进行的。那么,我们不妨来想这样一个问题,如果 M1 和 S1 都宕机了,此时 Redis 集群还能不能正常工作呢?答案是否定的,因为此时显然不满足最少 3 个主节点的要求。

一致性哈希算法

OK,我们知道,在面对数据库的水平拆分问题时,一个最为关键的问题是路由,换句话说,我怎么样可以找到到对应的库或者表。常见的思路有范围、哈希和配置等等,而在 Redis 的集群模式下,我们同样会面临这个问题,更一般地,任何需要负载均衡的场景都需要考虑这个问题,譬如,我们对多台服务器的 IP 地址求余,然后按照余数来进行路由,抑或者是按照不同的权重进行随机等等,这看起来像回到了熟悉的负载均衡算法,对吗?事实上,一般的负载均衡算法都会选择哈希算法,而哈希算法本质上就是一种散列函数,它可以把任意长度的输入转化为确定的、固定长度的输出,以最常见的求余为例,它具体是怎么工作的呢?我们来一起看下面的图:

经典哈希算法
经典哈希算法

可以注意到,首先,我们需要对 Key 计算出一个 hash 值,你可以理解为编程语言里的GetHashCode()方法,主要目的是将字符串类型的 Key 转化为整数型方便计算。接下来,按照主节点的数量来进行求余运算(统称为散列运算),例如,这里我们有 3 台主节点服务器,故而在上面的图示中 n 应该等于 3,而这就是经典的哈希算法啦!那么,Redis 的集群有没有采用这个算法呢?答案还是否定的,因为这个方案里最大的变数就是 n。具体来讲,如果你想要扩容,那么 n 会变大,此时 Key 与服务器间的映射关系会被打破,即使不扩容,一旦某台服务器宕机,Key 与服务器间的映射关系还是会被打破,如果出现散列“碰撞”,无疑会让问题变得更复杂。

经典哈希算法“碰撞”问题
经典哈希算法“碰撞”问题

可以注意到,当从对 3 取模变成对 2 取模以后,必然会出现两个 1,这就是所谓的散列“碰撞”。所以,对于经典的哈希算法而言,它无法抵消因为 n 的变化而带来的重新 hash 的问题。为了解决这个问题,业界普遍使用的是一致性哈希算法,相比经典的哈希算法,最大的变化在于它将 n 的取值固定下来,即按 2^32 取模,此时,结果会落在 0 到 2^32 - 1 这个区间内,一旦我们将这个区间抽象为一个圆环,利用 CRC16 算法计算出来的值就会落在圆环上的某个地方:

改良后的哈希一致性算法
改良后的哈希一致性算法

如图所示,假设我们有 A、B、C 三个 Redis 节点,它们均按照顺时针方向排列在整个圆环上,当我们对每一个 Redis 节点进行 hash() 运算以后按 2^32 取模,此时,这个值依然会落在 0 到 2^32 - 1 这个区间内,以此类推,理论上对于任意一台服务器 X,我们总能找到对应的一个值,当该值介于区间(m, n)中,表示它分配在节点 n 上,你可以认为,每个服务器节点,它负责的并不是哈希环上的一个点,而是一个范围。基于这种特性,当某一台 Redis 服务器宕机时,对应的这个区间会变大,相当于流量从这个节点转移到了它的下一个节点,这意味着我们只需要移动一部分数据。同理,如果要增加节点,只需要把移动该节点到它上一个节点间的数据。由此可见,它对原来数据的影响非常小,而这就是一致性哈希算法。

Redis 哈希槽

截止到现在,我们知道了,一致性哈希算法相对经典哈希算法的优势,可这个算法真的没有问题吗?我们应该会想到,节点在哈希环上的分布是不均匀的,这意味着,每个节点上对应的 Key 的数量各不相同,更进一步,我们可以说,每台 Redis 上存储的数据量不同,这样,原本期待着负载均衡的我们,此刻被光速地打脸。因此,在实际应用中,为了让哈希环分布更均匀一点,会设置所谓的“虚拟节点”。不过,就算你考虑到了这种地步,Redis 还是没有采用这种哈希一致性的方案,你说这是不是有点气人?事实上,它采用的是一种被称为哈希槽的方案:

Redis 哈希槽示意图
Redis 哈希槽示意图

如图所示,Redis 集群中总共有 16384 个槽位,它是怎么算出来的呢?因为 CRC16 算法产生的 hash 值有 16 个 bit,因此,它可以产生 2^16 即 65536 个值,理论上我们完全可以分配 65536 个槽位,不过考虑到网络带宽、节点数目,作者觉得 16384 个槽位完全够用了,前提是你集群内的节点不超过 1000 个!是不是听起来觉得非常离谱?可有些时候,工程上的事情,还真不能按科学一板一眼的来,不然,你又怎么会见到各种各样的“敏捷开发”、”项目管理”呢?

Redis 哈希槽槽位分配
Redis 哈希槽槽位分配

OK,对于 Redis 中的每一个 Key,它经过计算以后会落到某个具体的槽位内,至于槽位会路由到哪个机器上,这完全取决于每台 Redis 服务器的配置,硬盘大就多分一点,硬盘小就少分一点,“能者多劳”,听起来就很科学,对吧!所以,从这个角度来看,相比哈希环,哈希槽可以更加灵活地控制槽位的分布。可世间万物,无一不是双刃剑,你选择了自由,那么需要操心的事情就变多了,至少 Redis 集群不会帮你转移和分配槽位;你选择了秩序,一切井井有条,那么你内心又会期盼自由。“小而美”,想要面面俱到;“大而全”,想要细致入微,难怪刺客组织要和圣殿骑士间的斗争永无止息啊,哈哈……因此,Redis 集群的高可用,实际上非常依赖主从节点的主从复制和故障切换,我承认,我点题了,你发现了吗?

Redis 集群实战

好了,和上一篇一样,我们先礼后兵,等所有的理论知识都讲完了,再来着眼实际的过程,因为在博主看来,这是一个互相印证的过程,写流水账、记下每一步的操作步骤,这固然可以让你快速上手,但你真的只愿意到此为止吗?博主以前学过 CAD,近来又开始学习 Blender,一个深刻的感受就是,这些软件都需要大量的重复练习,甚至于形成肌肉记忆。可是我们学习知识的过程,是一个反复提炼、内化的过程,我们并不是为了成为某种“熟练工”,我发现有很多朋友,特别喜欢问某软件/工具怎么安装/配置类似的问题,虽然说这是技术人员日常生活里的一部分,但我觉得这不应该成为你特别关注的问题,所以,如果你发现我越来越不像是在写教程,恭喜你,发现了我的改变,谢谢你啊!回到正题,我们还是准备一个最小的集群,即“三主三从”的一个集群,依然使用 docker-compose 进行服务编排。首先,准备下面的目录结构:

 1Clusters
 2|-- docker-compose.yaml
 3|-- redis-1
 4|   |-- redis.conf
 5|-- redis-2
 6|   |-- redis.conf
 7|-- redis-3
 8|   |-- redis.conf
 9|-- redis-4
10|   |-- redis.conf
11|-- redis-5
12|   |-- redis.conf
13|-- redis-6
14|   |-- redis.conf

此时,针对集群模式的 Redis 配置文件,相比主从复制模式要精简许多,以其中一台服务器7001为例:

# 端口号
port 7001
# 启用集群
cluster-enabled yes
cluster-config-file nodes_7001.conf
cluster-node-timeout 5000
appendonly yes

照葫芦画瓢,我们准备好剩下的70027003700470057006 这 5台服务器即可。接下来,我们准备服务编排文件docker-compose.yaml:

 1version: '3.1'
 2services:
 3  redis1:
 4    image: redis:latest
 5    container_name: redis-1
 6    restart: always
 7    network_mode: "host"
 8    volumes:
 9      - ./redis-1/redis.conf:/usr/local/etc/redis/redis.conf
10    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
11  redis2:
12    image: redis:latest
13    container_name: redis-2
14    restart: always
15    network_mode: "host"
16    volumes:
17      - ./redis-2/redis.conf:/usr/local/etc/redis/redis.conf
18    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
19  redis3:
20    image: redis:latest
21    container_name: redis-3
22    restart: always
23    network_mode: "host"
24    volumes:
25      - ./redis-3/redis.conf:/usr/local/etc/redis/redis.conf
26    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
27  redis4:
28    image: redis:latest
29    container_name: redis-4
30    restart: always
31    network_mode: "host"
32    volumes:
33      - ./redis-4/redis.conf:/usr/local/etc/redis/redis.conf
34    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
35  redis5:
36    image: redis:latest
37    container_name: redis-5
38    restart: always
39    network_mode: "host"
40    volumes:
41      - ./redis-5/redis.conf:/usr/local/etc/redis/redis.conf
42    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
43  redis6:
44    image: redis:latest
45    container_name: redis-6
46    restart: always
47    network_mode: "host"
48    volumes:
49      - ./redis-6/redis.conf:/usr/local/etc/redis/redis.conf
50    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]

接下来,我们运行 docker-compose up命令,就可以看到 6 台 Redis 服务器都运行起来,此时,我们需要选择任意一台 Redis 服务器对应的容器内,执行下列命令:

1redis-cli --cluster create 
2  127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \
3  127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \
4  --cluster-replicas 1

该命令表示创建一个由 6 台服务器组成的集群,其中,--cluster-replicas 参数表示每个主节点分配一个从节点。此时此刻,当我们按下回车后,就可以看到下面的画面:

通过 redis-cli 创建 Redis 集群
通过 redis-cli 创建 Redis 集群

可以注意到,当前集群有 3 台主服务器节点:700170027003,有 3 台从服务器节点:700470057006,这符合我们一开始设想的“三主三从”,Redis 内部会为每个节点分配一个唯一的 Id,这个 Id 会和每个节点的 IP 地址、端口号一起保存下来。当我们没有显式地分配每台服务器对应多少个槽位时,它会按照主节点的数量平均地分割。在这里我们只有 3 台主节点服务器,无法被 16384 整除,所以,7002 这个服务器会多分配一个槽位。显然,Redis 需要我们来确定这个集群划分,此时,我们输入yes即可,这样我们就完成了 Redis 集群的搭建。接下来,我们通过 redis-cli 写入信息来看看集群实际的运行效果:

1# 进入 Redis 容器
2docker exec -it df5cae3c6004 sh
3# 连接 7001 服务器
4redis-cli -p 7001 -c
5# 写入一个 key
6127.0.0.1:7001> set name yuanpei

我们会发现一个现象,就是 Redis 会告诉你这里有一次重定向,如图所示,它从 7001 重定向到了 7002,这是因为按照 CRC16 算法计算出的结果,name 这个键应该被分配到 7002 上存储:

通过 redis-cli 向 Redis 集群写入值
通过 redis-cli 向 Redis 集群写入值

同理,在我们已经知道 name 这个键存储在 7002上的情况下,我们依然可以从集群中的其它节点上读取到这个值:

通过 redis-cli 向 Redis 集群读出值
通过 redis-cli 向 Redis 集群读出值

可以注意到,集群依然可以自动地从 7004 重定向到 7002,这表明,我们可以从集群中的任何一个节点上查询数据,并且每个节点上都存储着不同的数据,这可不就是数据分片吗?这恰恰印证了我一开始的观点,即:Redis 的集群模式,本质上是一种服务器 Sharding 技术。果然,博主诚不欺人也,哈哈!

Redis 集群投票示意图
Redis 集群投票示意图

到目前为止,我们已经搭建出了一个基本的 Redis 集群,你可能会问,如果集群中某个节点发生宕机该怎么办呢?此时,我们要注意区分,这是主观宕机还是客观宕机。什么是主观宕机呢?就是某个节点认为你挂了;什么是客观宕机呢?就是集群内超过半数的节点认为你挂了。事实上,只有客观宕机会触发故障转移,而所谓的故障转移,其实就是从故障节点的从节点中挑选一个出来继续提供服务,此时,需要有超过半数以上的主节点给这个从节点投票,这样,Redis 集群就会让它当选为新的主节点,谁能想到,在以绝对理性著称的技术世界里,居然会有如此民主而科学的做法呢?可少数服从多数,真的就是对的吗?

本文小结

坦白讲,这篇文章写起来非常费劲,因为它里面关联的知识点非常密集,从经典哈希算法到一致性哈希算法,再到 Redis 集群里的哈希槽,这是一个循序渐进的认知过程,我们由此认识到,Redis 的集群模式,本质上是由多个主从复制模式组成的服务器分片技术,它通过哈希槽来管理集群内的节点和数据,而节点间则是通过 TCP 协议互相通信,这使得我们可以从任意节点上查询数据,因为 Redis 集群会帮助我们实现连接的重定向。与此同时,Redis 集群内通过投票来实现故障转移,其触发机制是超过半数的节点认为该节点宕机,即客观宕机,此时,就需要从该节点的从节点中筛选一个继续提供服务,当然,这个筛选还是投票决定的,谁能说这不是一种现实世界的投影呢?好了,以上就是这篇博客的全部内容啦,关于 Gossip 协议等更细节的东西,留到以后有机会再写吧…..!

Built with Hugo
Theme Stack designed by Jimmy