探索Redis：哨兵模式深度解析

Redis哨兵（Sentinel）模式是Redis的高可用性解决方案。通过使用哨兵，Redis可以实现故障转移（failover），以及系统的监控和通知。 接下来以STAR法则来解释下哨兵模式的技术要点。

Redis哨兵模式概览：STAR法则解读

Situation

在分布式系统中，特别是使用Redis作为数据存储或缓存解决方案的场景下，系统的高可用性变得至关重要。Redis本身提供了主从复制（master-slave replication）功能，以支持数据的备份和读写分离，但是在主节点故障的情况下，需要手动将一个从节点晋升为新的主节点，并重新配置系统，这对于需要24/7运行的系统来说是不可接受的。

Task

为了解决上述问题，需要一个自动化的故障转移机制，确保当主节点出现故障时，系统能够自动将一个从节点晋升为新的主节点，并且自动更新其他从节点的配置，以指向新的主节点。此外，还需要能够对系统进行实时监控和配置管理。

Action

以下5个Action恰好就是解决问题的5个步骤:

1. 准备阶段：部署哨兵节点 部署多个哨兵节点来监控Redis的主从服务器。这些哨兵节点会定期发送PING请求给Redis节点，以检查其健康状态。

2. 发现问题：状态监控 哨兵节点监控Redis主从节点的运行状态，包括是否在线、延迟情况等。

3. 告警：出现问题通知到相关人 当哨兵节点检测到主节点不可用时，会通过配置的通知方式（例如邮件、短信等）通知系统管理员或自动执行故障转移程序。

4. 解决问题：自动故障转移 哨兵节点之间会协商选出一个领导者（leader），这个领导者负责执行故障转移操作，包括选择一个最合适的从节点晋升为新的主节点，并指示其他从节点修改其复制配置，以指向新的主节点。

5. 结果：更新配置，通知最新信息 在故障转移过程中，哨兵还负责更新自己的配置，以及通知客户端关于新主节点的信息。

Result

通过部署Redis哨兵模式，系统实现了高可用：

• 自动故障转移：当主节点失败时，系统能够自动且迅速地将从节点晋升为新的主节点，最小化了系统的不可用时间。

• 实时监控和通知：系统管理员可以实时了解Redis集群的状态，并在出现问题时获得通知，有助于快速响应和处理问题。

• 系统稳定性和可靠性提升：通过哨兵模式，Redis的使用变得更加稳定和可靠，支持了业务的连续性需求。

简言之，Redis哨兵模式通过提供自动故障转移和系统监控能力，极大地提高了Redis部署的可用性和稳定性，是构建高可用Redis解决方案的关键组成部分。

Redis哨兵模式技术细节：Action深入分析

1. 准备阶段：部署哨兵节点

部署Redis哨兵节点是确保Redis数据持续可用性和高可靠性的首要步骤。 既然要部署哨兵节点，那伴随而来会有以下几个问题：

• 部署几个节点
• 节点之间的关系
• 多个哨兵直接怎么发现
• 新增节点其他哨兵怎么知道
• 减少节点其他哨兵怎么知道
• 哨兵直接的共识

部署几个节点

部署的哨兵节点数量取决于系统的可用性要求和网络分区容忍度。一般建议至少部署三个哨兵节点，以保证在任何时候都有足够的哨兵节点参与故障转移的决策过程。部署三个或以上的哨兵节点可以在一个哨兵节点失效或网络分区情况下维持系统的高可用性和一致性。

节点之间的关系

哨兵节点之间是平等的，不存在主从或层级关系。每个哨兵节点都独立运行，它们通过发布订阅模式互相通信，共享关于Redis主从节点状态的信息。

多个哨兵直接怎么发现

哨兵节点之间通过Redis的发布订阅功能实现相互发现。一个哨兵节点会在一个特定的频道上发布自己的存在，其他哨兵节点订阅这个频道，从而实现哨兵节点之间的自动发现。

多哨兵模式-彼此发现

