Redis集群自身实现了高可用，当集群内少量节点出现故障时通过自动故障转移保证集群可以正常对外提供服务。
故障发现
1. 主观下线
当cluster-node-timeout时间内某节点无法与另一个节点顺利完成ping消息通信时，则将该节点标记为主观下线状态。
2. 客观下线
当某个节点判断另一个节点主观下线后，该节点的下线报告会通过Gossip消息传播。当接收节点发现消息体中含有主观下线的节点，其会尝试对该节点进行客观下线，依据下线报告是否在有效期内(如果在cluster-node-timeout*2时间内无法收集到一半以上槽节点的下线报告，那么之前的下线报告会过期)，且数量大于槽节点总数的一半。若是，则将该节点更新为客观下线，并向集群广播下线节点的fail消息。
故障恢复
故障节点变为客观下线后，如果下线节点是持有槽的主节点，则需要在它的从节点中选出一个替换它，从而保证集群的高可用，过程如下：
1. 资格检查
每个从节点都要检查最后与主节点断线时间，判断是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-timeout*cluster-slave-validity-factor，则当前从节点不具备故障转移资格。
2. 准备选举时间
从节点符合故障转移资格后，更新触发故障选举时间，只有到达该时间才能执行后续流程。采用延迟触发机制，主要是对多个从节点使用不同的延迟选举时间来支持优先级。复制偏移量越大说明从节点延迟越低，那么它应该具有更高的优先级。
3. 发起选举
当从节点到达故障选举时间后，会触发选举流程：
(1) 更新配置纪元
配置纪元是一个只增不减的整数，每个主节点自身维护一个配置纪元，标示当前主节点的版本，所有主节点的配置纪元都不相等，从节点会复制主节点的配置纪元。整个集群又维护一个全局的配置纪元，用于记录集群内所有主节点配置纪元的最大版本。每次集群发生重大事件，如新加入主节点或由从节点转换而来，从节点竞争选举，都会递增集群全局配置纪元并赋值给相关主节点，用于记录这一关键事件。
(2) 广播选举消息
在集群内广播选举消息，并记录已发送过消息的状态，保证该从节点在一个配置纪元内只能发起一次选举。
4. 选举投票
只有持有槽的主节点才会处理故障选举消息，每个持有槽的节点在一个配置纪元内都有唯一的一张选票，当接到第一个请求投票的从节点消息，回复消息作为投票，之后相同配置纪元内其它从节点的选举消息将忽略。投票过程其实是一个领导者选举的过程。
每个配置纪元代表了一次选举周期，如果在开始投票后的cluster-node-timeout*2时间内从节点没有获取足够数量的投票，则本次选举作废。从节点对配置纪元自增并发起下一轮投票，直到选举成功为止。
5. 替换主节点
当前从节点取消复制变为主节点，撤销故障主节点负责的槽，把这些槽委派给自己，并向集群广播告知所有节点当前从节点变为主节点。
故障转移时间
1. 主观下线识别时间=cluster-node-timeout。
2. 主观下线状态消息传播时间<=cluster-node-timeout/2(消息通信机制会优先选取下线状态节点通信)。
3. 从节点转移时间<=1000毫秒(偏移量最大的从节点最多延迟1秒发起选举，通常一次就会成功)。
所以，failover-time(毫秒) <= cluster-node-timeout + cluster-node-timeout/2 + 1000
故障转移过程
以Redis的集群(伸缩)搭建好的集群模拟主节点故障场景。
集群状态信息
127.0.0.1:6879> cluster nodes
99ea0df1d9683affb1271a5092fc8b15b378adba 127.0.0.1:6885 master - 0 1533780841246 12 connected 0-1364 4096 5461-6826 10923-12287 15018-16383
558b0fb8d44933e694b46c15d05e595ce5ae4fab 127.0.0.1:6886 slave 99ea0df1d9683affb1271a5092fc8b15b378adba 0 1533780844286 12 connected
...
强制关闭6885端口对应的redis进程
$ ps -ef | grep 6885
redis 96825 1 0 Aug04 ? 00:05:03 redis-server 0.0.0.0:6885 [cluster]
$ kill -9 96825
日志分析如下：
. 从节点6886与主节点6885复制中断。
96829:S 08 Aug 19:15:45.870 # Connection with master lost.
96829:S 08 Aug 19:15:45.870 * Caching the disconnected master state.
96829:S 08 Aug 19:15:46.804 * Connecting to MASTER 127.0.0.1:6885
96829:S 08 Aug 19:15:46.805 * MASTER <-> SLAVE sync started
96829:S 08 Aug 19:15:46.805 # Error condition on socket for SYNC: Connection refused
. 6879和6880两个主节点都标记6885为主观下线，超过半数因此标记为客观下线状态。
6879端口日志
22574:M 08 Aug 19:16:02.677 * Marking node 99ea0df1d9683affb1271a5092fc8b15b378adba as failing (quorum reached).
6880端口日志
22578:M 08 Aug 19:16:02.680 * Marking node 99ea0df1d9683affb1271a5092fc8b15b378adba as failing (quorum reached).
. 从节点识别正在复制的主节点进入客观下线后准备选举时间。
6886端口日志
96829:S 08 Aug 19:16:02.682 * FAIL message received from 90cb860b7f4ff516304c577bc1e514dc95ecd09b about 99ea0df1d9683affb1271a5092fc8b15b378adba
96829:S 08 Aug 19:16:02.761 # Start of election delayed for 855 milliseconds (rank #0, offset 1654026).
. 延迟选举时间到达后，从节点更新配置纪元并发起故障选举。
6886端口日志
96829:S 08 Aug 19:16:03.677 # Starting a failover election for epoch 13.
. 6879和6880主节点为从节点6886投票。
6879端口日志
22574:M 08 Aug 19:16:03.679 # Failover auth granted to 558b0fb8d44933e694b46c15d05e595ce5ae4fab for epoch 13
6880端口日志
22578:M 08 Aug 19:16:03.680 # Failover auth granted to 558b0fb8d44933e694b46c15d05e595ce5ae4fab for epoch 13
. 从节点获取2个主节点投票后，超过半数，执行替换主节点操作从而完成故障转移。
6886端口日志
96829:S 08 Aug 19:16:03.688 # Failover election won: I'm the new master.
96829:S 08 Aug 19:16:03.688 # configEpoch set to 13 after successful failover
故障转移后，集群状态信息
127.0.0.1:6879> cluster nodes
99ea0df1d9683affb1271a5092fc8b15b378adba 127.0.0.1:6885 master,fail - 1533780945879 1533780943442 12 disconnected
558b0fb8d44933e694b46c15d05e595ce5ae4fab 127.0.0.1:6886 master - 0 1533803267149 13 connected 0-1364 4096 5461-6826 10923-12287 15018-16383
...
重启6885端口，其会以现有集群配置为准，变为新主节点6886的从节点。
6885端口日志
47931:M 09 Aug 01:35:34.512 # Configuration change detected. Reconfiguring myself as a replica of 558b0fb8d44933e694b46c15d05e595ce5ae4fab
集群内其它节点接收到6885发来的ping消息，清空客观下线状态。
22574:M 09 Aug 01:35:34.520 * Clear FAIL state for node 99ea0df1d9683affb1271a5092fc8b15b378adba: master without slots is reachable again.
此时集群状态信息
127.0.0.1:6879> cluster nodes
99ea0df1d9683affb1271a5092fc8b15b378adba 127.0.0.1:6885 slave 558b0fb8d44933e694b46c15d05e595ce5ae4fab 0 1533804408406 13 connected
558b0fb8d44933e694b46c15d05e595ce5ae4fab 127.0.0.1:6886 master - 0 1533804407394 13 connected 0-1364 4096 5461-6826 10923-12287 15018-16383
...
手动故障转移
Redis集群提供了手动故障转移功能，指定从节点发起转移，主从节点角色进行互换，过程如下：
1. 从节点通知主节点停止处理所有客户端请求。
2. 主节点发送对应从节点延迟复制的数据。
3. 从节点接收复制延迟的数据，直到主从复制偏移量一致。
4. 从节点立刻发起投票选举，选举成功后断开复制变为新的主节点，之后向集群广播。
5. 原主节点接收消息后更新自身配置变为从节点，解除所有客户端请求阻塞，重定向到新的主节点。
6. 原主节点变为从节点后，向新的主节点发起全量复制请求(Redis4.0版本这一过程会有改善)。
6885端口上发起手动转移
127.0.0.1:6885> cluster failover
OK
日志分析如下：
6885端口日志
47931:S 09 Aug 02:11:19.943 # Manual failover user request accepted.
47931:S 09 Aug 02:11:20.010 # Received replication offset for paused master manual failover: 2969
47931:S 09 Aug 02:11:20.011 # All master replication stream processed, manual failover can start.
47931:S 09 Aug 02:11:20.011 # Start of election delayed for 0 milliseconds (rank #0, offset 2969).
47931:S 09 Aug 02:11:20.111 # Starting a failover election for epoch 14.
47931:S 09 Aug 02:11:20.115 # Failover election won: I'm the new master.
47931:S 09 Aug 02:11:20.115 # configEpoch set to 14 after successful failover
47931:M 09 Aug 02:11:20.115 # Connection with master lost.
6886端口日志
96829:M 09 Aug 02:11:19.943 # Manual failover requested by slave 99ea0df1d9683affb1271a5092fc8b15b378adba.
96829:M 09 Aug 02:11:20.113 # Failover auth granted to 99ea0df1d9683affb1271a5092fc8b15b378adba for epoch 14
96829:M 09 Aug 02:11:20.116 # Connection with slave 127.0.0.1:6885 lost.
96829:M 09 Aug 02:11:20.318 # Configuration change detected. Reconfiguring myself as a replica of 99ea0df1d9683affb1271a5092fc8b15b378adba
96829:S 09 Aug 02:11:20.521 * Connecting to MASTER 127.0.0.1:6885
Redis集群还提供了强制故障转移的方法：
1. cluster failover force - 用于主节点宕机且无法自动完成故障转移的情况。
2. cluster failover takeover - 用于集群内一半以上主节点故障的场景，从节点无法收到半数以上主节点投票，无法完成选举过程(慎用)。
若感兴趣可关注订阅号”数据库最佳实践”(DBBestPractice).
