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