深入学习 Redis Cluster - 基于 Docker、DockerCompose 搭建 Redis 集群，处理故障、扩容方案 - 码农知识堂

深入学习 Redis Cluster - 基于 Docker、DockerCompose 搭建 Redis 集群，处理故障、扩容方案
目录

一、基于 Docker、DockerCompose 搭建 Redis 集群

1.1、前言

1.2、编写 shell 脚本

1.3、执行 shell 脚本，创建集群配置文件

1.4、编写 docker-compose.yml 文件

1.5、启动容器

1.6、构建集群

1.7、使用集群

1.8、如果集群中，有节点挂了，怎么办？

二、集群故障、扩容处理

2.1、集群故障处理

a）故障判定

b）故障迁移

2.2、集群宕机

2.3、集群扩容

a）分析

b）将新的主节点 110 加入到集群中

c）重新分配 slots

问题：如果在搬运 slots / key 的过程中，客户端能否访问 redis 集群呢？

一、基于 Docker、DockerCompose 搭建 Redis 集群

1.1、前言

当前阶段，由于我只有一个云服务器，搞分布式系统就比较麻烦，而实际工作中，一般是通过多个主机的方式来搭建集群的.

因此这里我会基于 docker、docker-compose（容器编排）来搭建 redis 集群.

Ps：搭建前，一定要把之前启动的 redis 容器停止.

1.2、编写 shell 脚本

在 linux 上，以 .sh 为后缀的文件称为 “shell 脚本” ，通过这个文件，我们就可以把平时在 linux 上执行的指令，批量化执行，同时，还能加入条件、循环、函数等机制.

这里我们创建 11 个 redis 节点. 这些 redis 的配置文件内容，大同小异，因此这里使用脚本来批量生成（也可以不使用脚本，手动一个一个改）.
```
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
 
# 注意 cluster-announce-ip 的值有变化，和上面分开写也是因为这个原因
 
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
```
for port in $(seq 1 9)：表示一个循环，seq 是一个 linux 命令，生成 [1, 9] 数字，依次赋值给变量 port.

do、done：在 shell 中 { } 用来表示变量，不是代码块，对于 for，就是使用 do 和 done 来表示代码块开始和结束的（上古时期的编程语言就是这样的）.

\：表示续航符，就是把下一行的内容和当前行，合并成一行. shell 默认情况下，要求把所有代码都写到一行里，但是可以使用续航符来换行继续补充.

第一个循环体的内容（第二个循环体思想也一样）：通过 mkdir 创建 9 个名字分别为 redis1、redis2、redis3......的文件夹，接着，通过 touch redis${port} 在每个文件夹下，创建 redis.conf 文件. 文件的内容（从 EOF 开始，到 EOF 结束）通过 cat 写入到每个 redis.conf 文件中.

字符串拼接：shell 中拼接字符串是直接写在一起的，不需要使用 +.

cluster-enabled yes：开启集群

cluster-config-file：后续启动节点后，自动生成的节点配置文件，会配置一些 redis 集群信息.

cluster-node-timeout 5000：心跳包的超时时间设置为 5000 ms.

cluster-announce-ip：表示当前 redis 节点所在的主机 ip 地址（当前是使用 docker 容器模拟的主机，此处因该是 docker 容器的 ip）.

cluster-announce-port：表示当前 redis 节点自身绑定的端口（容器内的端口）. 不同容器内部可以有相同端口，后续进行端口映射，再把容器外的端口不同端口映射到容器内的端口即可.

cluster-announce-bus-port：一个服务器可以绑定多个端口号，当前这个表示管理端口（刚刚上面讲的是业务端口，是用来进行业务数据通信的），用来完成一些管理以上任务进行通信的（如果某个分片中的 redis 主节点挂了，就需要让从节点成为主节点，就需要通过管理端口来完成）.

1.3、执行 shell 脚本，创建集群配置文件

通过以下命令执行 shell 脚本

centos 执行 shell 脚本命令：
```
sh generate.sh
```
ubuntu 执行 shell 脚本命令：
```
bash generate.sh
```
执行后，会得到 11 个目录，每个目录里都有一个配置文件，配置文件中，ip 地址各不相同

1.4、编写 docker-compose.yml 文件

在配置文件中，需要先手动创建 networks 网络，然后分配网段给后续创建 redis 集群中每一个节点的静态ip.

