Redis主从复制-master
高可用解决方案
三个定时任务
1、每10秒每个sentinel对master和slave执行info
(1) 发现slave节点
(2) 确认主从关系
2、每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
(1) 通过_sentinel_:hello频道交互
(2) 交互对节点的“看法”和自身信息
3、每1秒每个sentinel对其他sentinel和redis执行ping
(1) 心跳监测，失败判定依据
领导者选举
原因：只有一个sentinel节点完成故障转移
选举：通过 sentinel is-master-down-by-addr 命令都希望成为领导者
1、每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将它设置为领导者。
2、收到命令的sentinel节点如果没有同意其他sentinel节点发送的命令，那么将同意该请求，否则拒绝。
3、如果该sentinel节点发现自己的 number of votes 已经超过sentinel集合半数且超过quorum，那么它将成为领导者。
4、如果此过程有多个sentinel节点成为了领导者，那么将等待一段时间重新进行选择。
故障转移（sentinel领导者节点完成）
1、从slave节点中选出一个“合适的”节点作为新的master节点
2、对上面的slave节点执行 slaveof no one 命令让其成为master节点
3、向剩余的slave节点发送命令，让它们成为新的master节点的salve节点，复制规则和parallel-syncs参数有关。
4、更新对原来master节点配置为slave，并保持着对其“关注”，当其回复后命令它去复制新的master节点。
选择“合适的”slave节点
1、选择 slave-priority(slave节点优先级)最高的salve节点，如果存在则返回，不存在则继续。
2、选择复制偏移量最大的slave节点（复制的最完整），如果存在则返回，不存在则继续。
3、选择runId最小的salve节点。
总结
1、Redis Sentinel 是Redis的高可用使用方案：故障发现、故障自动转移、配置中心、客户端通知。
2、Redis Sentinel 从Redis2.8版本开始才正式生产可用，之前版本生产不可用。
3、尽可能在不同物理机上部署Redis Sentinel所有节点。
4、Redis Sentinel 中的Sentinel节点个数应该为大于等于3且最好为奇数。
5、Redis Sentinel 中的数据节点与普通节点没有区别。
6、客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，但Sentinel只是配置中心不是代理。
7、Redis Sentinel 通过三个定时任务实现了Sentinel节点对于主节点、从节点其余Sentinel节点的监控。
8、Redis Sentinel 在对节点做失败判定时分为主观下线和客观下线。
9、看懂 Redis Sentinel 故障转移日志对于 Redis Sentinel 以及问题排查非常有帮助。
10、Redis Sentinel 实现读写分离高可用可以依赖 Sentinel 节点的消息通知，获取Redis数据节点的状态变化。