本文总结
1、哨兵集群作用是什么，不配置哨兵集群是否可以？
2、哨兵集群架构
- 哨兵-哨兵、哨兵-redis主从、哨兵-客户端应用 如何建立联系？
- 哨兵集群需要至少几个实例？
3、故障监控和迁移流程。
4、setinel投票原理和涉及投票的场景
- 投票原理？
- 两个场景
- master的客观下线判断流程
- 选出执行主从切换的sentinel节点
1 介绍
在主从模式下，如果主节点发生故障，需要人工进行主从切换。Redis从2.8引入了哨兵集群，代替人工方式，实现自动发现主节点故障和执行主从切换，切换完成之后并通知客户端新的master节点，从而实现高可用。
Q: 哨兵集群作用是什么，不配置哨兵集群是否可以？
A: 可以不配置，只是主从故障需要人工进行处理。哨兵集群是实现自动化处理故障，实现高可用。
2 哨兵集群
通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
哨兵-哨兵同学、哨兵-redis主从、哨兵-客户端应用 如何建立联系？
哨兵集群构建
基于pub/sub的构建哨兵集群。每个哨兵都配置redis主库地址，在哨兵实例启动时，往__sentinel__:hello发送一个消息，其他哨兵监听消息获取此节点信息，并建立连接。
哨兵集群和主从集群建立连接
Sentinel默认以10秒一次的频率向主库发送info命令，获取从库的连接信息，从和从库建立连接
Q: 为什么需要维护哨兵和redis从节点通信？
A: 维护和从节点通信，可以记录从节点是否为主观下线状态，在进行主从切换时，要从上线状态从节点中选取主节点。
哨兵集群和应用服务建立了解
通过pub/sub 哨兵之间组成集群
2.1 投票原理（RAFT协议）
投票原理
如果一个节点接受到大部分的投票max{quorum，N/2+1} ，比如N/2+1 个，则这个sentinel节点就是leader。由于每个sentinel实例只能投一票，所以在投票过程中只能有一个节点可以接受到N/2+1 张票。
sentinel投票的场景
- 监控故障阶段。通过对主机的主观下线进行投票，投票数目超过quorum，则任务客观下线投票。
- 故障迁移，执行主从切换阶段。选出执行主从切换的sentinel节点，获取投票个数超过quorum。
2.1 至少需要3个哨兵
如果只有两个哨兵实例，则需要2/2+1=2台机器，此时一台sentinel机器宕掉，整个sentinel就无法工作了，所以至少需要3台机器。
3 哨兵集群工作原理
3.1 master故障监控
主观下线流程
sentinel节点每秒一次往主/从节点发送PING命令，在规定时间down-after-milliseconds没有返回，就认为服务故障，标识为主观下线。
客观下线流程
为了避免单个哨兵因为自身网络状况不好，而误判主库下线的情况，引入了客观下线。客观下线流程为：
- 发现主库主观下线的sentinel，会向其他setinel节点发送is-master-down-by-addr命令。
- 当超过max{quorum，N/2+1}个哨兵实例都判断主库为主观下线，则当前setinel节点把主库节点就标志为客观下线，即主库发生了故障。
Q：Redis主从实例的主观下线和客观下线的状态是保存在哪里？
A：保存在每个setinel节点。每个sentinel节点都会进行主从监控，所以都保存了一份主从主从节点的状态。
3.2 选取执行主从切换的sentinel节点
只有确认主库节点客观下线的机器会才能发起投票，投票流程：
- 发现主库主观下线的sentinel节点会向其他setinel节点发送is-master-down-by-addr命令，请求把资金设置为leader。
- 当超过max{quorum，N/2+1}个哨兵实例回复同意，则当前setinel节点把主库节点成为leader。
在投票流程中，可能同时会有多个sentinel节点发起投票，导致leader没有选举出来。此时策略：等待failover_start_time+1s内随机数，进行再次选举。
3.3. 执行故障迁移
STEP1 选择slave作为主节点。
- 过滤主观下线状态的从节点
- 选择slave-priority最高的节点（在配置文件中配置），如果有则返回没有就继续选择
- 选择复制偏移量最大的从节点，因为偏移量越大说明数据复制的越完整。如果存在就返回，否则就继续
- 选择run_id最小的节点
STEP2 执行主从切换。Sentinel leader对选举得到从节点执行slaveof no one命令，成为master节点
STEP3 通知从节点。Sentinel leader向剩余的从节点发送slaveof {materHost} {materPort}命令，让它们成为新master的 从节点。
Q： 主从库切换完成，从库同步新的主节点是需要做一次全量同步吗？
A：在Redis 4.0前，主从切换后，从库需要和主库做全量同步。但是，在Redis 4.0后，Redis做了优化，从库可以只和新主库做增量同步就行。
STEP4 通知客户端，更新maste节点。