Ps：这里配置静态 ip（固定 ip）是为了后续观察.
```
version: '3.3'
networks:
  mynet:
    ipam:
      config:
        - subnet: 172.30.0.0/24
```
接着创建 redis 集群中每一个节点
```
services:
  redis1:
    image: 'redis:5.0.9'
    container_name: redis1
    restart: always
    volumes:
      - ./redis1/:/etc/redis/
    ports:
      - 6371:6379
      - 16371:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.101
 
  redis2:
    image: 'redis:5.0.9'
    container_name: redis2
    restart: always
    volumes:
      - ./redis2/:/etc/redis/
    ports:
      - 6372:6379
      - 16372:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.102
 
  redis3:
    image: 'redis:5.0.9'
    container_name: redis3
    restart: always
    volumes:
      - ./redis3/:/etc/redis/
    ports:
      - 6373:6379
      - 16373:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.103
 
  redis4:
    image: 'redis:5.0.9'
    container_name: redis4
    restart: always
    volumes:
      - ./redis4/:/etc/redis/
    ports:
      - 6374:6379
      - 16374:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.104
 
  redis5:
    image: 'redis:5.0.9'
    container_name: redis5
    restart: always
    volumes:
      - ./redis5/:/etc/redis/
    ports:
      - 6375:6379
      - 16375:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.105
 
  redis6:
    image: 'redis:5.0.9'
    container_name: redis6
    restart: always
    volumes:
      - ./redis6/:/etc/redis/
    ports:
      - 6376:6379
      - 16376:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.106
 
  redis7:
    image: 'redis:5.0.9'
    container_name: redis7
    restart: always
    volumes:
      - ./redis7/:/etc/redis/
    ports:
      - 6377:6379
      - 16377:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.107
 
  redis8:
    image: 'redis:5.0.9'
    container_name: redis8
    restart: always
    volumes:
      - ./redis8/:/etc/redis/
    ports:
      - 6378:6379
      - 16378:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.108
 
  redis9:
    image: 'redis:5.0.9'
    container_name: redis9
    restart: always
    volumes:
      - ./redis9/:/etc/redis/
    ports:
      - 6379:6379
      - 16379:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.109
 
  redis10:
    image: 'redis:5.0.9'
    container_name: redis10
    restart: always
    volumes:
      - ./redis10/:/etc/redis/
    ports:
      - 6380:6379
      - 16380:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.110
 
  redis11:
    image: 'redis:5.0.9'
    container_name: redis11
    restart: always
    volumes:
      - ./redis11/:/etc/redis/
    ports:
      - 6381:6379
      - 16381:16379
    command:
      redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.111
 
```
- subnet: 172.30.0.0/24：此处 172.30.0 是网络号，并且 ip 是内网 ip，这就要求不能和你当前主机上现有的其他网段冲突（每个人主机上已有的网段，具体不一定一样）.

ipv4_address: 172.30.0.101：此处配置静态 ip。注意网路号部分要和前面的网一致，主机号部分可以在(1~255 之间随意配置，不重复就行)，但是这里我们需要按照之前在配置文件中写的 cluster-announce-ip 要对应的上，如下图

1.5、启动容器

通过 docker-compose up -d 启动 yml 中配置的所有容器.

1.6、构建集群

此处是把前 9 个主机构建成集群, 3 主 6 从. 后 2 个主机暂时不⽤.

通过以下命令构建即可
```
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
```
--cluster create：表⽰建⽴集群. 后⾯填写每个节点的 ip 和地址（确保这个命令的 IP 和实际环境一致）.

--cluster-replicas 2： 表⽰每个主节点需要两个从节点备份. 这个配置设置了以后，redis 就知道 3 个节点是一伙的（一个分片上的），一共 9 个节点，一共是 3 个分片.

输入 yes 后，如下

1.7、使用集群

现在从 101 - 109 九个节点，是一个集群，使用客户端端连上任意一个节点，本质上都是等价的（每个集群分别存储 “全集” 数据中的一部分，连接任意一个客户端时加上 -c 选项，都可以访问到全集数据）.

建立号集群后，连接客户端，可以通过 -h -p 连接、可以通过 -h 连接，也可以直接通过 -p 连接对外端口，如下（以下都是连接 172.30.0.103:6379 ）:

通过 cluster nodes 查看当前集群的信息.

在集群中存储数据

