哨兵
为什么需要哨兵呢？在Redis的主从架构中，由于主从模式是读写分离的，如果主节点挂了，那么就没有主节点来服务客户端的写操作请求，也没有主节点给从节点进行数据同步。
在这个场景下，我们会尝试进行恢复，假设需要人工介入，选择一个从节点切换为主节点，然后让其他节点指向新的主节点，同时还需要通知上游那些连接Redis主节点的客户端，将配置的主节点IP地址更新为新节点的IP地址。
这听起来是不是很麻烦，一点也不智能？这个时候Redis在2.8版本以后提供的哨兵机制，他的作用是实现主从节点故障转移。他会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并把新节点的相关信息通知给从节点和客户端。
哨兵节点也是一个节点。
哨兵节点主要负责三件事：监控、选主、通知
步骤
1.监控与心跳检测
通常部署 3 个或更多 哨兵节点（奇数个，避免脑裂），它们分布在不同的服务器上。
每个哨兵每隔 1 秒 向所有已知的 Master、Slave 和其他 Sentinel 发送 PING 命令。
如果在规定时间内（由 down-after-milliseconds 配置，默认 30 秒）没有收到回复，或者回复了错误信息（如 +DOWN），哨兵就会认为该节点“有问题”。
2.故障节点主观下线
单个哨兵根据自己的心跳检测结果，认为某个节点（通常是 Master）已经下线。就像是“我觉得它挂了”，其他哨兵可能还觉得它是好的。当哨兵在 down-after-milliseconds 时间内无法连通 Master，标记为 SDOWN。
3.故障节点客观下线
大多数哨兵都认为该 Master 下线了，才确认为真正的下线。就像是选举投票一样。
当一个哨兵发现 Master SDOWN 后，它会向其他哨兵发送 ASK-MASTER-DOWN 询问：“你觉得 Master 挂了吗？”
其他哨兵回复自己的判断。
如果同意 Master 下线的哨兵数量 >= 配置的法定人数（Quorum），则该 Master 被标记为 ODOWN。
为什么要这样子呢？因为避免了因单个哨兵网络抖动而误判导致不必要的故障转移。
4.Sentinel集群选举Leader
如果要选一个节点为主节点，需要从集群中选一个为Leader
毕竟哨兵节点有很多，每个节点选一个主节点肯定会乱套。
但是也会产生一个新的问题，谁来成为Leader？所有发现 ODOWN 的哨兵都会发起选举，每个节点都可以成为Leader。每个哨兵给自己投一票。哨兵向其他哨兵发送 IS-MASTER-DOWN-BY-ADDR 请求投票。如果一个哨兵收到的票数 > 哨兵总数的一半，它就当选为 Leader。
5.Sentinel Leader决定新主节点
1.过滤故障节点
2.选择优先级slave-priority最大（这里优先级最大，数值越小，也就是选择小的数值）的从节点作为主节点，不存在则继续
3.选择复制偏移量，最大的从节点作为主节点，不存在则继续
4.选择runid（redis每次启动的时候生成随机的runid作为redis的标识）最小的节点作为主节点