导读 redis的哨兵模式,就是用于在一主多从的集群环境下,如果主服务器宕机了,它会自动的将从服务器中的一台设为新的master,并且将其余的slave的配置文件自动修改,这样就切换出一套新的主从服务,不需要人工干预,且不会影响服务的使用。

背景

在生产环境中,为了保证redis服务的高可用,通常都会搭建主从。我们知道主从的原理是从服务器获取rdb文件的全量复制+写操作的增量复制来共同保证数据的一致性,所以在配置从服务器的时候,一个很重要的配置项就是标明主服务器的ip和端口号,总得知道哪一台服务器是我的主子不是,像下图中的replicaof配置。

通俗易懂讲解redis的哨兵模式

对于图中的部署方案,如果主服务器宕机了,我们只能进行手动干预,选择一台从服务器重新作为主服务器,然后将另外的两台从服务器的配置文件修改一下,将replicaof的配置重新改成新的主服务器地址。人工干预费时费力不说,更重要的是,这样会造成一段时间内服务是不可用的。在这种场景下,哨兵模式应运而生了。

什么是哨兵模式Sentinel

redis的哨兵模式,就是用于在一主多从的集群环境下,如果主服务器宕机了,它会自动的将从服务器中的一台设为新的master,并且将其余的slave的配置文件自动修改,这样就切换出一套新的主从服务,不需要人工干预,且不会影响服务的使用。

那么它具体是怎么工作的呢?首先看下面这张图:

通俗易懂讲解redis的哨兵模式

哨兵模式结构图

首先哨兵是一个独立于主从服务之外的服务,它也是一个集群服务。哨兵实例会不断给主服务器发送Ping,主服务器在收到后,返回一个有效回复,这样哨兵实例认为服务器是正常的。

主观下线

假设主服务器宕机,哨兵1在指定时间内(可配置)没有收到主服务器的有效回复,那么这个哨兵会把服务器标记为下线,叫做主观下线SDOWN。

注意此时只有一个哨兵标记为下线,实际上哨兵没有收到回复原因可能有很多,可能是服务器确实挂了,也有可能是服务器并没有挂,由于网络原因没有收到回复,总之,一个哨兵没有收到回复并不能证明主服务器宕机。

客观下线

哨兵2也发送了Ping命令,同样也没有收到回复,哨兵2也会将主服务器标记为SDOWN。这个时候,3个哨兵中有2个哨兵上报了SDOWN,哨兵们在彼此交流之后,认为已经有足够数量的实例证明该服务已经不可用,因此,哨兵实例会将该服务器标记为客观下线ODOWN。

这里的足够数量是可配置的,一般是哨兵个数的一半加1,比如3个哨兵则就设置为2。

投票选举,故障转移

当哨兵实例将服务标记为客观下线时,会进行一次选举。在剩下的从服务器实例中,选出一个作为主节点,并同时修改其余从服务器的配置文件,将新的主节点作为数据同步的来源,然后重新启动服务,完成切换。

至此,一个完整的哨兵自动进行故障转移的过程就完成了。

springboot配置一主多从+哨兵

如果我们的环境由主从换成了主从+哨兵,修改配置也比较简单,先注释掉原来的host和port的配置,替换成哨兵的配置,如下图:

通俗易懂讲解redis的哨兵模式

需要注意的是,这里nodes里配置的是哨兵集群的IP+端口,而不是主从节点,一定不要配错了。

原文来自:

本文地址://lrxjmw.cn/sentinel-mode-of-redis.html编辑:J+1,审核员:逄增宝

Linux命令大全:

Linux系统大全:

红帽认证RHCE考试心得: