Redis Cluster 搭建筹备工作
- 搭建集群之前，务必有一点须要留神就是选举，因为在现在很多的分布式中间件里，集群都会有选举这个概念，肯定要达到半数以上的节点，才可能发动偏心的投票，否则就会脑裂，比方 redis，zk，es 等，所以至多保障 3 个 master 节点，master 会发动选举投票的。这一点要须知。
-
配置 6 个节点的虚拟机（事后做好）
- 192.168.1.221
- 192.168.1.222
- 192.168.1.223
- 192.168.1.224
- 192.168.1.225
- 192.168.1.226
- 192.168.1.227（新增 Master）
- 192.168.1.228（新增 Slave）
- 每个节点搭建单机 redis，清理 aof 和 rdb 文件（事后做好）
- 如果为单实例的 Redis 设置了明码 password，那么每个节点都必须要设置 masterauth，也就是对应明码，这样是为了 master 挂掉当前，对应的 slave 能够降级为 master。
- 须要留神，选举的过程会短暂的对外不可用。
Redis Cluster 搭建实操演练
附：
敞开 redis
./redis-cli -p < 批改的端口号 > -a < 批改的明码 > shutdown 开启 redis：
./redis-server redis.conf 每个单实例中的 redis.conf 配置：
# 配置 redis 日志，便于查看
logfile /usr/local/redis/redis-221.log
# 开启集群模式
cluster-enabled yes
# 每一个节点须要有一个配置文件，须要 6 份。每个节点处于集群的角色都须要告知其余所有节点，彼此晓得，这个文件用于存储集群模式下的集群状态等信息，这个文件是由 redis 本人保护，咱们不必管。如果你要从新创立集群，那么把这个文件删了就行
cluster-config-file nodes-221.conf
# 超时工夫，超时则认为 master 宕机，随后主备切换
cluster-node-timeout 5000
# 开启 AOF
appendonly yes 创立集群，在任意节点运行如下命令一次：
#####
# 留神 1：如果你应用的是 redis3.x 版本，须要应用 redis-trib.rb 来构建集群，最新版应用 C 语言来构建了，这个要留神
# 留神 2：以下为新版的 redis 构建形式
#####
# 创立集群，主节点和从节点比例为 1，1- 3 为主，4- 6 为从，这也是最经典用的最多的集群模式。cluster-replicas 是几个 slave，- a 是执行机密。./redis-cli --cluster create ip1:port1 ip2:port2 ip3:port3 ip4:port4 ip5:port5 ip6:port6 --cluster-replicas 1 -a 123456 从上图中能够看到，slots 槽，用于装数据，主节点有，从节点没有。
在任意节点查看集群信息：
./redis-cli --cluster check 192.168.1.221:6379 -a 123456 查看主从状态信息：
./redis-cli -a 123456
info replication 搭建集群时的日志
M221 与 S225
M222 与 S226
M223 与 S224
从节点日志，次要进行复制：
cluster nodes 查看各个节点的信息
故障转移
如果一个 master 挂了，那么残余的 2 个 master 会发动投票选举，从挂了的 master 对应的 slave 中选举出一个新的 master，产生故障的 master 不会参加投票，这个要留神。
选举的时候须要半数以上的 master 都投票给同一个 slave，那么他才会成为新的 master。所以 redis 集群中至多须要 3 个主节点，2 个是不行的。而且咱们也是倡议在不同的物理节点下来进行配置，如果是伪分布式集群，那么可能会有问题。
故障转移的次要流程首先是主观下线，而后是主观下线，这个咱们在课程里有说过，要以主观为主，也就是半数以上的 master 都收不到某节点的心跳，则认为他宕机了，此时发动选举。
验证故障转移
- redis 宕机，进行某一台 master，察看日志，以及对应的从。
上图中，225 降级为 master，原来的 221 下线。slots 主动重新分配。 - 重启原来的 221，能够发现，他退出到了 225 的麾下，成为他的 slave，并且进行了主从数据同步。
在新的主 225 中能够看到 221 的退出 ask 询问同步等信息 - 间接敞开 225 服务器，间接关停，相当于服务器炸了。测试后发现，221 成为新的 master，也就是说不论是 redis 宕机还是服务器炸了，对应的 slave 都能被选举为新的 master，因为只有 master 集群主观认为你下线了，那么就会进行选举。
验证数据是否都在主从中获取
./redis-cli -a 123456 -c
set name lee
集群中设值与取值，须要加 -c。
图中数据进入到了主 222 中，那么验证一下从某个从节点中能不能获取，他会跳转到 222 中去获取，因为当初是一个集群状态。
如果不加-c，以单实例模式去操作，那么会报错。
敞开主 222，察看原来设置的数据，在 slave226 转变为 master 后，数据是否存在：
因为数据会主从同步，所以 master 宕机后，slave 中还是会有他的数据。这些数据都是跟着 slot 走的。
master 宕机，他的 slave 降级为 master，再次宕机，看看残余的 2 主 2 从是否运行
紧接下面的，接着敞开新主 226，残余 2 主 2 从，查看状态，你会发现出错，提醒说 slots 调配不平均，因为有一对主从没有的 slot 都没了。
随后在任意节点去查问数据，提醒说以后集群不可用，咱们须要复原了。
多 master 宕机数超过半数以上，集群不可用
同时有 2 个 redis-master 都宕机，那么无奈达到半数以上，此时无奈选举，以后集群不可用。因为速度比拟快，虚拟机里难以演示，所以此处意会一下哈~
(如果半数以上 Master 处于敞开状态那么整个集群处于不可用状态。)
集群节点通信 gossip 理解即可，无需深究
redis 集群模式下的几个节点之间也会互相通信，他们的通信协议是 gossip，各个节点之间会有 ping pong 等音讯类型，每个节点也保护着 redis 的元数据，一旦产生更改会互相发送。
redis 程度扩容，减少节点，从新 shard 调配 slot
新增 192.168.1.227
批改 redis.conf 文件后，启动服务。查看分片信息：
比照现有的 master
比照后他本人尽管标识 master，然而没起作用，也没退出到现有的集群
这个时候须要应用如下命令，把节点退出到以后集群：
# 增加一个新的节点到现有的集群中。第一个 ip 为新节点，第二个 ip 为现有集群中的某个节点 ip
新增 192.168.1.227
./redis-cli --cluster add-node 192.168.1.227:6379 192.168.1.221:6379 -a 123456
如上图，新节点，退出胜利。
这个时候新退出的节点为 master 了，然而从图中看的进去，并没有 slot 槽位信息，咱们还须要从新分槽，能力应用。
# ip 端口是集群中任意一个节点和对应端口号
./redis-cli --cluster reshard ip:port -a 明码
询问须要迁徙多少个 slots，迁徙之后，原来的数据还是存在与 slots 中的，因为哈希后取模的接口还是对应某个 slot，数据还在。
填入须要迁徙的节点 id，也就是新增的 master 的 id，复制进去。
随后输出 all，示意从每个现有 master 中都取出肯定的 slot 进行迁徙。（done 的话是从指定的节点中拿出一部分 slot 来迁徙）
而后再 yes，示意执行 reshard 操作。
期待一段时间迁徙后，迁徙胜利。从新查看集群信息。这个时候 227 中有 2000 个 slot，别离都是从其余节点迁徙的一部分独特组合的。
如此一来，新的 master 节点退出到集群了。
之前的 name 是在别的 master 中，因为 slot 迁徙了，这个时候再查问的时候，他会路由到 227 节点，阐明了数据不会因为节点减少而失落，都会跟着 slot 走。
测试敞开这台新的 master，因为 slot 不残缺，集群不可用。其实也就是说明了整个集群状态下，总数 16384 个哈希槽必须都存在，短少了就不残缺了。所以就必然须要应用高可用，每个 master 下都要挂在至多 1 个 slave。
新加 slave，把他安顿到某个特定的 master 之下
执行如下命令：
./redis-cli --cluster add-node --cluster-slave --cluster-master-id [master-id] [slave-ip:port] [master-ip:port]
增加节点胜利。
这个时候查看，能够看到 228 退出到集群，并且成为了 slave：
228 的分片信息 slave 归属为 227，如此一来 slave 增加到某个 master 下胜利了。
Redis 集群总结
- 读写都是在 master，slave 退出集群，会进行数据同步，连贯集群中的任意主或从节点去读写数据，都会依据 key 哈希取模后路由到某个 master 节点去解决。slave 不提供读写服务，只会同步数据。
- 敞开任意一主，会导致局部写操作失败，是因为从节点不能执行写操作，在 Slave 降级为 Master 期间会有大量的失败。
- 敞开从节点对于整个集群没有影响
- 某个主节点和他麾下的所有从节点全副挂掉，咱们集群就进入 faill 状态，不可用。因为 slot 不残缺。
- 如果集群超过半数以上 master 挂掉，无论他们是否有对应 slave，集群进入 fail 状态，因为无奈选举。
- 如果集群中的任意 master 宕机，且此 master 没有 slave。集群不可用。（同 3）
- 投票选举过程是集群中所有 master 参加，如果半数以上 master 节点与 master 节点通信超时(cluster-node-timeout)，认为以后 master 节点挂掉。
- 选举只会针对某个 master 下的所有 slave 选举，而不是对所有全量的 slave 选举。
- 原先的 master 从新复原连贯后，他会成为新 master 的从服务器。因为主从同步，客户端的写入命令，有可能会失落（为啥？参考主从复制原理 AOF 与 RDB）。redis 并非强一致性，因为主从个性，所以最初一部分数据会失落。CAP 实践。
- 集群只实现了主节点的故障转移；从节点故障时只会被下线，不会进行故障转移。因而，应用集群时，个别不会应用读写拆散技术，因为从节点故障会导致读服务不可用，可用性变差了。所以不要在集群里做读写拆散。