深圳中高端网站建设怎么样,网站建设服务器 几核,太原网站科技公司,哪里购买域名哨兵模式介绍
在深入理解Redis主从架构中Redis 的主从架构中#xff0c;由于主从模式是读写分离的#xff0c;如果主节点#xff08;master#xff09;挂了#xff0c;那么将没有主节点来服务客户端的写操作请求#xff0c;也没有主节点给从节点#xff08;slave#…哨兵模式介绍
在深入理解Redis主从架构中Redis 的主从架构中由于主从模式是读写分离的如果主节点master挂了那么将没有主节点来服务客户端的写操作请求也没有主节点给从节点slave进行数据同步了。
在实际生产环境中服务器难免会遇到一些突发状况服务器宕机停电硬件损坏等等一旦发生后果不堪设想。 Redis 在 2.8 版本以后提供的哨兵Sentinel机制它的作用是实现主从节点故障转移。它会监测主节点是否存活如果发现主节点挂了它就会选举一个从节点切换为主节点并且把新主节点的相关信息通知给从节点和客户端。 哨兵的能力包含如下几点 监控 持续监控 master 、slave 是否健康是否处于预期工作状态。 主从动态切换 当 Master 运行故障哨兵启动自动故障恢复流程从 slave 中选择一台作为新 master。 通知机制 竞选出新的master之后通知客户端与新 master 建立连接slave 从新的 master 中 replicaof保障主从数据的一致性。
哨兵集群原理
监控能力
哨模式启用的时候会启动Sentinel的进程。sentinel进程会向所有的master 和 slave 以及其他sentinel进程 发送心跳包1s一次看看是否正常返回响应。 如果slave 没有在规定的时间内响应 sentinel 的 PING 命令 sentinel 会认为该实例已经挂了将它tag为下线状态 同理如果master 没有在规定时间响应 sentinel 的 PING 命令也会被判定为 offline 状态只是会多做一步 自动切换 master 的流程。
PING 命令的回复有两种情况 有效回复返回 PONG、-LOADING、-MASTERDOWN 任何一种 无效回复有效回复之外的回复或者指定时间内返回任何回复。
但是可能存在一些误判的情况比如说网络拥塞、master实例假死、请求延迟导致实例在某个短暂时间段不可用后续又快速恢复了。 如果这时候被我们主动下线了其实整个系统的可用性反而遭到了退化。而且 误判之后的一系列操作master竞选、消息通知slave 与新 master 同步数据都会消耗大量资源。所以误判要不得啊。 为了保证判断的可靠性我们对下线的标识做了区分一种是 主观下线一种是客观下线。 主观下线 哨兵利用 PING 命令来监测 master、 slave 实例节点的状态。如果是无效回复哨兵就把这个实例节点标记为 主观下线 。如果是slave一般是有多从概念直接下线即可但如果是master就需要小心了。需要多个sentinel进投票裁决。哨兵机制采用多个实例组成sentinel集群模式进行部署即哨兵集群。多个哨兵实例一起来判断就可以避免单个哨兵因为自身网络状况不好而误判主库下线的情况。 客观下线 master 是否要下线不是单个sentinel能够决定的上面说了我们会有个sentinel集群大家一起投票超过一半的sentinel 都判断了主观下线这时候我们就把 master 标记为 客观下线认为它是真的不行了。 当 master 被判定为 客观下线 后就算正式没有master了当务之急就是赶紧竞选出一个新的master。 总结 主观下线表示一个哨兵认为某个节点不可用客观下线表示足够多的哨兵对某个节点的主观下线达成一致。只有在客观下线时哨兵才会认定一个节点真正下线。
这里的「一定数量」是一个法定数量Quorum是由哨兵监控配置决定的解释一下该配置
# sentinel monitor master-name master-host master-port quorum
# 举例如下
sentinel monitor mymaster 127.0.0.1 6379 2
这条配置项用于告知哨兵需要监听的主节点 sentinel monitor代表监控。 mymaster代表主节点的名称可以自定义。 127.0.0.1代表监控的主节点 ip6379 代表端口。 2法定数量代表只有两个或两个以上的哨兵认为主节点不可用的时候才会把 master 设置为客观下线状态然后进行 failover 操作。
客观下线 的标准就是当有 N 个哨兵实例时要有 N/2 1 个实例判断 master 为 主观下线 才能最终判定 master 为 客观下线 其实就是过半机制。
主从动态切换
当master下线后sentinel如何从多个slave中选举出一个新的master这就需要通过 筛选 评估 方式进行选举了。
筛选 过滤掉不健康的下线或者断线没有回复哨兵ping响应的从节点。 过滤网路不好的节点通过 down-after-milliseconds评估以往断连情况如果一定周期内如24h从库和主库经常断连而且超出了一定的阈值如 10 次则该slave不予考虑。
评估
筛选掉不健康的实例之后我们就可以对于剩下健康的实例按顺序进行综合评估了。 slave 优先级通过 slave-priority 配置项redis.conf可以给不同的从库设置不同优先级优先级高的优先成为master。 选择数据偏移量差距最小的即slave_repl_offset与 master_repl_offset进度差距其实就是比较 slave 与 原master 复制进度差距。 slave runID在优先级和复制进度都相同的情况下选用runID最小的runID越小说明创建时间越早优先选为master。先来后到原则。
等这几个条件都评估完我们就会选择出最适合slave把他推举为新的master。
信息通知
等推选出最新的master之后后续所有的写操作都会进入这个master中。所以需要尽快通知到所有的slave让他们重新 replacaof 到 master上重新建立runID和slave_repl_offset 来保证数据的正常传输和主从一致性。
信息通知主要通过** Redis 的发布者/订阅者机制来实现的。每个哨兵节点提供发布者/订阅者机制客户端可以从哨兵订阅消息。主从切换完成后哨兵就会向 switch-master 频道发布新主节点的 IP 地址和端口的消息这个时候客户端就可以收到这条信息然后用这里面的新主节点的 IP 地址和端口进行通信了**。
总结
哨兵模式的核心还是主从模式的演变只不过相对于主从模式在主节点宕机导致不可写的情况下多了探活以及竞选机制从所有的从节点竞选出新的主节点然后自动切换。Redis 哨兵模式通过监控、协调和通知机制使得 Redis 集群能够在主节点故障时自动完成切换提高了 Redis 的高可用性。