上图 error 的原因是 k1 这个 key 通过 hash 计算后，得到 slot 是 12706，这个槽位号在刚刚查看的集群信息中是属于 3 号分片的.

报错信息中提示我们，要把客户端请求转发给 103 这个节点.

这样岂不是很麻烦？

实际上，我们可以在启动 redis-cli 的时候，加上 -c 选项，此时 redis 客户端就会根据当前 key 计算出的槽位号，自动找到匹配的分片主机，进一步完成操作.

注意上图，重定向后，redis 连接的客户端也会改变.

另外，如果尝试在从节点上写操作，也会自动重定向到指定的主节点上.

Ps：实际上，以前所讲到的 redis 相关命令，基本上都是都是适用的（除了个别，例如 mset，mget...... 这种可以操作多个 key 的，是不可用的，因为 key 可能都是分散在不同分片上的）.

1.8、如果集群中，有节点挂了，怎么办？

如果挂了的节点是从节点？没事~

如果挂了的事主节点？写操作就不能进行了！此时集群做的工作，和哨兵做的有点类似了，会自动从主节点下的从节点挑一个出来，提拔成主节点.

这里我让 redis1 这个主节点挂掉
```
docker stop redis1
```
redis1 挂掉前，集群信息如下：

redis1 挂掉后，集群信息如下：

可以看出，集群机制，也能处理故障转移.

二、集群故障、扩容处理

2.1、集群故障处理

a）故障判定

1. 每个节点，每秒钟，都会给一些随机的节点发送 ping 包（这里既包含了集群的配置信息，如 id、属于哪个分片、是主节点还是从节点、持有哪些 slots......），收到的节点会返回一个 pong 包. 这里的 ping 包，不是全发一遍，这样设定是为了避免在节点很多的时候，心跳包也是非常多的，严重消耗网络带宽.

2. 当节点 A 给节点 B 发送 ping 包， B 不能如期回应的时候，A 就会重置和 B 的 TCP 连接，如果重连失败，A 就会把 B 设为 PFAIL （相当于主观下线）。

3. A 判定 B PFAIL 后，会通过 redis 内置的 Gossip 协议，和其他节点沟通，向其他节点确认 B 的状态.

4. 如果 A 发现其他还跟多节点也认为 B 为 PFAIL，并且数目超过集群个数的一般，那么 A 就会把 B 标记为 FAIL（相当于客观下线），并且把这个消息同步给其他节点，让其他节点也把 B 标记为 FAIL.

b）故障迁移

首先会有个判定：
- 如果 B 是从节点，就不需要进行故障迁移.
- 如果 B 是主节点，那么就会由 B 的从节点（比如 C 和 D），触发故障迁移.
具体的：

1. 从节点判定自己是否具有参选资格，如果从节点太久没和主节点通信（太久没有同步数据，差异太大），就会失去竞选资格.

2. 有资格的节点，比如 C 和 D ，就会先休眠一定的时间，休眠时间 = 500ms 基础时间 + [0, 500ms] 随机时间 + 排名 * 1000ms，offset 值越大（表明数据越接近主节点），排名越靠前（休眠时间越短），也就是说，休眠时间主要取决于排名.

3. 此时如果 C 的休眠时间到了，C 就会给所有集群中的节点，进行拉票操作，但是只有主节点才有投票资格.（谁休眠时间短，大概率就是新的主节点了）.

4. 主节点会把自己的票投给 C（每个主节点只有 1 票），当 C 收到的票数超过主节点数目的一半，C 就会晋升成为主节点（C 自己执行 slaveof no one，并且让 D 执行 slaveof C）.

5. 同时，C 还会把自己成为主节点的消息，同步给其他集群的节点，大家都会更新自己保存的集群结构信息.

6. 最后，如果之前宕机的主机点恢复了，就会变成从节点接入到集群中.

2.2、集群宕机

以下三种情况会出现集群宕机：

某个分片，所有的主节点和从节点都挂了，这个时候分片就无法提供数据服务了.

某个分片，主节点挂了，但是没有从节点，也无法提供数据服务了.

超过半数的 master 节点挂了，说明集群遇到了非常严重的情况，就得感觉停止下来，检查看是不是有什么问题！

Ps：如果集群中有一个节点挂了，无论是什么节点，我们程序员都因该尽快处理好（最晚，也是第二天上班之前处理好）.

2.3、集群扩容

a）分析

