上一篇文章Redis主从复制原理中简要地说明了主从复制的一个基本原理,包含全量复制、复制积压缓冲区与增量复制等内容,有兴趣的同学可以先看下。
利用主从复制,可以实现读写分离、数据备份等功能。但如果主库宕机后,需要运维人员手动地将一个从库提升为新主库,并将其他从库slaveof新主库,以此来实现故障恢复。
因此, 主从模式的一个缺点,就在于无法实现自动化地故障恢复 。Redis后来引入了哨兵机制,哨兵机制大大提升了系统的高可用性。
哨兵,就是站岗放哨的,时刻监控周围的一举一动,在第一时间发现敌情并发出及时的警报。
Redis中的哨兵(Sentinel), 则是一个特殊的Redis实例 ,不过它并不存储数据。也就是说,哨兵在启动时,不会去加载RDB文件。
关于Redis的持久化,可以参考我的另外一篇文章 谈谈Redis的持久化——AOF日志与RDB快照
上图就是一个典型的哨兵架构,由数据节点与哨兵节点构成,通常会部署多个哨兵节点。
哨兵主要具有三个作用, 监控、选主与通知 。
监控:哨兵会利用心跳机制,周期性不断地检测主库与从库的存活性
选主:哨兵检测到主库宕机后,选择一个从库将之切换为新主库
通知:哨兵会将新主库的地址通知到所有从库,使得所有从库与旧主库slaveof新主库,也会将新主库的地址通知到客户端上
我会在下文详细讲一下监控与选主的过程
哨兵系统是通过3个定时任务,来完成对主库、从库与哨兵之间的探活。
首先我们会在配置文件中配置主库地址,这样哨兵在启动后,会以 每隔10秒 的频率向主库发送info命令,从而获得当前的主从拓扑关系,这样就拿到了所有从库的地址。
在此基础上,哨兵会 每隔1秒 向主库、从库与其他哨兵节点发送PING命令,因此来进行互相探活。
当某个哨兵在 down-after-milliseconds(默认是30秒) 配置的连续时间内,仍然没有收到主库的正确响应,则当前哨兵会认为主库 主观下线 ,并将其标记为sdown(subjective down)
为了避免当前哨兵对主库的误判,因此这个时候还需要参考其他哨兵的意见。
接着当前哨兵会向其他哨兵发送 sentinel is-master-down-by-addr 命令, 如果有半数以上(由quorum参数决定)的哨兵认为主库确实处于主观下线状态,则当前哨兵认为主库客观下线 ,标记为odown(objective down)
一旦某个主库被认定为客观下线时,这个时候需要进行哨兵选举,选举出一个领导者哨兵,来完成主从切换的过程。
哨兵A在向其他哨兵发送 sentinel is-master-down-by-addr 命令时,同时要求其他哨兵同意将其设置为Leader,也就是想获得其他哨兵的投票。
在每一轮选举中,每个哨兵仅有一票。投票遵循先来先到的原则,如果某个哨兵没有投给别人,就会投给哨兵A。
首先获得半数以上投票的哨兵,将被选举称为Leader。
这里的哨兵选举,采用的是Raft算法。这里不对Raft做详细的探讨,有兴趣的同学,可以参考我的另外一篇文章 22张图,带你入门分布式一致性算法Raft
该文章采用大量的图例,相信你可以从中学习到全新的知识,从而打开分布式一致性算法的大门,大伙们记得等我搞完Paxos与Zab。
过半投票机制也常用于很多算法中,例如RedLock,在半数以上的节点上加锁成功,才代表申请到了分布式锁,具体可参考这篇文章的最后 我用了上万字,走了一遍Redis实现分布式锁的坎坷之路,从单机到主从再到多实例,原来会发生这么多的问题
在Zookeeper选举中,同样也用到了过半投票机制,在这篇文章中 面试官:能给我画个Zookeeper选举的图吗? 我从源码角度分析了Zookeeper选举的过程。
在选举到领导者哨兵后,将由该哨兵完成故障恢复工作。
故障恢复分为以下两步:
详细说一下第一步,挑选是有条件的。首先要过滤出不 健康 的节点,再按某种规则排序,最后取第一个从库,我们直接从源码入手:
因此,以下从库会被过滤出:
剩下的节点,就是 健康 的节点,此时再执行一次快速排序,排序的规则如下:
本文算是Redis哨兵的一个入门文章,主要讲了哨兵的作用,例如监控、选主和通知。
在Redis读写分离的情况下,使用哨兵可以很轻松地做到故障恢复,提升了整体的可用性。
但哨兵无法解决Redis单机写的瓶颈,这就需要引入集群模式,相应的文章也被列为明年的写作计划中。