Redis Sentinel：高可用性解决方案详解

Redis Sentinel：高可用性解决方案详解

引用

CSDN

1.

https://blog.csdn.net/GRrtx/article/details/145502324

Redis Sentinel是Redis的高可用性解决方案，它通过监控Redis节点状态、自动故障转移和通知应用方，实现了真正的高可用性。本文将详细介绍Sentinel的工作原理、选举机制以及其在主节点故障时的自动恢复过程。

1. 哨兵Sentinel概念

由于对Redis的许多概念都有不同的名词解释，所以在介绍Redis Sentinel之前，先对几个名词概念进行必要的说明，如下表所示。

Redis Sentinel相关名词解释：

Redis Sentinel是Redis的高可用实现方案，在实际的生产环境中，对提高整个系统的高可用是非常有帮助的。

1.1 主从复制的缺点

Redis的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：

• 第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶”上来，并且保证数据尽量不丢失（主从复制表现为最终一致性）。
• 第二，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。

但是主从复制模式并不是万能的，它同样遗留下以下几个问题：

• 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。
• 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。

其中第一个问题是高可用问题，即Redis哨兵主要解决的问题。第二个问题是属于存储分布式的问题，留给Redis集群去解决。

1.2 人工恢复主节点故障

Redis主从复制模式下，主节点故障后需要进行的人工工作是比较繁琐的，在图中大致展示了整体过程。

实际开发过程中，对于服务器后端开发，监控程序是非常重要的。服务器要求要有比较高的可用性，而服务器长期运行总会出现一些“意外”，但也没法全靠人工来盯着这些服务器运行。所以，此时就可以写一个程序，用程序来盯着服务器的运行状态（监控程序，往往还需要搭配“报警程序”来发现服务器的运行出现状态异常）。

步骤解释：

1. 运维人员通过监控系统，发现Redis主节点故障宕机。
2. 运维人员从所有节点中，选择一个（此处选择了slave 1）执行slaveof no one，使其作为新的主节点。
3. 运维人员让剩余从节点（此处为slave 2）执行slaveof {newMasterIp} {newMasterPort}，连上新的主节点，从新的主节点开始数据同步。
4. 告知客户端（修改客户的的配置），让客户端能够连接新的主节点，用来完成修改数据的操作，需要更新应用方连接的主节点信息到{newMasterIp} {newMasterPort}。
5. 如果原来挂了的主节点恢复，执行slaveof {newMasterIp} {newMasterPort}，让其成为一个从节点，挂到这组机器中。

上述过程可以看到基本需要人工介入，无法被认为架构是高可用的，而这就是Redis Sentinel所要做的。

1.3 哨兵自动恢复主节点故障

当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线表示。如果下线的是主节点，它还会和其他的Sentinel节点进行“协商”，当大多数Sentinel节点对主节点不可达这个结论达成共识之后，它们会在内部“选举”出一个领导节点来完成自动故障转移的工作，同时将这个变化实时通知给Redis应用方。整个过程是完全自动的，不需要人工介入。整体的架构如下图所示。

这里的分布式架构是指：Redis数据节点、Sentinel节点集合、客户端分布在多个物理节点上，不要与后面将要学习的Redis Cluster集群分布式混淆。

Redis Sentinel相比于主从复制模式是多了若干单独的（建议保持奇数，最少应该是3个）Sentinel节点用于实现监控数据节点，哨兵节点会定期监控（这些进程之间会建立tcp长连接，通过这样的长连接定期发送心跳包）所有节点（包含数据节点和其他哨兵节点）。

针对主节点故障的情况，故障转移流程大致如下：

1. 主节点故障，从节点同步连接中断，主从复制停止。
2. 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商，达成多数认同主节点故障的共识。这步主要是防止该情况：出故障的不是主节点，而是发现故障的哨兵节点，该情况经常发生于哨兵节点的网络被孤立的场景下。
3. 哨兵节点之间使用Raft算法选举出一个leader（领导角色），由该节点负责后续的故障转移工作。
4. 哨兵领导者开始执行故障转移：leader从节点中选择一个作为新的主节点，挑选出新的主节点之后，哨兵节点就会自动控制这个被选中的节点，执行slaveof no one，并且控制其他从节点，修改slaveof到新的主节点上，哨兵节点会自动通知客户端程序，告知新的主节点是谁，并且后续客户端再进行写操作，就会针对新的节点进行操作。

通过上面的介绍，可以看出Redis Sentinel具有以下几个功能：

• 监控：Sentinel节点会定期检测Redis数据节点、其余哨兵节点是否可达。
• 故障转移：实现从节点晋升（promotion）为主节点并维护后续正确的主从关系。
• 通知：Sentinel节点会将故障转移的结果通知给应用方。

注意：只有一个Redis哨兵节点也是可以的。但是万一这个哨兵节点挂了，后续Redis节点也挂了的话，就无法进行自动回复的过程了。而且出现误判的概率也比较高，毕竟网络传输数据容易出现抖动、延迟或者丢包等情况，只有一个哨兵节点出现上述情况影响较大。

基本原则：在分布式系统中，应该避免使用“单点”。

2. 重新选举master过程

