Redis Cluster 搭建筹备工作

  1. 搭建集群之前，务必有一点须要留神就是选举，因为在现在很多的分布式中间件里，集群都会有选举这个概念，肯定要达到半数以上的节点，才可能发动偏心的投票，否则就会脑裂，比方redis，zk，es等，所以至多保障3个master节点，master会发动选举投票的。这一点要须知。

  2. 配置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）
  3. 每个节点搭建单机redis，清理aof和rdb文件（事后做好）
  4. 如果为单实例的Redis设置了明码password，那么每个节点都必须要设置masterauth，也就是对应明码，这样是为了master挂掉当前，对应的slave能够降级为master。
  5. 须要留神，选举的过程会短暂的对外不可用。

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# 开启AOFappendonly 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 123456info replication


搭建集群时的日志

M221与S225

M222与S226

M223与S224

从节点日志，次要进行复制：

cluster nodes 查看各个节点的信息

故障转移

如果一个master挂了，那么残余的2个master会发动投票选举，从挂了的master对应的slave中选举出一个新的master，产生故障的master不会参加投票，这个要留神。

选举的时候须要半数以上的master都投票给同一个slave，那么他才会成为新的master。所以redis集群中至多须要3个主节点，2个是不行的。而且咱们也是倡议在不同的物理节点下来进行配置，如果是伪分布式集群，那么可能会有问题。

故障转移的次要流程首先是主观下线，而后是主观下线，这个咱们在课程里有说过，要以主观为主，也就是半数以上的master都收不到某节点的心跳，则认为他宕机了，此时发动选举。

验证故障转移

  1. redis宕机，进行某一台master，察看日志，以及对应的从。

    上图中，225降级为master，原来的221下线。slots主动重新分配。
  2. 重启原来的221，能够发现，他退出到了225的麾下，成为他的slave，并且进行了主从数据同步。

    在新的主225中能够看到221的退出ask询问同步等信息
  3. 间接敞开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集群总结

  1. 读写都是在master，slave退出集群，会进行数据同步，连贯集群中的任意主或从节点去读写数据，都会依据key哈希取模后路由到某个master节点去解决。slave不提供读写服务，只会同步数据。
  2. 敞开任意一主，会导致局部写操作失败，是因为从节点不能执行写操作，在Slave降级为Master期间会有大量的失败。
  3. 敞开从节点对于整个集群没有影响
  4. 某个主节点和他麾下的所有从节点全副挂掉，咱们集群就进入faill状态，不可用。因为slot不残缺。
  5. 如果集群超过半数以上master挂掉，无论他们是否有对应slave，集群进入fail状态，因为无奈选举。
  6. 如果集群中的任意master宕机，且此master没有slave。集群不可用。（同3）
  7. 投票选举过程是集群中所有master参加，如果半数以上master节点与master节点通信超时(cluster-node-timeout)，认为以后master节点挂掉。
  8. 选举只会针对某个master下的所有slave选举，而不是对所有全量的slave选举。
  9. 原先的master从新复原连贯后，他会成为新master的从服务器。因为主从同步，客户端的写入命令，有可能会失落（为啥？参考主从复制原理AOF与RDB）。redis并非强一致性，因为主从个性，所以最初一部分数据会失落。CAP实践。
  10. 集群只实现了主节点的故障转移；从节点故障时只会被下线，不会进行故障转移。因而，应用集群时，个别不会应用读写拆散技术，因为从节点故障会导致读服务不可用，可用性变差了。所以不要在集群里做读写拆散。