上一节，我们用三台redis组成了cluster，现在我们停掉一台试试：

比较奇怪的是，在停掉其中一台服务器之前建立的链接仍然可以正常执行命令，当我们断开重连时,命令就都被拒绝了：

redis cluster原理 redis cluster_state fail_redis cluster原理

关联知识：

什么时候整个集群不可用(cluster_state:fail)?

如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. 

redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.

如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.

 

为了验证这个说法我们给每个实例配一个slave。 

redis cluster原理 redis cluster_state fail_重启_02

redis cluster原理 redis cluster_state fail_重启_03

 

7004 是7000的slave  7005是7001的slave 7003是7002的slave

我们停掉7000,观察7004的日志：

 

redis cluster原理 redis cluster_state fail_服务器_04

 

除此之外可以从各个实例上看到类似的日志

redis cluster原理 redis cluster_state fail_服务器_05

观察到

Cluster state chage有一个从fail到ok的过程。

通过客户端重连可以验证集群当前是可用的状态

redis cluster原理 redis cluster_state fail_redis_06

 info查看下当前集群的情况

./redis-cli --cluster info 127.0.0.1:7004

 

redis cluster原理 redis cluster_state fail_redis cluster原理_07

 

用check好想能看到更详细的主从信息：

redis cluster原理 redis cluster_state fail_服务器_08

 我们重启7000会不会重新rebalance呢：

redis cluster原理 redis cluster_state fail_服务器_09

 

7000重新加入了cluster 并且成为了7004的slave 又点厉害

 

试试挂掉一对主从：

redis cluster原理 redis cluster_state fail_redis_10

 

不可用了，应该是验证了：“如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ”:

redis cluster原理 redis cluster_state fail_服务器_11

 

恢复之前的master 现在我们直接挂掉2台master 试试：

 

redis cluster原理 redis cluster_state fail_redis cluster原理_12

redis cluster原理 redis cluster_state fail_重启_13

崩掉了 看来剩下的2台slave并没有切换成master，难道是互为sentinel吗。

cluster info 可以查看集群信息 

redis cluster原理 redis cluster_state fail_redis cluster原理_14

 看一下生产某个集群：

redis cluster原理 redis cluster_state fail_重启_15

 

8个master 每个一个从节点16个实例