哨兵存在的意义：能够在Redis主从结构出现问题（比如主节点挂了）时，哨兵节点自动帮我们重新选出一个主节点来代替之前挂了的节点，保证整个Redis仍然是可用状态。

当主节点挂了之后，哨兵节点就开始工作了，哨兵发现了主节点sdown，进一步的由于主节点宕机得票达到3/2，达到法定得票，于是master被判定为odown。

• 主观下线（Subjectively Down，SDown）：哨兵感知到主节点没心跳了，判定为主观下线。
• 客观下线（Objectively Down，ODown）：多个哨兵达成一致意见，才能认为master确实下线了。

接下来，哨兵们挑选出了一个新的master。此时，对于Redis来说仍然是可以正常使用的。

• Redis主节点如果宕机，哨兵会把其中的一个从节点，提拔成主节点。
• 当之前的Redis主节点重启之后，这个主节点被加入到哨兵的监控中，但是只会被作为从节点使用。

3. 选举master原理

假定当前环境为：三个哨兵（sentenal1、sentenal2、sentenal3），一个主节点（redis-master），两个从节点（redis-slave1、redis-slave2）。

当主节点出现故障，就会触发重新一系列过程。

3.1 主观下线

哨兵节点通过心跳包来判断Redis服务器是否正常工作。当redis-master宕机，此时redis-master和三个哨兵之间的心跳包就没有了。此时，站在三个哨兵的角度来看，redis-master出现严重故障。此时还不能排除网络波动的影响，因此三个哨兵均会把redis-master判定为主观这个Redis节点下线（SDown）。

3.2 客观下线

此时，哨兵sentenal1、sentenal2、sentenal3均会对主节点故障这件事情进行投票。当故障得票数>=配置的法定票数之后，此时意味着redis-master故障这个事情被做实了，此时触发客观下线（ODown）。

是否可能出现非常严重的网络波动，而导致所有的哨兵都联系不上Redis主节点，而被误判为挂了呢？

是有这个可能的。如果出现这个情况，怕是用户的客户端也连不上Redis主节点了，此时这个主节点基本也就无法正常工作了。

“挂了”不一定是进程崩了，只要是无法访问，都可以被视为是挂了。

3.3 选举出哨兵的leader

接下来需要哨兵把剩余的slave中挑选出一个新的master，这个工作不需要所有的哨兵都参与，只需要选出个代表（称为leader），由leader负责进行slave升级到master的提拔过程。这个选举的过程涉及到Raft算法。

Raft算法是一种为分布式系统设计的共识算法，旨在简化共识过程的理解与实现。其核心目标是在多个节点间高效达成一致，确保系统在节点故障时仍能可靠运行。

假定一共三个哨兵节点：S1、S2、S3

1. 每个哨兵节点都给其他所有哨兵节点，发起一个“拉票请求”（S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3，S3 -> S1，S3 -> S2）。
2. 收到拉票请求的节点，会回复一个“投票响应”。响应的结果有两种可能，投/不投。比如S1给S2发了个投票请求, S2就会给S1返回投票响应。到底S2是否要投S1呢？取决于S2是否给别⼈投过票了（每个哨兵只有一票）。如果S2没有给别⼈投过票，换而言之，S1是第一个向S2拉票的，那么S2就会投S1，否则则不投。
3. 一轮投票完成之后, 发现得票超过半数的节点，自动成为leader。如果出现平票的情况（S1投S2，S2投S3，S3投S1，每人一票），就重新再投一次即可。这也是为啥建议哨兵节点设置成奇数个的原因。如果是偶数个，则增大了平票的概率，带来不必要的开销。
4. leader节点负责挑选一个slave成为新的master，当其他的sentenal发现新的master出现了，就说明选举结束了。

简而言之，Raft算法的核心就是“先下手为强”。谁率先发出了拉票请求，谁就有更大的概率成为leader。这里的决定因素成了“网络延时”。网络延时本身就带有一定随机性。

具体选出的哪个节点是leader，这个并不重要，重要的是能选出一个节点即可。

3.4 leader挑选出master

leader挑选出合适的slave成为新的master，挑选规则：

挑选规则：

1. 比较优先级。优先级高（数值小的）的上位，优先级是配置文件中的配置项（slave-priority或者replica-priority）。
2. 比较replication offset谁复制的数据多，高的上位。
3. 比较run id，谁的id小，谁上位。

当某个slave节点被指定为master之后，

1. leader指定该节点执行slave no one，成为master。
2. leader指定剩余的slave节点，都依附于这个新master。

选举小结：

上述过程都是“无人值守”，Redis自动完成的。这样做就解决了主节点宕机之后需要人工干预的问题，提高了系统的稳定性和可用性。

注意事项：

• 哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性。
• 哨兵节点最好是奇数个，方便选举leader，得票更容易超过半数。
• 哨兵节点不负责存储数据，仍然是redis主从节点负责存储。
• 哨兵+主从复制解决的问题是“提高可用性”，不能解决“数据极端情况下写丢失”的问题。
• 哨兵+主从复制不能提高数据的存储容量。当我们需要存的数据接近或者超过机器的物理内存，这样的结构就难以胜任了。

为了能存储更多的数据，就引入了集群，后面将会详细介绍。