一、redis现状

目前redis cluster集群是3主6从，在三台机器上多实例部署，每台机器上部署了三个实例，具体如下图所示：

二、Redis 存在的风险

集群的三个master实例分别部署在三台机器，如果某个host机器down机，剩余的两个master节点会选举一个slave为新的master, 不会有单点故障，但是如果由于某种原因，例如网络抖动，host1上的master1和host2上slave1发生了切换，此时host2机器上就会有两个master节点;

具体如下所示：

此时如果host2发生故障，那么redis将不可用，因为新master的选举需要大于半数的集群master节点同意才能选举成功，所以三个master节点同时死了两个，超过了半数master节点，所以就无法选举新的master节点，集群就不可用了，故该架构存在一些潜在风险;

这里回顾下redis cluster master节点故障切换原理：

1、redis cluster节点间通信协议：

Redis Cluster 实例间以 Gossip 协议进行通信的机制。Redis Cluster 运行时，各实例间需要通过 PING、PONG 消息进行信息交换，这些心跳消息包含了当前实例和部分其它实例的状态信息，以及 Slot 分配信息。这种通信机制有助于 Redis Cluster 中的所有实例都拥有完整的集群状态信息。

2、通信机制和频率：

1)每个实例每 1 秒发送一条 PING 消息。Redis Cluster 的实例启动后，默认会每秒从本地的实例列表中随机选出 5 个实例，再从这 5 个实例中找出一个最久没有通信的实例，把 PING 消息发送给该实例。

2)每个实例每 100 毫秒会做一次检测，给 PONG 消息接收超过 cluster-node-timeout/2 的节点发送 PING 消息。

3、判断节点故障的过程：

集群中当一个节点向另一个节点发送PING命令，但是目标节点未在给定的时限(cluster-node-timeout)内返回PING命令的回复时，那么发送命令的节点会将目标节点标记为PFAIL(possible failuer，可能已失效)，也叫主观下线;

主观下线：指某个节点认为另一个节点不可用， 即下线状态， 这个状态并不是最终的故障判定， 只能代表一个节点的意见， 可能存在误判情况。

客观下线： 集群内多个持有槽的 主节点 都认为该节点不可用， 从而达成共识的结果。 如果是持有槽的主节点故障， 需要为该节点进行故障转移，当下线报告大于持有槽的主节点数量一半时， 标记对应故障节点为客观下线状态。同时向集群广播一条fail消息， 通知所有的节点将故障节点标记为客观下线， fail消息的消息体只包含故障节点的ID

4、选主的过程

选举采用过半机制：有超过一半的主节点投票给这个从节点，这个从节点才被选举成功。

只有持有槽的主节点才会处理故障选举消息(FAILOVER_AUTH_REQUEST) ， 因为每个持有槽的节点在一个配置纪元内都有的一张选票， 当接到第一个请求投票的从节点消息时回复FAILOVER_AUTH_ACK消息作为投票， 之后相同配置纪元内其他从节点的选举消息将忽略。

投票过程其实是一个领导者选举的过程， 如集群内有N个持有槽的主节点代表有N张选票。 由于在每个配置纪元内持有槽的主节点只能投票给一个从节点， 因此只能有一个从节点获得N/2+1的选票， 保证能够找出的特定的从节点。

由此可见要想完成一个master节点的故障切换，也就是slave提升成master，需要保证多数master节点是存活的!

三、Redis改造优化方案

1、申请三台服务器部署redis实例，分别以slave的角色加入进cluster集群，然后把之前多实例部署的redis实例slave角色下架，最终原来机器上只保留master节点即可;

最终cluster架构如下所示：

该架构没有潜在单点故障问题，对多允许依次死3个节点;

2、系统运维修改所有连接redis的服务配置，修改为新的架构配置并重启服务;