上述操作，已经将 101 ~ 109 9 个主机，构成了 3 主， 6 从结构的集群了.

接下来为了演示扩容，就把 110 和 111 也加入到集群中.

以 110 为 master ，111 为 slave，把数据分片从 3 -> 4.

b）将新的主节点 110 加入到集群中
```
redis-cli --cluster add-node 172.30.0.110:6379 172.30.0.101:6379
```
add-node：第一个 ip 和端口号表示新增的节点是什么，第二个 ip 和端口号表示集群上任意一个节点（任何一个都行，只要是你想加入的某一个集群中的节点即可），表示要把新节点加入到哪个集群中.

之后通过 cluster nodes 就可以看到 redis10 主节点加入集群，但是并没有分配 slots.

c）重新分配 slots

把之前的三组 master 上面的 slots 拎出来，分配给新的 master
```
redis-cli --cluster reshard 172.30.0.101:6379
```
输入命令后，会先打印出当前集群每个机器的情况，然后要求用户输入要切分多少个 slots

4 个分片，一共是 16384，除以 4 得到的就是 4096，因此这里填 4096 即可（给 redis10 切分出 4096 个槽位号）.

紧接着，会询问让哪个节点来接收，直接粘贴 redis10 这个主机的 id 即可.

接着，就让你选择从哪些节点且分出 slots：
1. all：表示从其他每个持有 slots 的 master 都点过来.
2. 手动指定，从某一个或者某几个节点来移动 slots（以 done 为结尾）.
输入 all 之后，不会真正的搬运，而是先给出搬运的计划.

当输入 yes 之后，搬运真正开始，此时不仅仅是 slots 重新划分，也会把 slots 上对应的数据，也搬运到新的主机上.（这是比较重量级的操作）

d）给新的主节点添加从节点
```
redis-cli --cluster add-node 172.30.0.111:6379 172.30.0.101:6379 --cluster-slave
```
执⾏完毕后, 从节点就已经被添加完成了.

问题：如果在搬运 slots / key 的过程中，客户端能否访问 redis 集群呢？

之前咱们了解到哈希槽分区算法，可以知道大部的 key 是不用搬运的，针对这些未搬运的 key，此时可以正常访问的. 针对正在搬运中的 key，是有可能会出现访问出错的情况.

假设客户端访问 k1，集群通过分片算法得到的 k1 是第一个分片的数据，就会重定向到第一个分片的节点，那么就有一种可能，在重定向过去之后，正好 k1 被搬走了，自然就无法访问了.

如果像针对生产环境进行扩容操作，还是得悠着点，比如找个夜深人静的时候，没啥客户端访问集群的时候，进行扩容，就可以把损失降到最低.

很明显，要想追求更高的可用性，让扩容对于用户影响更小，就需要搞一组新的机器，重新搭建集群，并且把数据导进来，使用新集群代替旧集群（但是成本是最高的）.

Ps：关于集群的缩容，就是把一些节点拿掉，减少分片的数量.

不过一般都是进行扩容，很少缩容.
相关阅读:
KM算法解决二分图最大权分配问题
 Windows系统下追踪占用端口的进程名
 docker 网络简介
 3-1、python内置数据类型(字符串类型)
Linux中用嵌套方式打印
 Java 18 还未用上，最新Java 19 则出来了
 day7【代码随想录】移除链表元素
 使用yum安装jdk，并配置环境变量
 Linux 系统 Vi和Vim编辑器—笔记7
Vue | Vue 核心 +
原文地址：https://blog.csdn.net/CYK_byte/article/details/132940548

深入学习 Redis Cluster - 基于 Docker、DockerCompose 搭建 Redis 集群，处理故障、扩容方案

一、基于 Docker、DockerCompose 搭建 Redis 集群

1.1、前言

1.2、编写 shell 脚本

1.3、执行 shell 脚本，创建集群配置文件

1.4、编写 docker-compose.yml 文件

1.5、启动容器

1.6、构建集群

1.7、使用集群

1.8、如果集群中，有节点挂了，怎么办？

二、集群故障、扩容处理

2.1、集群故障处理

a）故障判定

b）故障迁移

2.2、集群宕机

2.3、集群扩容

a）分析

b）将新的主节点 110 加入到集群中

c）重新分配 slots

d）给新的主节点添加从节点

问题：如果在搬运 slots / key 的过程中，客户端能否访问 redis 集群呢？