Redis Sentinel 服务端实现原理

Redis主从复制-master

 

 

高可用解决方案

三个定时任务

一、每10秒每一个sentinel对master和slave执行info

    (1) 发现slave节点

    (2) 确认主从关系

二、每2秒每一个sentinel经过master节点的channel交换信息(pub/sub)

    (1) 经过_sentinel_:hello频道交互

    (2) 交互对节点的“见解”和自身信息

三、每1秒每一个sentinel对其余sentinel和redis执行ping

    (1) 心跳监测，失败断定依据

 

领导者选举

缘由：只有一个sentinel节点完成故障转移

选举：经过 sentinel is-master-down-by-addr 命令都但愿成为领导者

一、每一个作主观下线的sentinel节点向其余sentinel节点发送命令，要求将它设置为领导者。

二、收到命令的sentinel节点若是没有赞成其余sentinel节点发送的命令，那么将赞成该请求，不然拒绝。

三、若是该sentinel节点发现本身的 number of votes 已经超过sentinel集合半数且超过quorum，那么它将成为领导者。

四、若是此过程有多个sentinel节点成为了领导者，那么将等待一段时间从新进行选择。

 

故障转移（sentinel领导者节点完成）

一、从slave节点中选出一个“合适的”节点做为新的master节点

二、对上面的slave节点执行 slaveof no one 命令让其成为master节点

三、向剩余的slave节点发送命令，让它们成为新的master节点的salve节点，复制规则和parallel-syncs参数有关。

四、更新对原来master节点配置为slave，并保持着对其“关注”，当其回复后命令它去复制新的master节点。

 

选择“合适的”slave节点

一、选择 slave-priority(slave节点优先级)最高的salve节点，若是存在则返回，不存在则继续。

二、选择复制偏移量最大的slave节点（复制的最完整），若是存在则返回，不存在则继续。

三、选择runId最小的salve节点。

 

总结

一、Redis Sentinel 是Redis的高可用使用方案：故障发现、故障自动转移、配置中心、客户端通知。

二、Redis Sentinel 从Redis2.8版本开始才正式生产可用，以前版本生产不可用。

三、尽量在不一样物理机上部署Redis Sentinel全部节点。

四、Redis Sentinel 中的Sentinel节点个数应该为大于等于3且最好为奇数。

五、Redis Sentinel 中的数据节点与普通节点没有区别。

六、客户端初始化时链接的是Sentinel节点集合，再也不是具体的Redis节点，但Sentinel只是配置中心不是代理。

七、Redis Sentinel 经过三个定时任务实现了Sentinel节点对于主节点、从节点其他Sentinel节点的监控。

八、Redis Sentinel 在对节点作失败断定时分为主观下线和客观下线。

九、看懂 Redis Sentinel 故障转移日志对于 Redis Sentinel 以及问题排查很是有帮助。

十、Redis Sentinel 实现读写分离高可用能够依赖 Sentinel 节点的消息通知，获取Redis数据节点的状态变化。