关于redis:redis-哨兵进阶

3次阅读

共计 1645 个字符,预计需要花费 5 分钟才能阅读完成。

redis – 哨兵(高可用)提了哨兵的作用以及简略配置,这边就讲一讲他的原理。

哨兵是怎么发现其余哨兵的

哨兵与哨兵之间,是须要晓得其余哨兵的衰弱状况以及信息的分享,咱们在后面的配置中,并没有看到其余哨兵地址的配置,只配置了 master 的地址。哨兵通过 redis 的 Pub/Sub 性能,发现也监督的 master/slave 的其余哨兵。
哨兵会往名字为__sentinel__:hello 的 Channel 里发送 hello,此时其余的哨兵就能够接管到音讯,并晓得其余哨兵的存在。

  • 每隔两秒,会向__sentinel__:hello 的 Channel 发送音讯,内容包含 ip, port, runid。
  • Hello 音讯还包含主服务器的残缺以后配置。如果接管哨兵为给定的主服务器配置了比接管到的更老的配置,它会立刻更新到新的配置。
  • 每个哨兵会监听_sentinel__:hello 的 Channel 的音讯,当他发现其余哨兵的信息时,就会被退出哨兵群里。
  • 退出哨兵群里之前,他会判断 runid 是否一样,或者 ip+port 是否一样,如果一样,旧的信息降被移除,用新的信息代替。

哨兵是怎么晓得 master 挂了

每个哨兵,都会给每个节点发送 ping 申请(上面只画了 master,slave 也会发送 ping 申请),如果节点在 down-after-milliseconds(sentinel 的配置,比方 30 秒)内没有响应 sentinel- 1 的 ping 申请,则咱们认为他是被动下线了(SDOWN),如果 sentinel- 2 也发现他没有响应 ping 申请了,此时两个 sentinel 大于等于 quorum(此时是 2),则咱们认为他是主观下线了(ODOWN)。也能够这么了解,比方路人甲认为路人乙很坏,可能是因为他跟路人乙有矛盾,主观的认为他坏,其他人可能并不认可他的想法,所以是主观下线。然而路人丙路人丁等少数人感觉路人很坏,那很可能路人乙真的坏,大家的评估是主观的,所以是主观下线。

那咱们以什么判断是达到了 ODOWN 的条件呢,就是咱们之前配置的 Quorum,然而是否进行故障转移,也要思考到 majority,也就是数量要达到 majority 才运行受权做故障转移。
比方有 5 个哨兵,Quorum 设置为 2,majority 设置为 3,此时 master 没响应哨兵的数量为 2,曾经达到 ODOWN 的条件了,还是不能做故障转移,只有达到 3 的时候,才能够做故障转移。
如果 Quorum 设置为 3,majority 设置为 2,此时 master 没响应哨兵的数量为 2,尽管能够受权做故障转移,然而并没有达到 ODOWN 的条件,还是不能做故障转移。

哨兵是怎么选举 master 的

当 master 被认为是 ODOWN 的时候,哨兵会通过以下几个选举一个 slave 为 master:

  1. 从 master 断开的工夫
  2. slave 的优先级
  3. offset 的值
  4. Run ID

如果 slave 和 master 的断开工夫超过 down-after-milliseconds 的 10 倍 +master 的 SDOWN 的时长,则不思考切换为 master,公示如下:

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

slave 被选举为 master 的程序如下:

  1. redis.conf 配置的优先级,replica-priority 越低优先级越高。
  2. 优先级一样,看 offset,offset 越大,阐明对 master 的同步数据越多。
  3. 看 offset 也一样,则抉择 runid 最小的,抉择最小的是为了在抉择的时候有更多的确定性,而不是随机选一个。

确定了哪个 slave 降级为 master,那哨兵也是要从哨兵中选举一个来做这些操作的。

  1. 对应的 slave 执行 slaveof no one,把 slave 的 role 移除,变为新的 master。
  2. 告诉其余的 slav 指向新的 master。
  3. 告诉应用程序指向新的 master。
  4. 出故障的原 master 重启后,成为新 master 的 slave 节点。
正文完
 0