目录
一、基于 Docker、DockerCompose 搭建 Redis 集群
问题：如果在搬运 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
donefor 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.shubuntu 执行 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 redis1redis1 挂掉前，集群信息如下：
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:6379add-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：
- all：表示从其他每个持有 slots 的 master 都点过来.
- 手动指定，从某一个或者某几个节点来移动 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：关于集群的缩容，就是把一些节点拿掉，减少分片的数量.
不过一般都是进行扩容，很少缩容.
