之前我们聊过 redis 的主从同步（复制）主题，这期我们来聊 Redis 的哨兵机制。
上期我们说过，在实际互联网架构上，Redis 为了保证高可用和分担读写压力，几乎都会采取主从复制的部署架构。
一方面让架构易于扩展，另一方面防止单体故障：当主库挂了，可以立即拉起从库，不至于让业务停滞太久。
如果把所有互联网应用看做是一个江湖，Redis 是武林中的门派，为了让门派更加稳定，每个门派都有掌门和副掌门。
在一些小门派里面，掌门仙逝以后，都会开追悼大会，然后从副掌门中再选一个掌门出来主持大局，这个过程可能会持续好几天。
但是，在一些大门派里面，比如武林之中一些有名望的派别：武当、少林（如淘宝、微信）之流，却不可一日无掌门。
放到如今的双 11，电商应用挂几秒钟可能都是千万甚至亿万级别的损失，所以对系统的可用性要求非常高。
一般大型应用的可用性都需要达到 4 个 9：即 99.99%，一年宕机时间不超过 53 分钟。
那以武当（淘宝 Redis）为例，需要如何保证门派的稳定性呢？
首先我们得依赖副掌门机制（主从复制）做备份，上篇我们已经说过了。
这期我们来说一下在掌门挂了后如何高效交接事务（故障转移），武林门派大会 2.8 后，每个门派有一个单独的部门来负责掌门交接事宜——哨兵部门。
Redis2.8 版本以后提供的哨兵机制（Sentinel）。
在武当派，张真人之下有武当七侠，从声望和资历来看，派内将前两位弟子作为副掌门人选，他们平时也会辅助掌门处理门派事务。
而哨兵部门的职责，主要有四点：
图片
其中监控和故障转移功能主要是为了维系系统的稳定，可以第一时间感知几位掌门的状态，当掌门人闭关或者嗝屁以后，能快速地选出一个新的掌门接替门派事务。
而配置提供和通知功能主要是和客户端交互，可以理解为哨兵部门是外宾和门派建立联系的桥梁。
并且，当掌门人易主以后，哨兵机制会向客户端发布新的主节点地址。仿佛在向外界宣布，新掌门联系方式变了，望周知！
哨兵部门这么强横，那它究竟是怎么做到的呢？接下来我们从分别从监控、节点切换、发布通知和节点恢复来详细介绍一下。
虽然说是监控，但哨兵只是对各掌门人的状态是否正常做一个判断，门派事务哨兵是一概不参与的（毕竟人家是掌门&副掌门，哨兵还管不着这么宽）！
在武当派，不管是哨兵部门的成员，还是副掌门之上，都会一招 “千里传音”，以便更好地传递事务消息。
那既然不能参与事务，哨兵如何监控它们的状态呢？
图片
如图所示，哨兵成员会定期给掌门人们千里传音，各掌门如果定时回复，那掌门人就处于正常状态。
反之，如果掌门在规定时间内不回复就说明状态不正常，哨兵就会采取行动。
在 Redis 服务器中，哨兵每隔 1 秒会给主从节点发送 PING 命令，如果在一定时间内收到响应，就说明节点正常运行。
如果任意一个主/从节点没有在规定时间内（down-after-milliseconds 可配置，单位是毫秒）响应，哨兵就认为这个节点挂了，将其标记为主观下线。
为什么是主观下线呢？
因为 Redis 中为了保证监控的稳定性，当一个哨兵没收到回复时，就说明这个节点有概率挂了，但是不一定完全是节点的问题，也有可能是网络故障，或者阻塞了导致消息没有正常传播。
在武当，哨兵部门就出过洋相！
那天，某个哨兵监控到掌门人长时间不回复消息，于是主观判断掌门人嗝屁了。于是开始换掌门，发通知，一顿操作下来，掌门人又传来回复说晚饭吃得有点饱，千里传音可能声音比较小，哨兵没听到。
这让武林同道看尽了笑话，至今传为茶余饭后的谈资。
于是，为了防止这种情况的发生，哨兵部门决定加派人手，每个部门至少 3 个人，每次判断掌门嗝屁时如果有多个人得出相同的判断，才能说明这个判断有效。
在 Redis 里，每次部署哨兵集群时至少三台机器来部署，当某个哨兵判断节点主观下线后，就会向其它哨兵发起命令，其它哨兵根据自己的监控情况，给出赞同或者反对的投票。
图片
当多数节点（比如 3 个哨兵有 2 个都认可，quorum 可配置这个值）支持节点已下线，该节点会被标记为客观下线。
当判断主节点客户下线后，哨兵机制会进行故障转移操作，即选出一个从节点升级为主节点。
不难理解，如果掌门人挂了，则哨兵部门会重新选一个新的掌门，来接替门派事务。
首先，哨兵部门会先选一个领头哨兵（leader sentinel），来主持换掌门的仪式。
图片
领头哨兵的选举需要从领头候选人（leader candidate）里面选，而只有发现掌门客观下线的哨兵成员才可以成为候选人。
通过所有哨兵节点给候选人投票，至少得票数过半的候选人才能成为领头哨兵。
为了防止票数重叠（刷票行为），每个节点只可以投一票，并且当节点成为哨兵候选人时，会首先给自己投一票。
不难理解，毕竟换掌门仪式和下任新掌门息息相关，所以每个哨兵都想当这个 leader。
在 Redis 里面，参选领头哨兵的候选人不止需要拿到半数以上的票，还需要超过配置文件中的 quorum 值才可以成为 leader sentinel。
为了防止投票数一致的问题，哨兵个数和 Redis 的节点数一样，一般为单数个。
哨兵集群中选出一个 leader哨兵 之后，就开始进行主从故障转移。
在武当，老掌门挂了，谁来当这个新掌门呢？
为了公平起见，哨兵部门制定了一个策略，会从副掌门的向上管理能力、业务熟悉程度以及资历来考虑。
对应 Redis 里选主节点的三大策略：优先级、复制进度、节点 ID 号。
哨兵会根据从节点的优先级进行排序，优先级越小排名越靠前。
在门派中，这可能是看哪个副掌门的向上管理做得更好，和领导走得更近，毕竟，掌门在选接班人时也会有优先级的侧重。
如果节点的优先级不分上下，则查看数据复制的 slave_repl_offset 参数，这个参数指向了从节点复制数据的偏移量，偏移量越大（复制数据越多）的那个从节点胜出。
想了解更多的，可以看我上一篇文章：救命！只有我还不明白Redis主从复制的原理吗？
这就好比掌门不偏不倚，对待副掌门都一视同仁。这就得考量副掌门的业务熟悉能力了，谁在掌门那里学的本事越多，谁就来当这个新掌门。
当优先级和复制程度都相同时，就选择从节点 ID 较小的那个（说明排行越高）。
当副掌门的受重视程度和能力不相上下时，就得论资排辈了，看谁资历更高，排行更靠前（大师兄 > 二师兄 > 三师弟），谁就来当这个新掌门。
在哨兵机制的协助下，从节点晋升为主节点，这时机器节点的 IP 等信息都更换了，所以需要知会客户端和新的主节点进行通信，这是通过发布/订阅者机制实现的。
图片
每个门派可能有诸多事宜，但是客户端（外宾）不会关心所有的事件，它们只关心一些像掌门更换这种大事情。
在 Redis 里面，哨兵机制提供的订阅事件主要有如下三种：
如果客户端订阅了主节点更换的事件，就会收到哨兵的通知事件，进而调整自身连接的节点信息。
所谓一山不容二虎，哨兵部门在更换掌门后要做的职责是，继续监控老掌门的体征信息。
图片
一当老掌门有消息回复时，哨兵部门就会告诉它，现在已经有新掌门人了，老掌门失联这么久，对门派事务的了解难免落后，所以会让它先担任副掌门。
Redis 中，哨兵集群会向重新上线的旧主节点发送 SLAVEOF 命令，让它成为新主节点的从节点。
当哨兵集群同步这个事件以后，会接着发布从库更新配置事件的订阅消息，让客户端也知晓。
在大型的互联网应用上，Redis 为了保证高可用，会在主从复制的部署架构上进一步引入哨兵机制。
如果说主从同步是 Redis 高可用的数据保障基础，那哨兵机制就是 Redis 高可用的进阶支撑，有了它，就不用担心 Redis 挂了后得人工升级，并且还非常低效的问题了。
毕竟，乱世江湖，门派中一旦群龙无首，就很容易陷入危机，导致四分五裂！
接下来我们总结一下，哨兵机制的工作流程：
而 Redis 精准无误地执行上述流程，是通过发布订阅、投票算法等机制做到的，这让系统的高可用进一步得到了保障。
在派系林立的江湖也这样，哨兵部门如果能很好地处理掌门人之间的权力和事务关系，门派发展扩大亦是指日可待！
京公网安备 11010802035086号