领导者选举出的Sentinel节点负责故障转移
1）在从节点列表中选出一个节点作为新的主节点，选择方法如下：
a）过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒。
b）选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续。
c）选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续。
d）选择runid最小的从节点。
2）Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
3）Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关
4）Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点
故障转移日志分析
Redis Sentinel拓扑结构
因为故障转移涉及节点关系的变化，所以下面说明中用端口号代表节点。
开始故障转移测试
方法一，强制杀掉对应节点的进程号，这样可以模拟出宕机的效果。
方法二，使用Redis的debug sleep命令，让节点进入睡眠状态，这样可以模拟阻塞的效果。
方法三，使用Redis的shutdown命令，模拟正常的停掉Redis。
-- 此处需要实战操作--稍后补充
节点运维
在介绍如何进行节点下线之前，首先需要弄清两个概念：临时下线和永久下线。
临时下线：暂时将节点关掉，之后还会重新启动，继续提供服务。
永久下线：将节点关掉后不再使用，需要做一些清理工作，如删除配置文件、持久化文件、日志文件。
所以运维人员需要弄清楚本次下线操作是临时下线还是永久下线。通常来看，无论是主节点、从节点还是Sentinel节点，下线原因无外乎
以下几种：
节点所在的机器出现了不稳定或者即将过保被回收。
节点所在的机器性能比较差或者内存比较小，无法支撑应用方的需求。
（1）主节点
如果需要对主节点进行下线，比较合理的做法是选出一个“合适”（例如性能更高的机器）的从节点，使用sentinel failover功能将从节点晋升主节点，只需要在任意可用的Sentinel节点
sentinel failover <master name>在任意一个Sentinel节点上（例如26379端口节点）执行sentinel failover即
Redis Sentinel存在多个从节点时，如果想将指定从节点晋升为主节点，可以将其他从节点的slavepriority配置为0，但是需要注意failover后，将slave-priority调回原值。
（2）从节点和Sentinel节点
如果需要对从节点或者Sentinel节点进行下线，只需要确定好是临时还是永久下线后执行相应操作即可。如果使用了读写分离，下线从节点需要保证应用方可以感知从节点的下线变化，从而把读取请求路由到其他节点。需要注意的是，Sentinel节点依然会对这些下线节点进行定期监控，这是由Redis Sentinel的设计思路所决定的。下面日志显示（需要设置loglevel=debug），6380节点下线后，Sentinel节点还是会定期对其监控，会造成一定的网络资源浪费。
-cmd-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
#Connection refused
-pubsub-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
#Connection refused
...2.节点上线
（1）添加从节点
添加从节点的场景大致有如下几种：
1. 使用了读写分离，但现有的从节点无法支撑应用方的流量。
2. 主节点没有可用的从节点，无法支持故障转移。
3. 添加一个更强悍的从节点利用手动failover替换主节点。
添加方法：添加slaveof{masterIp}{masterPort}的配置，使用redis-server启动即可，它将被Sentinel节点自动发现。
（2）添加Sentinel节点
添加Sentinel节点的场景可以分为以下几种：
1. 当前Sentinel节点数量不够，无法达到Redis Sentinel健壮性要求或者无法达到票数。
2. 原Sentinel节点所在机器需要下线。
添加方法：添加sentinel monitor主节点的配置，使用redis-sentinel启动即可，它将被其余Sentinel节点自动发现。
（3）添加主节点
因为Redis Sentinel中只能有一个主节点，所以不需要添加主节点，如果需要替换主节点，可以使用Sentinel failover手动故障转移。
节点配置
有关Redis数据节点和Sentinel节点配置修改以及优化的方法，前面的章节已经介绍过了，这里给出Sentinel节点配置时要注意的地方：
1. Sentinel节点配置尽可能一致，这样在判断节点故障时会更加准确。
2. Sentinel节点支持的命令非常有限，例如config命令是不支持的，而Sentinel节点也需要dir、loglevel之类的配置，所以尽量在一开始规划好，不过所幸Sentinel节点不存储数据，如果需要修改配置，重新启动即可。
Sentinel节点只支持如下命令：ping、sentinel、subscribe、unsubscribe、psubscribe、punsubscribe、publish、info、role、client、shutdown。具体可以参考源码中sentinel.c。
上面介绍了Redis Sentinel节点运维的场景和方法，但在实际运维中，故障的发生通常比较突然并且瞬息万变，影响的范围也很难预估，所以建议运维人员将上述场景提前做好预案，当事故发生时，可以用脚本或者可视化工具快速处理故障。
