redis集群哨兵（redis哨兵故障转移及实现）

本文目录

• redis哨兵故障转移及实现
• SpringBoot连接redis哨兵模式
• Redis哨兵（Sentinel）模式搭建
• 每天一个知识点：哨兵挂了，Redis 主从库还能切换吗
• Redis中的哨兵模式

redis哨兵故障转移及实现

sentinel 是一个特殊的 redis 节点，它有自己专属的 api ：

sentinel masters

展示所有被监控的主节点状态及相关信息：

sentinel master 《master name》

展示指定 《master name》 状态以及相关的信息：

sentinel slaves 《master name》

展示指定 《master name》 的从节点状态以及相关的统计信息：

sentinel sentinels 《master name》

展示指定 《master name》 的 sentinel 节点集合（不包含当前 sentinel 节点）：

sentinel get-master-addr-by-name 《master name》

获取主节点信息：

sentinel failover 《master name》

对 《master name》 进行强制故障转移：

修改配置：

Master 可能会因为某些情况宕机了，如果客户端是固定一个地址去访问，肯定是不合理的，所以客户端请求是请求哨兵，从哨兵获取主机地址的信息，或者是从机的信息。可以实现一个例子：

执行 docker-composer up 之后 sentinel.conf 发生了变化，每个配置文件变化如下：

sentinel\conf\sentinel.conf

sentine2\conf\sentinel.conf

sentine3\conf\sentinel.conf

从变化中可以看出每台 Sentinel 分别记录了 slave 的节点信息和其它 Sentinel 节点信息。

在宿主机中随便进入一台 Sentinel ：

可以观察到监听的所有 master ，将 192.168.3.2 这台 master 进行宕机

docker stop redis-master

宕机完之后等待 Sentinel 检测周期过了之后再对 sentinel.conf 和 redis.conf 进行观察。

3台 Sentinel 的 sentinel monitor mymaster 192.168.3.2 6379 2 变成了 sentinel monitor mymaster 192.168.3.4 6379 2

其次master对应的slave节点信息也进行更改。

而 192.168.3.3 的 redis.conf 中 replicaof 192.168.3.2 6379 也变成了 replicaof 192.168.3.4 6379 。

192.168.3.2 的 redis.conf 中 replicaof 192.168.3.2 6379 这行配置被删除掉了。

再次启动 192.168.3.2 的 redis 节点，而这台节点的 redis.conf 中增加了一行 replicaof 192.168.3.4 6379 。

其实就是将我们的操作自动化了。

Sentinel 的实现原理，主要分为三个步骤：

回顾上一篇文章中 Sentinel 的配置。

主观下线：每个 Sentinel 节点对 Redis 失败的“偏见”。之所以是偏见，只是因为某一台机器30s内没有得到回复。

客观下线：这个时候需要所以 Sentinel 节点都发现它30s内无回复，才会达到共识。

​ Redis 内部其实是有一个优先级配置的，在配置文件中 replica-priority ，这个参数是 slave 节点的优先级配置，如果存在则返回，如果不存在则继续。当上面这个优先级不满足的时候， Redis 还会选择复制偏移量最大的 Slave 节点，如果存在则返回，如果不存在则继续。之所以选择偏移量最大，这是因为偏移量越小，和 Master 的数据越不接近，现在 Master 挂掉了，说明这个偏移量小的机器数据可能存在问题，这就是为什么选择偏移量最大的 Slave 的原因。如果发现偏移量都一样，这个时候 Redis 会默认选择 runid 最小的节点。

生产环境部署技巧：

哨兵集群在发现 master node 挂掉后会进行故障转移，也就是启动其中一个 slave node 为 master node 。在这过程中，可能会导致数据丢失的情况。

造成的问题：

​ 此时哨兵可能就会认为 master 宕机了，然后开始选举，将其它 slave 切换成 master 。这时候集群里就会有2个 master ，也就是所谓的脑裂。此时虽然某个 slave 被切换成 master ，但是可能 client 还没来得及切换成新的 master ，还继续写向旧的 master 的数据可能就丢失了。因此旧 master 再次被恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会被清空，重新从新的 master 复制数据。

怎么解决：

要求至少有一个 slave ，数据复制和同步的延迟不能超过10s。

如果说一旦所有的 slave ，数据复制和同步的延迟都超过了10s，这个时候， master 就不会再接收任何请求了。

上面两个配置可以减少异步复制和脑裂导致的数据丢失。

异步复制导致的数据丢失：

​ 在异步复制的过程当中，通过 min-slaves-max-lag 这个配置，就可以确保的说，一旦 slave 复制数据和 ack 延迟时间太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样就可以把 master 宕机时由于部分数据未同步到 slave 导致的数据丢失降低到可控范围内。

集群脑裂导致的数据丢失：

​ 集群脑裂因为 client 还没来得及切换成新的 master ，还继续写向旧的master的数据可能就丢失了通过 min-slaves-to-write 确保必须是有多少个从节点连接，并且延迟时间小于 min-slaves-max-lag 多少秒。

客户端需要怎么做：

​ 对于 client 来讲，就需要做些处理，比如先将数据缓存到内存当中，然后过一段时间处理，或者连接失败，接收到错误切换新的 master 处理。

SpringBoot连接redis哨兵模式

