一、Redis集群容灾:容灾(failover)
### --- 故障检测
~~~ 集群中的每个节点都会定期地(每秒)向集群中的其他节点发送PING消息
~~~ 如果在一定时间内(cluster-node-timeout),发送ping的节点A没有收到某节点B的pong回应,
~~~ 则A将B标识为pfail。
~~~ A在后续发送ping时,会带上B的pfail信息, 通知给其他节点。
~~~ 如果B被标记为pfail的个数大于集群主节点个数的一半(N/2 + 1)时,
~~~ B会被标记为fail,A向整个集群广播,该节点已经下线。
~~~ 其他节点收到广播,标记B为fail。
### --- 从节点选举
~~~ raft,每个从节点,都根据自己对master复制数据的offset,来设置一个选举时间,
~~~ offset越大(复制数据越多)的从节点,选举时间越靠前,优先进行选举。
~~~ slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选,
~~~ master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意。
~~~ slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增,
~~~ 并将最新的Epoch 带入到FAILOVER_AUTH_REQUEST 消息中,
~~~ 如果自己未投过票,则回复同意,否则回复拒绝。
~~~ 所有的Master开始slave选举投票,给要进行选举的slave进行投票,
~~~ 如果大部分master node(N/2 +1)都投票给了某个从节点,那么选举通过,
~~~ 那个从节点可以切换成master。
### --- RedisCluster失效的判定:
~~~ 集群中半数以上的主节点都宕机(无法投票)
~~~ 宕机的主节点的从节点也宕机了(slot槽分配不连续)
二、变更通知
### --- 变更通知
~~~ 当slave 收到过半的master 同意时,会成为新的master。
~~~ 此时会以最新的Epoch 通过PONG 消息广播自己成为master,
~~~ 让Cluster 的其他节点尽快的更新拓扑结构(node.conf)。
三、主从切换
### --- 自动切换
~~~ 就是上面讲的从节点选举
### --- 手动切换
~~~ 人工故障切换是预期的操作,而非发生了真正的故障,
~~~ 目的是以一种安全的方式(数据无丢失)将当前master节点和
~~~ 其中一个slave节点(执行cluster-failover的节点)交换角色
~~~ 1、向从节点发送cluster failover 命令(slaveof no one)
~~~ 2、从节点告知其主节点要进行手动切换(CLUSTERMSG_TYPE_MFSTART)
~~~ 3、主节点会阻塞所有客户端命令的执行(10s)
~~~ 4、从节点从主节点的ping包中获得主节点的复制偏移量
~~~ 5、从节点复制达到偏移量,发起选举、统计选票、赢得选举、升级为主节点并更新配置
~~~ 6、切换完成后,原主节点向所有客户端发送moved指令重定向到新的主节点
~~~ # 以上是在主节点在线情况下。
~~~ 如果主节点下线了,则采用cluster failover force或
~~~ cluster failover takeover 进行强制切换。
四、副本漂移
### --- 副本漂移:如图:
~~~ 我们知道在一主一从的情况下,如果主从同时挂了,那整个集群就挂了。
~~~ 为了避免这种情况我们可以做一主多从,但这样成本就增加了。
~~~ Redis提供了一种方法叫副本漂移,这种方法既能提高集群的可靠性又不用增加太多的从机。
![](https://i-blog.csdnimg.cn/blog_migrate/2187b9fe59e04c817f4a601d687e4f8f.png)
### --- Master1宕机,则Slaver11提升为新的Master1
~~~ 集群检测到新的Master1是单点的(无从机)
~~~ 集群从拥有最多的从机的节点组(Master3)中,
~~~ 选择节点名称字母顺序最小的从机(Slaver31)漂移到单点的主从节点组(Master1)。
### --- 具体流程如下(以上图为例):
~~~ 1、将Slaver31的从机记录从Master3中删除
~~~ 2、将Slaver31的的主机改为Master1
~~~ 3、在Master1中添加Slaver31为从节点
~~~ 4、将Slaver31的复制源改为Master1
~~~ 5、通过ping包将信息同步到集群的其他节点