0
点赞
收藏
分享

微信扫一扫

MyBatis——MyBatis的缓存

止止_8fc8 2023-12-27 阅读 36

前言

redis 的哨兵的相关业务功能的实现 

哨兵的主要作用是 检测 redis 主从集群中的 master 是否挂掉, 单个哨兵节点识别 master 下线为主管下线, 超过 quorum 个 哨兵节点 认为 master 挂掉, 识别为 客观下线

然后做 failover 的相关处理, 重新选举 master 节点 

我们这里 来看一下 这里的整个流程

 

 

定时发送 ping, pub/sub ”Hello” 频道 

sentinel 这边有单独的定时任务处理部分, 它存取数据, 只做 监听集群中的数据节点, 哨兵节点 的相关功能

定时发送 info, ping, 向 “__sentinel__:hello” 发布当前哨兵的相关信息[ip, port, id, epoch]

info 这边主要是向各个节点发送 info 命令, 然后 哨兵节点这边定时更新 数据节点的元数据信息

ping 这边主要是类似于一个集群心跳的功能 

可以给根据 ping_period, PUBLISH_PERIOD 来更新发送的频率 

72edd505fdd14faa9091701a2538061a.png

 

向各个数据节点发送 PING 之后, 会记录 last_ping_time 等等信息 

这里的 PING 就是一个心跳的功能 

17bb2cacba09445f9e808a4bbc080b63.png

 

哨兵节点这边初始化的时候, 和 master 创建连接的时候, 会订阅 “__sentinel__:hello”

各个哨兵节点就是通过 “__sentinel__:hello” 来感知哨兵列表的 

然后具体的 哨兵节点的哨兵列表的维护就是在 sentinelReceiveHelloMessages 中进行处理的 

9f67f12a00ae4518a537db77b86df01d.png

 

 

哨兵节点认为 master 主观下线

就是 上一次ping心跳 到现在的时间超过了 down_after_period

或者 info心跳信息 到现在的时间超过了 down_after_period+20s

f148c30534b541779410a32c53ab6bb1.png

 

调用堆栈信息如下

959ae1878874474aa13161d1da1eb97f.png

 

 

哨兵集群认为 master 客观下线

当认为 master 客观下线的 哨兵节点数量超过了 quorum 个的时候, 哨兵集群认为 master 客观下线 

0038a23572214ec481b9d2f0bec203d2.png

 

调用堆栈信息如下

01d333c5c19a4d74adb5f467d53b07a5.png

 

 

master 挂掉之后的重新选举 和更新

主观下线之后, 选择 哨兵 master 的流程

sentinelFailoverWaitStart 是选取 哨兵 master 的处理

sentinelFailoverSelectSlave 是从数据节点中选择 master 的处理 

sentinelFailoverSendSlaveOfNoOne 是切换 master 的处理 

e816ebb4208a4f2f9dddcfd485d2a7fb.png

 

 

sentinelFailoverWaitStart 选取哨兵 master 

sentinelGetLeader 是选择哨兵 master 的核心逻辑

哨兵master 才会往下面走下面的 从 slave 节点中选择 master 的流程 

6d80ad70aceb49638aa5b467fcf34169.png

 

选取哨兵 master 的相关处理 

先统计其他哨兵的相关投标, 然后 自己再进行投票 选择票数最多的哨兵 或者 自己

然后 投票之后, 再来选择 票数最多的哨兵 

最终筛选 是否满足基础条件, 大于 (哨兵数量/2+1) 并且大于 master选举的数量 

44a4bfe7fe52498b802f99a42f344086.png

 

 

sentinelSelectSlave 选择新的 master 数据节点

处理方式如下, 筛选掉 一部分的节点, 经过筛选的节点为备选列表, 然后还有具体的选择规则 

筛选掉 主观客观下线 的节点 

筛选掉 失联的节点

筛选掉 ping 网络存在问题的节点 

筛选掉 配置 priority 为 0 的节点 

筛选掉 info心跳 超过一定时间的节点

筛选掉和 master 这边失联时间较长的节点, 说明它可能和集群沟通有问题 

f4b324d202d2421bbda023ec08b72e3a.png

 

master 这边选择规则如下 

优先级为 slave_priority, slave_repl_offset, runId 的比较 

其中 slave_repl_offset 指代的是 该 slave 节点和 master 这边同步的偏移, 偏移越大, 和 master 这边丢失的数据越少 

就我们这里的场景, 挂掉了目前的 master 节点 redis_8002, 然后 redis_8001, redis_8003 的 slave_priority, slave_repl_offset 均相同, 然后就是根据 runId 进行选择了 

f5cb567349884ca38a992e97d8b0f0fb.png

 

然后上下文如下, 根据 runId 的规则, 选择了 redis_8003, 然后 redis_8003 成为了新的 master 节点 

4908a1484e294edc93d6ec2e07269648.png

 

 

Master 信息的传播

其他的哨兵节点是通过 PUBLISH “__sentinel__:hello” 这边的业务处理来进行更新 master 的 

804edb3cd28b4038a22aee9fc7e22dd1.png

 

然后从节点这边的 slaveOf 主从关系是 哨兵节点这边向 slave 节点这边发送的信息 

进而通知 其他的 slave 节点, master 更新了, 需要全量 或者 增量重新同步数据了

7d41693c91754175b2ec530ea59ddee4.png

 

 

 

 

 

举报

相关推荐

0 条评论