新增节点其他哨兵怎么知道

当新增一个哨兵节点时，它会通过发布自己的信息到共享的频道中，其他已存在的哨兵节点通过订阅这个频道，能够接收到新节点的信息，从而实现对新哨兵节点的自动识别和接纳。

减少节点其他哨兵怎么知道

如果一个哨兵节点停止工作或从集群中移除，它将停止在频道上发布自己的信息。其他哨兵节点会定期检查哨兵列表，如果在一定时间内没有接收到某个哨兵的消息，就会将其从自己维护的哨兵列表中移除。这个过程是通过哨兵节点之间的心跳检测机制实现的。

哨兵之间的共识

哨兵节点之间通过一种称为Raft协议的变种来达成共识。当主节点出现故障需要进行故障转移时，哨兵节点之间会进行一次投票，选举出一个领导者（leader）哨兵来负责这次故障转移操作。这保证了在进行关键操作时，哨兵集群内部的一致性和决策的权威性。

多哨兵模式－下线共识

通过这样的设计，Redis哨兵系统能够在不影响Redis服务的前提下，动态地进行哨兵节点的增减和自我管理，从而确保Redis系统的高可用性和稳定性。

2. 发现问题：状态监控

Redis Sentinel的状态监控机制是其高可用性架构的关键组成部分。通过定期监控Redis节点的状态，Sentinel能够及时发现并响应各种异常情况。 仍然通过问题来理解：

• 监控什么
• 怎么监控
• 怎么判定节点异常

监控什么

• 节点的在线状态：监控所有Redis节点（包括主节点和从节点）是否在线，以及它们是否能够正常响应请求。
• 节点的响应时间：监控节点对于监控命令（如PING）的响应时间，以此作为节点健康状态的一个重要指标。
• 节点的角色变化：监控Redis节点的角色（主节点或从节点）是否发生变化，这对于维护数据一致性和故障转移至关重要。
• 从节点的复制状态：监控从节点与其对应主节点之间的复制状态，确保数据的一致性和完整性。

怎么监控

• 心跳检测：Sentinel通过定期发送PING命令给Redis节点来检测它们是否在线。如果一个节点在预定的超时时间内没有回应，Sentinel会认为这个节点是不可达的。
• 订阅与发布（Pub/Sub）：Sentinel订阅Redis节点的__sentinel__:hello频道，通过这种方式获取关于节点状态和配置的更新信息。
• 命令统计与分析：Sentinel使用Redis的INFO命令获取节点的详细状态信息，包括角色信息、网络延迟、复制状态等。
• 角色检查：通过定期检查Redis节点的角色信息，Sentinel能够监控到主从切换或角色变化事件。

怎么判定节点异常

• 响应超时：如果一个Redis节点在预定的超时时间内没有回应PING命令，Sentinel会将其标记为s_down（主观下线）。
• 多个Sentinel共识：如果多个Sentinel实例都报告了同一个节点的主观下线状态，该节点会被标记为o_down（客观下线）。这意味着系统认为该节点确实发生了故障。
• 复制健康检查：对于从节点，如果发现其与主节点的复制连接断开或复制延迟过大，Sentinel也会认为这个从节点异常。
• 角色不一致：如果一个节点的实际角色与Sentinel的配置信息不一致（例如，一个被标记为从节点的实例却自称是主节点），Sentinel会进一步检查该节点的状态。

通过上述机制，Redis Sentinel能够有效地监控和维护Redis集群的健康状态，及时发现并处理各种异常情况，保障Redis服务的高可用性。

3. 告警：出现问题通知到相关人

当哨兵节点检测到主节点不可用时，可以通过配置的通知方式（例如邮件、短信等）通知到相关人或自动执行故障转移程序。实际工作中没遇到使用Sentinel自带方式通知的。 参考：sentinel.conf

配置Sentinel通知脚本：Redis Sentinel允许为不同的事件配置通知脚本。这些脚本在特定事件发生时被执行，可以用来发送邮件、短信或者触发其他类型的通知。需要在Sentinel的配置文件中指定这些脚本。

