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数据节点的状态变化。