深入浅出Redis高可用：哨兵机制( 二 ) _Redis

在武当，哨兵部门就出过洋相！
那天，某个哨兵监控到掌门人长时间不回复消息，于是主观判断掌门人嗝屁了。于是开始换掌门，发通知，一顿操作下来，掌门人又传来回复说晚饭吃得有点饱，千里传音可能声音比较?。?诒?惶??。
【深入浅出Redis高可用：哨兵机制】这让武林同道看尽了笑话，至今传为茶余饭后的谈资。

客观下线于是，为了防止这种情况的发生，哨兵部门决定加派人手，每个部门至少 3 个人，每次判断掌门嗝屁时如果有多个人得出相同的判断，才能说明这个判断有效。
在 Redis 里，每次部署哨兵集群时至少三台机器来部署，当某个哨兵判断节点主观下线后，就会向其它哨兵发起命令，其它哨兵根据自己的监控情况，给出赞同或者反对的投票。

文章插图
图片
当多数节点（比如 3 个哨兵有 2 个都认可，quorum 可配置这个值）支持节点已下线，该节点会被标记为客观下线。
当判断主节点客户下线后，哨兵机制会进行故障转移操作，即选出一个从节点升级为主节点。
不难理解，如果掌门人挂了，则哨兵部门会重新选一个新的掌门，来接替门派事务。

3.2 节点切换：如何选出新掌门领头哨兵：主持掌门更换仪式首先，哨兵部门会先选一个领头哨兵（leader sentinel），来主持换掌门的仪式。

文章插图
图片
领头哨兵的选举需要从领头候选人（leader candidate）里面?。?而只有发现掌门客观下线的哨兵成员才可以成为候选人。
通过所有哨兵节点给候选人投票，至少得票数过半的候选人才能成为领头哨兵。
为了防止票数重叠（刷票行为），每个节点只可以投一票，并且当节点成为哨兵候选人时，会首先给自己投一票。

不难理解，毕竟换掌门仪式和下任新掌门息息相关，所以每个哨兵都想当这个 leader 。

在 Redis 里面，参选领头哨兵的候选人不止需要拿到半数以上的票，还需要超过配置文件中的 quorum 值才可以成为 leader sentinel 。
为了防止投票数一致的问题，哨兵个数和 Redis 的节点数一样，一般为单数个。

主从故障转移：选出新掌门哨兵集群中选出一个 leader哨兵之后，就开始进行主从故障转移。
在武当，老掌门挂了，谁来当这个新掌门呢？
为了公平起见，哨兵部门制定了一个策略，会从副掌门的向上管理能力、业务熟悉程度以及资历来考虑。
对应 Redis 里选主节点的三大策略：优先级、复制进度、节点 ID 号。

1. 优先级哨兵会根据从节点的优先级进行排序，优先级越小排名越靠前。
在门派中，这可能是看哪个副掌门的向上管理做得更好，和领导走得更近，毕竟，掌门在选接班人时也会有优先级的侧重。

2. 复制进度如果节点的优先级不分上下，则查看数据复制的 slave_repl_offset 参数，这个参数指向了从节点复制数据的偏移量，偏移量越大（复制数据越多）的那个从节点胜出。

想了解更多的，可以看我上一篇文章：救命！只有我还不明白Redis主从复制的原理吗？

这就好比掌门不偏不倚，对待副掌门都一视同仁。这就得考量副掌门的业务熟悉能力了，谁在掌门那里学的本事越多，谁就来当这个新掌门。

3. 节点 ID 号当优先级和复制程度都相同时，就选择从节点 ID 较小的那个（说明排行越高）。
当副掌门的受重视程度和能力不相上下时，就得论资排辈了，看谁资历更高，排行更靠前（大师兄 > 二师兄 > 三师弟），谁就来当这个新掌门。

3.3 通知机制：更换掌门后告知武林同道在哨兵机制的协助下，从节点晋升为主节点，这时机器节点的 IP 等信息都更换了，所以需要知会客户端和新的主节点进行通信，这是通过发布/订阅者机制实现的。