redis哨兵模式

由于redis主从模式无法解决主从节点的状态监测及异常情况的故障切换，redis引入哨兵模式，进行状态监测和故障切换。
redis哨兵模式是基于主从模式（主从模式优点得以保留）。相对于主从模式需要手动修改redis.properties配置来实现从节点升级为主节点手动干预，哨兵模式可以通过哨兵监测选举实现主从节点的自动化切换。哨兵模式的部署图如下图所示

特点

1. 引入独立哨兵
2. 自动检测状态
3. 主从自动切换
4. 奇数的哨兵数

哨兵模式下存在如下的定时任务

1. 哨兵每1s向所有节点发送ping命令做心跳监测
2. 哨兵每2s向主节点的_sentinel_.hello频道发送命令进行交互
3. 哨兵每10s向所有数据节点发送info命令获取最新的拓扑结构

因为哨兵模式基于主从模式，主从模式的优点（数据同步）得以保存，此处仅介绍状态监测和故障切换的过程

状态监测-节点下线

1. 哨兵每1s进行ping命令，如果发现节点超过时间未回复，标记为主观下线sdown
2. 当标记的主观下线的节点为主节点，会遍历所有的其他sentinel节点询问对该主节点的判断，
3. 超过quorum(默认2)数的sentinel都认为下线的话，标记为客观下线odown
   

哨兵leader选举，在启动故障切换之前，需要在多个哨兵中选举产生一个leader，由leader执行故障切换的过程

1. 假设s1最先完成客观下线，它会向其余Sentinel发送命令is-master-down-by-addr ip port current_epoch runid
2. 请求成为领导者；收到命令的Sentinel如果没有同意过其他Sentinel的请求，就会同意s1的请求，否则拒绝；如果s1发现自己的票数已经超过一半，那么它将成为领导者
   

哨兵leader执行故障切换

1. Sentinel leader在从节点选出一个节点作为新的主节点，执行slaveof no one命令
2. Sentinel leader节点让剩余的从节点成为新的主节点的从节点
3. Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点
   

从节点选举成主节点的策略

当sentinel准备好了要进行failover，并且收到了其他sentinel的授权，那么就需要选举出一个合适的slave来做为新的master。

slave的选举主要会评估slave的以下几个方面：

1. 与master断开连接的次数和时间长短过滤不合适的从节点
   （断开次数>10 and 断开时间>down-after-milliseconds）

2. Slave的优先级（slave-priority N标记优先级，越小越高，0为特殊，永不做主）

3. 数据复制的下标(用来评估slave当前拥有多少master的数据)

4. 进程ID

哨兵模式的优缺点

优点：

1. 自动进行状态监测
2. 故障恢复
3. 数据自动同步，保证从节点的数据备份

缺点：

1. 节点资源存在浪费
2. 没有分担主节点的写压力