我们之前文章说的Redis的主从架构模式实现了读写分离,支持了高并发的业务场景。主从模式也由单台Redis服务器变成了多台Redis服务器,服务器数量一多,当某服务器发生故障宕机的时候,可能就会影响到其它正在工作的服务器,然后产生连锁反应,进而使得整个系统崩溃。对于这种情况我们需要拿出一个方案,使得在某一台或者多台服务器宕机时,要保证不会影响到其它正常工作的服务器,继续维持整个系统正常运转。而Redis的哨兵模式就提供了高可用的解决方案!
哨兵模式,是由一个或者多个哨兵实例组成的哨兵系统,这个系统可以监视多个主服务器和从服务器,并在被监视的主服务器进入下线状态时,自动将某个从服务器升级为新的主服务器,然后由新的主服务器替代原来下线的主服务器继续工作。
作用就是监视所有的主从服务器,感知到了某些故障然后去处理
比如当主服务器下线了,sentinel就会从主服务器的那些从服务器中选一个出来当作新的主服务器,然后发出命令让其他从服务器去复制这个新的主服务器,当原来的主服务器再次上线后,然后作为新主服务器的从服务器。这就完成了这次故障处理。
Sentinel本质上也是一个redis服务器,但由于与普通服务器的功能不同,它们之间又有很多的不同处,比如命令表的不同,还有普通服务器启动后会加载持久化文件,sentinel就不会。它的主要任务不是存储数据而是监视其它Redis服务器是否还在正常工作,以及发生故障时给出解决方案,保证其它服务器能够继续工作。
Sentinel用一个masters字典记录着自己监视的服务器,这个服务器可以是主或者从或者其他的sentinel。Sentinel启动后,会先根据配置文件去初始化监视的服务器结构,即masters字典。
初始化的最后一步,是建立两个异步网络连接:
命令连接:用于向 Redis master 数据节点发送命令,例如通过 INFO 命令了解:
订阅连接:订阅 sentinel:hello 频道,用于发现其他 Sentinel,频道中信息包括:
Sentinel 之间:自动发现机制
Sentinel 利用 pub/sub(发布/订阅)机制,订阅了每个 master 和 slave 数据节点的
sentinel:hello 频道,去自动发现其它也监控了统一 master 的 sentinel 节点
Sentinel 向每 1s 向 sentinel:hello 中发送一条消息,包含了其当前维护的最新的 master
配置。如果某个sentinel发现自己的配置版本低于接收到的配置版本,则会用新的配置更新自己的 master 配置
与发现的 Sentinel 之间相互建立命令连接,之后会通过这个命令连接来交换对于 master 数据节点的看法
监控
定时监控 Redis 数据节点
1、每 10 秒每个 sentinel 向 master、slaves 节点发送 INFO 命令
2、每 2秒每个 sentinel 通过 master 节点的 channel(名称为 sentinel:hello)交换信息(pub/sub),信息包括:
3、每 1 秒每个 sentinel 对其他 sentinel 和 redis master,slave 发送 PING 命令,用于心跳检测,作为节点存活的判断依据
主观下线和客观下线(发现故障)
1、主观下线(subjectively down,SDOWN):当前 Sentinel 实例认为某个 redis服务为”不可用”状态。Sentinel 向 redis master 数据节点发送消息后30s(down-after-milliseconds) 内没有收到有效回复(+PONG、-LOADING 或者-MASTERDOWN),Sentinel 会将 master 标记为下线(打开 master 结构中 flags 的 SRI_S_DOWN 标记)
2、客观下线(objectively down,ODOWN):多个 Sentinel 实例都认为 master 处于 SDOWN 状态,那么此时 master 将处于 ODOWN, ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制。向其他 sentinel 节点发送
sentinel is-master-down-by-addr 消息询问数据节点情况,得知达到 quorum 数量的 sentinel节点认为数据节点已经下线 作者:云课堂技术栈 https://www.bilibili.com/read/cv7425521/ 出处:bilibili