哨兵机制是保证Redis高可用性的机制之一，一言以蔽之“哨兵”会监控Redis集群中所有节点，当主节点挂掉后会自动选择一个从节点并升级为主节点，这一过程对用户是透明的。并且如果挂了的主节点能恢复工作，也会被重新设置为从节点。客户端连到Redis集群的时候回先连到哨兵(sentinel)上，由哨兵来告诉客户端主节点的地址。
16.1 启动并初始化Sentinel
sentinel本质上是一个特殊的Redis服务器，初始化Sentinel分为两步：1、启动一个普通的Redis服务器 2、替换相关指令使之变为Sentinel
16.1.1 启动普通Redis服务器
Sentinel启动的时候不会读取RDB文件或者AOF文件，也不会执行和操作数据有关的命令，因为它不会操作数据。
16.1.2 Redis变异成Sentinel
Sentinel加载Sentinel特有的指令
16.1.3 开始管理集群
启动一个Redis服务器的时候会在内存里加载一个Redis-server结构体，该结构体里保存Redis服务器所有需要的内容，相应的一个Sentinel也对应内存中一个结构体，该结构体存储所有Sentinel管理集群需要的状态，如集群的master、slaver，在Sentinel初始化的时候回存储整个集群的主节点和从节点的信息。在整个管理周期中，Sentinel会按照一定频率向主、从节点发送信息以更新状态。
并且哨兵不是唯一的，可以设置多个哨兵节点，这些哨兵节点彼此也是互连的。
16.2 检测故障
每一个哨兵都会按每秒一次的频率向所有的主、从节点和其余哨兵发送PING命令，根据PING的结果判断实例是否在线。如果某个节点在给定时间(down-after-milliseconds)毫秒内没有返回有效信号，该节点会被该哨兵认定为主观下线(Subjective Down)。当一个哨兵判断一个节点主观下线后会咨询别的哨兵的意见，如果超过quorm数量的哨兵认为某个节点主观下线，那么该节点被判定为客观下线(Object Down)。
这种考虑是为了避免由于某个哨兵的网络不佳造成的误判，比如某个哨兵和某个节点网络不佳，PING不通，但其实该节点是在线的，如果只有一个哨兵可能会造成该节点挂了的误判。
16.3 故障转移
如果一个主节点被判为客观下线，需要选举出新的主节点，这一过程称为故障转移。由于存在多个哨兵，所以必须选择一个哨兵来完成故障转移。
16.3.1 选举领头哨兵
每一个哨兵节点都可能成为新的领头哨兵，当需要选举领头哨兵的时候，每个哨兵向其余所有哨兵发送命令要求把自己选为领头哨兵，每个哨兵会相应收到的第一个请求，整个选举过程按照先到先得的策略进行。
16.3.2 选举新的主节点
从所有从节点里选举新的主节点，让直接挂了的主节点和剩下的从节点slaveof新的主节点并继续复制。
选取新的主节点的策略是该节点网络通信状况良好，且和挂了的主节点数据一致性最强。哨兵内部维护了所有从节点的一个列表，按照规定的次序依次筛选从节点：网络连接状况好->5s内回复INFO命令->删除与之前主节点断开时间超过阈值->优先级->复制偏移量->从节点ID。整个过程遵循着先考虑网络通信质量，再考虑从节点数据是否足够“新鲜”。