Redis分布式系统:集群

"还不如留给花园，多一瞬色彩~"?

? ? ? ? 当我们聊到“集群”这一个词，我们脑中构想出的画面，一定是多台机器，构成的分布式系统，这可以被称为一个“集群”。其实，在前篇的哨兵机制下，奇数个监控哨兵，以及多组主从结构的数节点所构成的大的环境，就是一个“广义的集群”。

? ? ? ? 但，在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 号分?时，就可以针对原有的槽位进?重新分配，?如可以把之前每个分?持有的槽位, 各拿出?点, 分给新分?：

? ? ? ? 在我们实际操作中，不需要去指定哪些槽位要被分配，而是告诉Redis哪些分片能被分配Redis 会?动完成后续的槽位分配，以及对应的 key 搬 运的?作。当然这是后面的事情。

问题?: Redis 集群是最多有 16384 个分?吗?????????

? ? ? ? 当Redis分片被设计为16384时，那么每个分片只能对应一个槽位，要保证每个分片上的数据均匀时很难的。

? ? ? ? 当分片包含的槽位够多时，能够直观反映出包含key 的数量。反之，当槽位数量非常少，槽位个数不一定能反应key的个数。实际上 Redis 的作者建议集群分?数不应该超过 1000。

问题?: 为什么是 16384 个槽位?

? ? ? ? 在集群中，各个节点通过心跳包通信。这些心跳包中包含了该节点所持有的槽(slots)。16384个槽位，需要2KB大的空间，这个值基本够用。如果设计为65536个，那么就需要8 KB 位图。如果放在计算机存储中看这个大小着实难以起眼，但在通信频繁的网络中，却十分吃网络带宽，会成为通信成本一个不小的开销。

? ? ? ? 另外，Redis 集群?般不建议超过 1000 个分?所以 16k 对于最? 1000 个分?来说是?够?

? ? ? ? 我们仍是基于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 就会晋升成主节点。(从节点是不会参与投票的)。

????????

#  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集群

④ 集群容灾、故障转移

⑤ 集群扩容、缩容

本篇到此结束，感谢你的阅读。

祝你好运，向阳而生~