sentinel notification-script mymaster /path/to/notification-script.sh

编写通知脚本：可编写一个shell脚本或者更复杂的程序通来发送通知，通过API发送短信或者集成到其他系统中

#!/bin/bash
SUBJECT="Redis Sentinel Alert: $2"
TO="admin@example.com"
MESSAGE="Redis Sentinel $1: $2"
echo "$MESSAGE" | mail -s "$SUBJECT" $TO

4. 解决问题：自动故障转移

哨兵节点之间会协商选出一个领导者（leader），这个领导者负责执行故障转移操作，包括选择一个最合适的从节点晋升为新的主节点，并指示其他从节点修改其复制配置，以指向新的主节点。 继续提出问题：

• 选哪个哨兵当领导
• 提升哪个从节点为主节点
• 怎么指挥其他从节点复制配置
• 什么时候算故障转移完成

选哪个哨兵当领导

哨兵节点之间采用一种分布式一致性算法（通常基于 Raft 协议）来选举领导者。这个过程通常遵循以下步骤：

1. 发起选举：当一个或多个 Sentinel 节点判断主节点下线（即无法访问）时，它们会发起领导者选举。
2. 请求投票：每个参与选举的 Sentinel 向其他 Sentinel 请求投票。
3. 投票和选举：每个 Sentinel 只能为一个候选者投票一次。它们基于当前的视图（了解到的信息）和候选者的优先级来决定投票给谁。通常，最先请求投票的 Sentinel 有较高的获胜几率，除非有其他 Sentinel 由于网络分区等原因未能参与早期的投票过程。
4. 达到多数：一旦某个 Sentinel 获得了超过半数的投票，它就被选为领导者。

多哨兵模式－竞选leader

提升哪个从节点为主节点

选出领导者之后，接下来就是选择一个从节点晋升为新的主节点。这个决策基于以下几个标准：

• 数据的更新程度：优先选择数据最完整（即复制偏移量最大）的从节点。
• 网络延迟和稳定性：考虑从节点的响应时间和网络稳定性，选择一个响应快且稳定的从节点。
• 从节点的优先级：可以为从节点设置优先级，优先级高的从节点会被优先考虑。
• 运行时间：运行时间较长，表明稳定性较好的从节点也会被优先考虑。

怎么指挥其他从节点复制配置

一旦新的主节点被选定，领导者 Sentinel 会负责通知其他从节点进行以下操作：

1. 更新复制配置：领导者 Sentinel 向其他从节点发送命令，指示它们将复制配置更新为新的主节点地址。
2. 开始同步过程：从节点接收到命令后，会立即开始与新的主节点进行数据同步，确保数据的一致性。

什么时候算故障转移完成

• 从节点全部更新：所有从节点都成功修改了复制配置，并开始从新的主节点同步数据。
• 服务恢复：新的主节点能够接受写请求，并且系统对外提供的服务已经恢复正常。
• 稳定性验证：系统运行一段时间后，没有出现新的问题，性能稳定，可以认为故障转移正式完成。

单哨兵模式－故障发现和转移

5. 结果：更新配置，通知最新信息

更新哨兵配置

• 自动保存：当故障转移完成后，哨兵会自动更新其内部配置，这包括新的主节点信息和任何关于从节点的变更。这确保了哨兵对当前集群状态的认识始终是最新的。
• 持久化变更：哨兵节点将这些变更持久化到磁盘上的配置文件中，这样即使在哨兵重启后也能保持对集群最新状态的跟踪。

通知客户端

• 发布/订阅机制：哨兵利用 Redis 的发布/订阅功能，向订阅了相关通道的客户端广播新主节点的信息。客户端通过监听这些通道可以实时获得故障转移事件和新主节点的地址。
• 配置更新API：部分客户端库支持通过 API 自动更新其内部的 Redis 服务器配置。这意味着在故障转移发生后，客户端可以无需人工干预即可重新定位到新的主节点。