在主从复制的模式中，Sentinel(哨兵，也是一个Redis服务器)对所有主从服务器进行监视，如果主服务器断线挂掉(太长时间)，从服务器复制中止，Sentinel系统让某个从服务器上位，成为主服务器，其他从服务器依旧是从服务器，原来的主服务器再次上线时就变成从服务器了，提高Redis的可用性。
一、启动并初始化Sentinel
redis-sentinel /path/to/your/sentinel.conf redis-server /path/to/your/sentinel.conf --sentinel
1.初始化服务器
Sentinel本质上只是一个运行在特殊模式下的Redis服务器，所以启动Sentinel的第一步就是初始化服务器，步骤和普通服务器类似，过程略有不同，不载入AOF或RDB文件。功能上也有所差异，内部指自己，外部指客户端。不能使用键值对命令、事务命令、脚本命令、持久化命令；复制命令只允许内部使用；发布与订阅命令中publish只能内部使用等
2.使用Sentinel专用代码，与普通服务器有差别，例如端口号是26379
3.初始化Sentinel状态，保存在结构体sentinelState里，保存服务器所有和Sentinel功能有关的状态
4.初始化Sentinel状态的masters属性
5.创建连向主服务器的网络连接，有两个，命令连接和订阅连接。因为发布与订阅功能中，发送的信息不会保存在redis服务器里，万一客户端掉线，则丢失信息，所以另开一个连接专门接收该频道消息。异步连接。
二、获取主服务器信息
Sentinel默认以十秒一次的频率向监视的主服务器发送INFO命令，主服务器的回复中蕴含了运行ID，从服务器的套接字。
三、获取从服务器信息
通过向主服务器发送INFO命令发现从服务器后，对那些从服务器创建命令和订阅连接，并默认以十秒一次的频率向从服务器发送INFO命令，得到回复后提取这些信息：运行ID、角色role、主服务器套接字、主从连接状态master_link_status、优先级、复制偏移量。(这些信息和操作在后续选新主服务器时用上)
四、Sentinel默认以每两秒一次向主从服务器发送信息，包含自己和对方的 套接字、运行ID、当前配置纪元。
五、接收主从服务器的频道信息
通过订阅连接接收，发现其他监视该服务器的Sentinel并记录，并与其他Sentinel建立命令连接，但不建立订阅连接。
六、主观下线
Sentinel默认每秒一次向所监视的主从服务器发送ping命令，如果在一定时间(主观下线时常，down-after-milliseconds毫秒)内，连续得到无效回复，则该Sentinel修改该实例所对应的实例结构，主观认为该实例挂了。
主观下线时常作用于：监视的主服务器及该服务器下的从服务器、同样监视该主服务器的Sentinel。不同的Sentinel根据各自的主观下线时常判断。
#监视主服务器，自动发现从服务器和其他Sentinel，后面的2表示两个Sentinel认为主观下线就 判定为客观下线 sentinel monitor master 127.0.0.1 6379 2 #设置主观下线时常50000毫秒 senetinel down-after-milliseconds master 50000
七、客观下线
当一个主服务器被所有监视它的Sentinel都认为主观下线，就判定为客观下线，这些Sentinel里选一个领头羊对下线服务器进行故障转移。选领头羊Sentinel规则如下：
- 所有Sentinel都有机会，得票超过半数的被选上；
- 设定客观下线的Sentinel(源)对其他Sentinel(目标)发送命令，要目标把自己设为局部领头羊，局部领头羊先到先得，后续的拒绝，每次选举只能设一次，目标Sentinel对源Sentinel回复命令包含了【局部领头羊运行ID和配置纪元】；
- 如果没有Sentinel得票超过半数，一直选举，每次选举配置纪元都会自增1；
八、故障转移
领头Sentinel在已下线的主服务器的从服务器里选一个当主服务器，已下线的主服务器再上线会变成从服务器。
1.选主服务器
- 要在线；
- 最近5秒内回复过领头Sentinel的INFO命令；
- 与主服务器连接断开时间不长(不超过down-after-milliseconds*10毫秒)；
- 通过上述三点第一维度根据优先级高的排序，第二维度根据复制偏移量大的排序，第三维度根据运行ID小的排序；
2.修改从服务器
领头Sentinel让从服务器去复制新老大
3.旧主服务器重新上线后变从服务器
领头Sentinel改实例结构，对其发送slaveof命令
参考&引用
《redis设计与实现》