Redis高可用之哨兵模式
Redis的三大特性分别为高性能、高可用、高可扩简称三高，这三大特性奠定了Redis成为一个优秀的中间件的基础，今天聊聊三大特性之一的高可用，Redis采用主从复制以及哨兵模式保证，其结构如下所示。
哨兵模式其实是对主从复制的一种补充，哨兵通过监控主从节点的健康状况确定节点是否正常，如果主节点发生故障那么哨兵会重新选取新的主节点，发起故障转移，后续将新的主节点信息通知到所有的从节点，从而保证Redis的高可用。
从上面的描述中哨兵特点可以概括为监控、选举、故障转移、通知，我们可以进行这样的思考哨兵如何确定主从节点是否发生故障？哨兵是如何进行新主节点的选举以及哨兵如何通知其它从节点呢？
监控
哨兵监控主从节点，主要由哨兵节点向主从节点周期性发送ping命令，如果主从库没有在规定时间内响应那么哨兵节点会将其标记为下线状态，后面就会启动选举，故障转移功能。
但我们思考下如果主节点（从节点误判代价小所以不讨论）只是因为网络阻塞或者网络故障导致无法响应哨兵节点请求，由于单个哨兵节点的误判就让主从节点直接下线，这时后续的选举、故障转移、通知步骤带来的内存开销是极大的。
所以这里引入主观下线和客观下线的概念，不再由单个哨兵节点判断而是由哨兵集群判断，当哨兵集群中存在N个实例，那么最好超过N/2+1个实例（也可以在sentinel.conf文件中配置主观下线的个数）判断主观下线后，这个主节点才能客观下线，如下所示。
选举
如果哨兵集群客观判断主节点下线后，那么哨兵需要在从节点中选取一个新的主节点，整个选举过程分为筛选和打分。
筛选这一步主要是筛选出符合竞选条件的实例
- 检查实例的状态，已下线的实例需要剔除。
- 检查实例的连接情况，如果在sentinel.conf配置了down-after-milliseconds选项（主从节点允许断连的最大时间），主从节点断开时间超过down-after-milliseconds的值次数过高将会被剔除，这里需要注意的是有可能主节点故障导致所有的从节点断开连接这时筛选可能会将所有的从节点剔除，存在取消选举的情况。
打分阶段依靠三个评分规则实例优先级、主从复制进度、实例id
- 实例优先级在redis.conf中6.0版本是replica-priority默认100，值越小优先级越高。
- 主从复制进度，主节点的复制进度为master_repl_offset，从节点的复制进度为slave_repl_offset，由于主节点客观下线那么无法拿到master_repl_offset值，只能比较从节点复制进度slave_repl_offset的最大值。
- 每个实例存在一个实例id，默认使用其实例id最小值为新主库。
故障转移
哨兵会把新的主节点连接信息发送给其它从节点，让从库执行replicaof命令，和新主库建立连接并且完成主从数据同步。
通知
哨兵会把新主节点的连接信息通知给客户端，让客户端将后续的请求发送给新的主节点。