设置 sentinel-26377.conf 的 protected-mode no ；默认是该字段值是yes

修改问题中为redis集群master节点的真实地址；
修改问题中为 bind 0.0.0.0

【注】redisTemplate实际上是对其他框架的的封装，springboot2.x以上底层实现由jedis变为了lettuce。而且lettuce会根据配置自动选择是否用单机或者哨兵模式。

【1】 Redis 哨兵模式 设置密码
【2】 sentinel搭建redis集群经验总结
***隐藏网址***
***隐藏网址***

Redis哨兵（Sentinel）模式搭建

Redis哨兵模式介绍，参考文档如下：
***隐藏网址***

2、...

master

slave

常用命令

windows

linux

每天一个知识点：哨兵挂了，Redis 主从库还能切换吗

直接抛结论，可能可以。实际上，一旦多个实例组成了哨兵集群，即使有哨兵实例出现故障挂掉了，其他哨兵还能继续协作完成主从库切换的工作，包括判定主库是不是处于下线状态，选择新主库，以及通知从库和客户端。那为什么是可能呢？这就要了解哨兵工作的基本原理了。

在配置哨兵的信息时，我们只需要设置主库的 IP 和端口，并没有配置其他哨兵的连接信息，因为哨兵不需要知道其他的哨兵信息。那么哨兵之间是如何互相发现的呢？这要归功于 Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。实际上，哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如说发布它自己的连接信息（IP 和端口）。同时，它也可以从主库上订阅消息，获得其他哨兵发布的连接信息。当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口。
除了哨兵实例，我们自己编写的应用程序也可以通过 Redis 进行消息的发布和订阅。所以，为了区分不同应用的消息，Redis 会以频道的形式，对这些消息进行分门别类的管理。所谓的频道，实际上就是消息的类别。当消息类别相同时，它们就属于同一个频道。反之，就属于不同的频道。只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。
哨兵除了彼此之间建立起连接形成集群外，还需要和从库建立连接。这是因为，在哨兵的监控任务中，它需要对主从库都进行心跳判断，而且在主从库切换完成后，它还需要通知从库，让它们和新主库进行同步。

这是由哨兵向主库发送 INFO 命令来完成的。哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。通过 pub/sub 机制，哨兵之间可以组成集群，同时，哨兵又通过 INFO 命令，获得了从库连接信息，也能和从库建立连接，并进行监控了。

从本质上说，哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。具体的操作步骤是，客户端读取哨兵的配置文件后，可以获得哨兵的地址和端口，和哨兵建立网络连接。然后，我们可以在客户端执行订阅命令，来获取不同的事件消息。

确定由哪个哨兵执行主从切换的过程，和主库“客观下线”的判断过程类似，也是一个“投票仲裁”的过程。

Redis中的哨兵模式

哨兵模式是一种自动选择老大的模式，即在老大宕机之后，哨兵模式会根据哨兵们的内部投票，自动的重新选出一个新的老大。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，如果Redis服务器一直没有响应，说明这个Redis服务器可能已经宕机了，从而监控运行的多个Redis实例。

这里的哨兵有两个作用
1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换(failover)的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。如果有三个哨兵，不仅每个哨兵会监视主机和从机，而且哨兵之间也会互相监视，如下图：

配置哨兵配置文件sentinel.conf，如下

当哨兵模式的配置文件配置好之后，就可以启动哨兵模式了，如下图

测试在哨兵模式下如果主机崩了的话会不会从从机中自动选出一个老大，先关闭主机，让主机宕机，如下图：

看看主机宕机之后，哨兵模式中输出日志的新的内容是什么，如下图：

哨兵模式自动选举一个主机这个过程是怎样实现自动化的？哨兵自动选举之前的某个从机为老大，所有的从机都会称新选出的从机为老大，以及原本的老大也会称新选出的老大为老大，这个过程是怎么自动化实现的呢？是通过在对应的redis服务器的配置文件中写内容来实现的，比方说，让我们看一下新老大也即是端口号是6381的redis服务器的配置文件中是怎样改写的，如下图：

再来看一下从机即端口号是6380的redis服务器对应的配置文件是怎样改写的，如下图：

最后看一下原本的主机即端口号是6379的redis服务器的配置文件是怎样改写的。我检查了一下，发现在重新启动原本的老大即重启已经宕机的端口号是6379的redis服务器之前，它对应的配置文件中没有发生任何改变，但是一旦重新启动原本的老大，它对应的配置文件就会发生变化，如下图：

哨兵模式中的主机关闭之后需要特别注意的一个易错点：就是因为现在老大已经换了，所以老大的认证密码也换了，因此需要在现任老大的所有从机里面配置主机的认证密码，这个哨兵模式是不会帮我们自动配置的，需要我们自动配置，如下图：

测试哨兵模式结果，如下图：

1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。

2、主从可以切换，故障可以转移，系统的可用性就会更好。

3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。

1、集群容量一旦到达上限，在线扩容十分麻烦。

2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择。

当Redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤：

Sentinel集群的每一个Sentinel节点会定时对Redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。

当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。

该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过quorum数量的Sentinel节点认为该Redis节点主观下线，则该redis客观下线。

如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。

如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。

如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。

当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：

详解redis集群选举机制