"还不如留给花园，多一瞬色彩~"
当我们聊到“集群”这一个词，我们脑中构想出的画面，一定是多台机器，构成的分布式系统，这可以被称为一个“集群”。其实，在前篇的哨兵机制下，奇数个监控哨兵，以及多组主从结构的数节点所构成的大的环境，就是一个“广义的集群”。
但，在Redis中“集群”一词是有所区别的，在Redis中有一种模式也叫做“集群”，这种“狭义的集群”，主要是为了解决存储空间不足的问题。
——前言
Redis集群模式
哨兵机制(模式)能够提高了系统的高可用性，能够对数据节点的性能进行有效监控。但，哨兵机制下，实质上仍然是主从节点存储整个数据集，存储的压力完完全全压在了主节点上，哨兵节点仅仅是作为一种警示器，并在数据节点出现问题时，做出一定的恢复操作。
在现如今大数据“爆棚”的时代，如何获取足够大的空间？最有效、最直接的方法就是增加机器，所谓 "⼤数据" 的核⼼, 其实就是⼀台机器搞不定了, ⽤多台机器来搞。
Redis 的集群就是在上述的思路之下,引入了多组Master/Slave，每一组存储数据全集的⼀部分, 从⽽构成⼀个更⼤的整体, 称为 Redis 集群。例如，我们现如今由1TB 数据，现在我们有三组
Master/Slave，每一组存储着1TB中的1/3，从而能够减少各组的存储压力。
由此，只要公司有足够多台机器，那么存储任意大小的数据都不在话下。
Redis数据分片
那么现在，我们的问题就在于，如何将要存储的数据进行划分呢？当给的一个数据Key，我们需要知道着Key应该被存储在哪一个分片上，读取时，又应该去哪一个分片上读取。围绕这个问题，我们能够很直观地想到使用 “哈希思想” 来解决这个问题。
在Redis中，每一组节点可以被称为“片”。现目前，有三种主流的分片方式。
(1) 哈希求余
借鉴了哈希表的基本思想：借助hash函数可以把一个key，映射到整数，再针对数组长度求得下表。
例如，现在我们有三个分片，编号分别为0、1、2，此时我们得到一个key值，并通过哈希算法(比如使用: md5)，再将这个结果%3，假设结果为0，那么这个key就应当被放在编号为0的分片上。 
哈希求余十分简单高效，我们可以通过精密设计哈希函数，让数据分布更加均匀
然而，集群一旦进⾏扩容, N 改变了, 原有的映射规则被破坏，就需要让节点之间的数据相互传输，重新进行编排，以满足新的映射规则。此时，我们遍历所有分片中的数据，并通过重新的映射规则，将这些数据搬运到 新的分片之中。这巨大的搬运工作，无疑是耗时费力的。
(2) ⼀致性哈希算法
为了降低搬运的工作，能够更⾼效扩容, 业界提出了 "⼀致性哈希算法"。
哈希求余取得的值经过规则映射后，放到不同的分片之中，一旦规则发生改变，它们的在新的映射规则里，就会被放到新的分片之中。究其原因就在于，分片中的key值，在新的映射规则里，不再属于同组了，而是交叉的。存储在0号分片的数据，在新的规则下需要去到1号分片，而其他放在0号的数据，在新的规则下又得放在2号分片当中。
在"⼀致性哈希算法"中，把集群中的地址空间映射到了一个逻辑上的圆环上，并通过hash算法将key值的结果放到对应的分片范围之中： 
在这种情况下，出现一个新的分片，那么它需要在这个圆环中，选择一块新的范围，作为自己的分片管理范围。 
此时, 只需要把 0 号分⽚上的部分数据,搬运给 3 号分⽚即可. 1 号分⽚和 2 号分⽚管理的区间都是不变的。这样极大减少了数据搬运的工作量。
优点: ⼤⼤降低了扩容时数据搬运的规模, 提⾼了扩容操作的效率.缺点: 数据分配不均匀 (有的多有的少, 数据倾斜)
(3) 哈希槽分区算法
最后这一种方法，也是Redis选择的方法。为了解决上述问题 (搬运成本⾼ 和 数据分配不均匀), Redis cluster 引⼊了哈希槽 (hash slots) 算法。
hash_slot = crc16(key) % 16384哈希槽总共会被分为个16384个槽位上，每一个key值被转换后，就会被放在这 [0, 16383] 的槽位上。然后再把这些槽位⽐较均匀的分配给每个分⽚. 每个分⽚的节点都需要记录⾃⼰持有哪些分片。例如，我们现如今有三个分片，可以进行如下的分配方式：
• 0 号分⽚: [0, 5461], 共 5462 个槽位• 1 号分⽚: [5462, 10923], 共 5462 个槽位• 2 号分⽚: [10924, 16383], 共 5460 个槽位
这里的分片槽位是很灵活的，Redis内部是通过使用bitmap位图结构区分，这个分片上是否拥有该槽位号，这个位图至少占用占2KB空间(16384(bit)= 2048(byte) = 2 * 1024)。
当我们新增⼀个 3 号分⽚时，就可以针对原有的槽位进⾏重新分配，⽐如可以把之前每个分⽚持有的槽位, 各拿出⼀点, 分给新分⽚：
• 0 号分⽚: [0, 4095], 共 4096 个槽位• 1 号分⽚: [5462, 9557], 共 4096 个槽位• 2 号分⽚: [10924, 15019], 共 4096 个槽位• 3 号分⽚: [4096, 5461] + [9558, 10923] + [15019, 16383], 共 4096 个槽位
在我们实际操作中，不需要去指定哪些槽位要被分配，而是告诉Redis哪些分片能被分配Redis 会⾃动完成后续的槽位分配，以及对应的 key 搬 运的⼯作。当然这是后面的事情。
问题⼀: Redis 集群是最多有 16384 个分⽚吗?
当Redis分片被设计为16384时，那么每个分片只能对应一个槽位，要保证每个分片上的数据均匀时很难的。
当分片包含的槽位够多时，能够直观反映出包含key 的数量。反之，当槽位数量非常少，槽位个数不一定能反应key的个数。实际上 Redis 的作者建议集群分⽚数不应该超过 1000。
问题⼆: 为什么是 16384 个槽位?
在集群中，各个节点通过心跳包通信。这些心跳包中包含了该节点所持有的槽(slots)。16384个槽位，需要2KB大的空间，这个值基本够用。如果设计为65536个，那么就需要8 KB 位图。如果放在计算机存储中看这个大小着实难以起眼，但在通信频繁的网络中，却十分吃网络带宽，会成为通信成本一个不小的开销。
另外，Redis 集群⼀般不建议超过 1000 个分⽚所以 16k 对于最⼤ 1000 个分⽚来说是⾜够⽤
Redis集群搭建
我们仍是基于docker，模拟分布式系统的场景，在低配置的云服务器上完成Redis集群的搭建。
Redis集群的拓扑图如下：
(1) 创建目录和配置
创建 redis-cluster ⽬录. 内部创建两个⽂件
谈谈shell脚本
在Linux系统中，以.sh结尾的文件，统称为“脚本”。我们使用Linux系统时，都是以命令的形式进行操作。这些命令，非常适合写到一个文件之中，进行批量化执行。同时，还能再这些文件之中加入条件、循环、函数等机制，从而能够完成一些复杂的工作。
① 生成Redis节点的配置文件
generate.sh 内容如下：
for port in $(seq 1 9); \
do \
mkdir -p redis${port}/
touch redis${port}/redis.conf
cat << EOF > redis${port}/redis.conf
port 6379
bind 0.0.0.0
protected-mode no
appendonly yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 172.30.0.10${port}
cluster-announce-port 6379
cluster-announce-bus-port 16379
EOF
done
for port in $(seq 10 11); \
do \
mkdir -p redis${port}/
touch redis${port}/redis.conf
cat << EOF > redis${port}/redis.conf
port 6379
bind 0.0.0.0
protected-mode no
appendonly yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 172.30.0.1${port}
cluster-announce-port 6379
cluster-announce-bus-port 16379
EOF
done在我们的预期之中，得到11个目录，每一个目录中有一个节点配置文件，每个配置文件中的ip地址是不同的：
bash generate.sh 通过bash执行脚本后，我们得到如下目录表：
以Redis1/redis.conf为例：
区别在于每个配置中配置的 cluster-announce-ip 是不同的, 其他部分都相同。
👑 配置说明：
• cluster-enabled yes 开启集群.• cluster-config-file nodes.conf 集群节点⽣成的配置• cluster-node-timeout 5000 节点失联的超时时间.• cluster-announce-port 6379 节点⾃⾝的业务端⼝.• cluster-announce-port 6379 节点⾃⾝的业务端⼝.• cluster-announce-bus-port 16379 节点⾃⾝的总线端⼝. 集群管理的信息交互 是通过这个端⼝进⾏的.
(2) 编写 docker-compose.yml
在外面编写了各个节点启动时的配置文件后，到了现在使用docker去创建容器，并在这些容器中启动Redis服务。
① 创建局域网
docker会为每一个新创建的容器创建新的局域网，各个局域网内部默认是不互通的。所以，在配置文件时，需要首先申请networks，并分配网段，“172.30.0.0/24”，这里分配网段，是为了契合redis.conf文件中写死的静态ip。
② 配置每个节点. 注意配置⽂件映射, 端⼝映射, 以及容器的 ip 地址
每个容器都是独立的，所以它们可以使用相同的端口号。如果想要通过外部机器，访问容器内的端口，就需要在配置.yml文件中，建立容器端口和外界端口的映射关系。
此处的端⼝映射不配置也可以,。配置的⽬的是为了可以通过宿主机 ip + 映射的端⼝进⾏访问. 通过 器⾃⾝ ip:6379 的⽅式也可以访问。
我们使用docker compose统一启动容器：
(3) 构建集群
启动容器后，每一个容器上都 运行着redis-server，现在，需要我们使用：
# 创建集群
redis-cli --cluster create redis_node(ip:port) --cluster-replicas n
--cluster create 表⽰建⽴集群. 后⾯填写每个节点的 ip 和地址
--cluster-replicas n 表⽰每个主节点需要n个从节点备份
# 示例：
redis-cli --cluster create 172.30.0.101:6379 172.30.0.102:6379
172.30.0.103:6379 172.30.0.104:6379
172.30.0.105:6379 172.30.0.106:6379 172.30.0.107:6379
172.30.0.108:6379 172.30.0.109:6379 --cluster-replicas 2
# 末尾表示从节点个数此处是把前 9 个主机构建成集群, 3 主 6 从. 后 2 个主机暂时不⽤(这两个作为之后扩容的主机待命)。参与构建集群的redis节点都是平等的，所以谁是主节点，谁是从节点不是固定的。但，你总得告诉Redis节点集群的特点(如上述：--cluster-replicas 2)。
执行完成命令后，我们可以看到如下界面：
如此，集群也就搭建好了。此时, 使⽤客⼾端连上集群中的任何⼀个节点, 都相当于连上了整个集群。
正因为我们在docker-compose.yml文件中，建立了容器内外端口的映射，所以我们可以是使用两种不同的方式访问redis-server。
# 查看集群节点信息
cluster nodes
现在，我们是否可以直接存储数据了呢？我们来试试看：
我们可以直观发现，直接插入这个值是报错的，其原因就在于，key1进行哈希映射后，应该存放的分片是第二个分片，而不是现目前的第一分片内。反观，我们直接插入key2，则能够插入成功，说明key2经过哈希映射后，就是第一分片内。
那如何解决呢？难道拿着每个分片去试？ 那肯定很太呆瓜了。
# 加上-c选项，会⾃动把请求重定向到对应节点
redis-cli -port xxx -c
我们不仅成功插入了该节点值，访问请求也从第一个分片，重定向到了第二分片！
所以，在集群之后，Redis之前的有一些命令就无法正常使用。例如，获取多个key就无法正常执行，因为key都被分配到了不同的分片上。
Redis集群容灾、故障转移
当集群中有节点挂了。如果是从节点，那还好说，因为它不承担写操作。可一旦是主节点挂了呢？一旦客户端发送的全都是写请求，无一例外都会失败。
我们现在⼿动停⽌⼀个 master 节点, 观察其效果：
# 停止容器
docker stop redis1 
我们能够看到，在redis1挂掉之后，集群做的工作就同哨兵类似，会在当前片中选择出从节点，提拔为主节点。
集群机制的处理，也叫做故障转移。
故障转移:
集群机制中的故障转移，同哨兵机制中这块的处理流程还是有一些细微不同的。
① 故障判断
集群中的所有节点, 都会周期性的使⽤⼼跳包进⾏通信。
🥎节点 A 给 节点 B 发送 ping 包, B 就会给 A 返回⼀个 pong 包. ping 和 pong 除了 message type 属性之外, 其他部分都是⼀样的. 这⾥包含了集群的配置信息。
🥎每个节点, 每秒钟, 都会给⼀些随机的节点发起 ping 包, ⽽不是全发⼀遍。
🥎当节点 A 给节点 B 发起 ping 包, B 不能如期回应的时候, 此时 A 就会尝试重置和 B 的 tcp 连接, 看能 否连接成功. 如果仍然连接失败, A 就会把 B 设为 PFAIL 状态。
🥎A 判定 B 为 PFAIL 之后, 会通过 redis 内置的 Gossip 协议, 和其他节点进⾏沟通, 向其他节点确认 B 的状态。(每个节点都会维护⼀个⾃⼰的 "下线列表“)。
🥎此时 A 发现其他很多节点, 也认为 B 为 PFAIL, 并且数⽬超过总集群个数的⼀半, 那么 A 就会把 B 标 记成 FAIL (相当于客观下线), 并且把这个消息同步给其他节点。
这也就是为什么我们使用cluster nodes时，看到redis1 的”FAIL“字样。
以下三种情况会出现集群宕机:
② 故障迁移
如果检测到故障的节点不是主节点，那么就不会执行故障迁移。如果故障节点是主节点就会，触发故障迁移了。所谓故障迁移, 就是指把从节点提拔成主节点, 继续给整个 redis 集群提供⽀持.
具体流程如下:
🏀 从节点判定⾃⼰是否具有参选资格。如果长时间都未与主节点通信过，那么从节点上的数据太过陈旧。
🏀具有资格的节点, ⽐如 C 和 D, 就会先休眠⼀定时间. 休眠时间 = 500ms 基础时间 + [0, 500ms] 随机时间 + 排名 * 1000ms. offset 的值越⼤, 则排名越靠前(越⼩)。 选取节点的过程不重要，重要的是选出节点作为主节点。
🏀 当C的休眠时间先到, C 就会给其他所有集群中的节点, 进⾏拉票操作。
🏀主节点就会把⾃⼰的票投给 C，当 C 收到的票数超过主节点数⽬的⼀半, C 就会晋升成主节点。(从节点是不会参与投票的)。
Redis集群扩容
扩容实在实际开发中比较常见的场景。随着业务的发展, 现有集群很可能⽆法容纳⽇益增⻓的数据. 此时给集群中加⼊更多新的机器, 就可以使 存储的空间更⼤了。
(1) 把新节点加⼊到集群
上⾯已经把 redis1 - redis9 重新构成了集群. 接下来把 redis10 和 redis11 也加⼊集群。
# add-node 后的第⼀组地址是新节点的地址. 第⼆组地址是集群中的任意节点地址 表示要加入到的集群
redis-cli --cluster add-node 172.30.0.110:6379 172.30.0.101:6379
(2) 重新分配 slots
上图能够很清晰地看到，我们新加的节点110是成为了主节点，但没有被分配任何slots。
# 重新分配 reshard 后的地址是集群中的任意节点地址
redis-cli --cluster reshard 172.30.0.101:6379执行后，首先提示我们需要多少个slots。
填入新的id：
一般情况下，是选择第一种方法。
搬运过程：
(3) 给新的主节点添加从节点
光有主节点此时扩容的⽬标已经初步达成，但是为了保证集群可⽤性，我们之前还创建了一个redis11，现在就是要将这个节点加入到才创建的主节点之中。
# 后面需要携带 作为从节点加入
redis-cli --cluster add-node 172.30.0.111:6379 172.30.0.101:6379 --cluster-slave
Redis集群缩容
扩容是⽐较常⻅的, 但是缩容其实⾮常少⻅. 此处我们简单了解缩容的操作步骤即可。
接下来演⽰把 110 和 111 这两个节点删除。
(1) 删除从节点
# redis-cli --cluster del-node [集群中任⼀节点ip:port] [要删除的从机节点 nodeId]
redis-cli --cluster del-node 172.30.0.101:6379 09cc4432e6a407c341186748ea4d5acd691d24a7
(2) 重新分配 slots
redis-cli --cluster reshard 172.30.0.101:6379执⾏后仍然进⼊交互式操作。此时要删除的主节点, 包含 4096 个 slots。这个注解上的这 4096 个 slots 分成三份 (1365 + 1365 + 1366), 分别分给其他三个主节点。这样可以使 reshard 之后的集群各个分⽚ slots 数⽬仍然均匀。
例：分配给 102 1365 个 slots
照此方式，我们将剩余的slot，依次分配给其他的主节点。
(3) 删除主节点
把 110 节点从集群中删除。
# redis-cli --cluster del-node [集群中任⼀节点ip:port] [要删除的从机节点 nodeId]
redis-cli --cluster del-node 172.30.0.101:6379 ac67fc8a7e1e02a3e1d231dd64db9789f4d02879
⾄此, 缩容操作完成.
总结：
本篇我们谈论了如下的几个问题：
① 集群是什么？解决了说明问题？
② 数据分片算法：哈希求余、一致性哈希算法、哈希槽算法
③ 搭建redis集群
④ 集群容灾、故障转移
⑤ 集群扩容、缩容
本篇到此结束，感谢你的阅读。
祝你好运，向阳而生~文章来源：https://www.toymoban.com/news/detail-821141.html
文章来源地址https://www.toymoban.com/news/detail-821141.html
到了这里，关于Redis分布式系统:集群的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
