Redis 哨兵集群如何实现高可用？（2）

目录

7.slave 配置的自动纠正

8.slave->master 选举算法

9.quorum 和 majority

10.configuration epoch

11.configuration 传播

---

7.slave 配置的自动纠正

        哨兵会负责自动纠正 slave 的一些配置，比如 slave 如果要成为潜在的 master 候选人，哨兵会确保 slave 复制现有 master 的数据;如果 slave 连接到了一个错误的 master 上，比如故障转移之后，那么哨兵会确保它们连接到正确的 master 上。

8.slave->master 选举算法

        如果一个 master 被认为 odown 了，而且 majority 数量的哨兵都允许主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个 slave 来，会考虑 slave 的一些信息:

                ·跟 master 断开连接的时长
                ·slave 优先级
                ·复制 offset
                ·erun id
        如果一个 slave 跟 master 断开连接的时间已经超过了 down-after-milliseconds 的 10 倍,外加 master 宕机的时长，那么 slave 就被认为不适合选举为 master。
                (down-after-milliseconds *10)+ milliseconds_since_master_is_in_SDowN_sta
        接下来会对 slave 进行排序:

        按照 slave 优先级进行排序，slave priority 越低，优先级就越高。
        如果 slave priority 相同，那么看 replica offset，哪个 slave 复制了越多的数据，offset 越靠后，优先级就越高。
        如果上面两个条件都相同，那么选择一个run id 比较小的那个 slave。

9.quorum 和 majority

        每次一个哨兵要做主备切换，首先需要 quorum 数量的哨兵认为 odown，然后选举出一个哨兵来做切换，这个哨兵还需要得到 majority 哨兵的授权，才能正式执行切换。
        如果 quorum         但是如果 quorum >= majority，那么必须 quorum 数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换。

10.configuration epoch

        哨兵会对一套 Redis master+slaves 进行监控，有相应的监控的配置
执行切换的那个哨兵，会从要切换到的新 master(salve->master)那里得到一个 configurationepoch，这就是一个 version 号，每次切换的 version 号都必须是唯一的。
        如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待 failover-timeout 时间，然后接替继续执行切换，此时会重新获取一个新的 configuration epoch，作为新的 version 号。

11.configuration 传播

        哨兵完成切换之后，会在自己本地更新生成最新的 master 配置，然后同步给其他的哨兵，就是通过之前说的 pub/sub 消息机制。
        这里之前的 version 号就很重要了，因为各种消息都是通过一个 channel 去发布和监听的，所以一个哨兵完成一次新的切换之后，新的 master 配置是跟着新的 version 号的。其他的哨兵都是根据版本号的大小来更新自己的 master 配置的。

(ps：一个点赞一份爱，点个关注不迷路！)