学习自：Redis 哨兵模式下，Master节点宕机后，进行故障转移的过程
现部署了三台虚拟机上的redis服务，采用哨兵模式进行管理。
- S1：192.168.50.121
- S2：192.168.50.122
- S3：192.168.50.123
日志项说明
1、+sdown master：m的主观下线
+sdown master mymaster 192.168.50.121 6379
sdown：主观下线
解释：当前哨兵（日志文件所属的那个哨兵）认为m宕机，此时为主观下线2、+odown master：m的客观下线
+odown master mymaster 192.168.50.121 6379
odown：客观下线
解释：哨兵集群中有超过<quorum>（默认2）个哨兵都认为master sdown，此时集群会认为m客观下线
3、+new-epoch 1
该项为递增集群状态版本，每个新m都有其对应的epoch。
该项由哨兵集群共同维护。
4、+vote-for-leader：选举哨兵leader，
+vote-for-leader 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1
在哨兵集群中vote投票选举出一个leader，负责本次故障转移过程
5、+try-failover master：尝试故障转移
+try-failover master mymaster 192.168.50.121 6379
开始对IP 192.168.50.121、端口 6379、名为mymaster的redis集群进行故障转移。
6、+elected-leader：再次确认是哪个leader要进行故障转移
+elected-leader master mymaster 192.168.50.121 6379
7、+faileover-state-send-slaveof-noone
+failover-state-send-slaveof-noone slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379
告知某个slave，不要再做slave了，马上就要升级为master
8、+selected-slave
+selected-slave slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379
已经找到了合适的slave作为新的master，它是位于s2上的192.168.50.122 6379号服务
9、+faileover-state-wait-promotion
+failover-state-wait-promotion slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379
等待其他哨兵确认将成为m的slave
10、+promoted-slave
+promoted-slave slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379
其他哨兵都确认成功（已经得知哪个s将成为m）
11、faileover-state-reconf-slaves
+failover-state-reconf-slaves master mymaster 192.168.50.121 6379
开始对集群中的所有s做reconf操作（更新配置信息sentinel.conf），完毕后，在sentinel.conf最后会出现以下配置：
12、+slave-reconf-sent
向指定的s发送"slaveof"命令，令其跟随新的m
13、failover-end
+failover-end master mymaster 192.168.50.121 6379
本次故障转移完毕
14、switch-master：监听新master
+switch-master mymaster 192.168.50.121 6379 192.168.50.122 6379
故障转移完毕后，各个sentinel开始监控新master
15、+slave
原m成为新m的slave
16、+sdown slave
由于原m现在仍是断开状态，所以这里对其进行主观下机
其他
-sdown：取消主观下机状态（意味着重连回来了）