Redis 哨兵

简介

Redis的哨兵（Sentinel）机制是一种用于高可用性的分布式系统架构。它允许在Redis主节点发生故障时自动进行故障转移，并选举新的主节点，以确保系统的连续性。

原理

Redis的哨兵采用了基于领导者选举的选举模式。在哨兵架构中，多个哨兵节点通过相互通信来达成共识，并选举出一个领导者来执行故障转移操作。

该选举模式可以被认为是一种分布式一致性算法，类似于Raft或Paxos。哨兵节点之间通过协商、投票和选举的方式来达成一致，确保选举出的领导者是唯一且一致的。选举过程中，哨兵节点会比较各个候选节点的健康状态、复制偏移量、优先级等因素，并选择一个最适合成为新主节点的候选者。

这种选举模式确保了哨兵节点之间的高可用性和容错性。即使在部分哨兵节点失效的情况下，剩余的哨兵节点仍然可以通过协调和选举来维持系统的正常运行。选举模式的使用还能够确保在主节点故障时能够快速选举出新的主节点，以实现故障转移并保持系统的连续性。

总的来说，哨兵采用基于领导者选举的选举模式，使得Redis能够实现自动故障转移和高可用性，保证分布式系统的稳定性和可靠性。

工作流程

1. 哨兵节点：哨兵是一种特殊的Redis实例，它负责监控并管理Redis主节点和从节点的状态。哨兵节点通过周期性地向主节点和从节点发送心跳检测来监控它们的健康状态。
2. 监控主节点：每个哨兵节点都会监控一个或多个Redis主节点。它们通过发送PING命令检测主节点是否正常运行，并检查主节点的回复是否超时。如果一个哨兵节点检测到主节点不可达，它会将该节点标记为主观下线（Subjectively Down）。
3. 选举新的主节点：当一个哨兵节点将主节点标记为主观下线后，它会与其他哨兵节点进行协调，通过投票选举出一个新的主节点。这个过程称为领导者选举（Leader Election）。哨兵使用Raft算法的一部分来确保选举的一致性。
4. 选举决策：哨兵节点在进行领导者选举时，会通过投票来选择一个新的主节点。选举的条件包括：候选主节点的健康状态、复制偏移量（Replication Offset）以及优先级（Priority）等。哨兵节点会比较这些条件，并选出一个最适合成为新主节点的候选者。
5. 故障转移：一旦新的主节点被选举出来，哨兵节点会将其他从节点切换为新的主节点的从节点，并更新客户端的配置，使其连接到新的主节点。这个过程称为故障转移（Failover）。故障转移是通过发送命令来实现的，哨兵节点会通知客户端进行重新连接。
6. 监控从节点：哨兵节点会继续监控从节点的状态，并在需要时进行故障转移。如果从节点发生故障，哨兵节点可以重新配置其他从节点作为新的从节点，以保持系统的高可用性。

Demo

当Redis主节点发生主动下线或被动下线时，哨兵节点会进行选举过程来选择新的主节点。下面是一次主动下线和被动下线的选举过程的模拟示例：

假设有三个哨兵节点（S1、S2、S3）和三个Redis实例（R1、R2、R3），其中R1为当前主节点。

1. 主动下线：
   • 步骤1：R1主动下线，通知哨兵节点。
   • 步骤2：S1、S2、S3的哨兵节点检测到R1下线，将其标记为主观下线。
   • 步骤3：S1、S2、S3的哨兵节点开始进行选举。
   • 步骤4：S1、S2、S3的哨兵节点相互通信，比较各个候选节点（R2、R3）的健康状态、复制偏移量、优先级等因素。
   • 步骤5：S2和S3一致地选择R2为新的主节点，并将其升级为主节点。
   • 步骤6：S1检测到大多数哨兵节点选择了R2，同意R2作为新的主节点。
   • 步骤7：客户端被通知重新连接到R2，R2成为新的主节点，负责处理写操作和读操作。
2. 被动下线：
   • 步骤1：R1发生故障，未能响应心跳检测，S1、S2、S3的哨兵节点将其标记为主观下线。
   • 步骤2：S1、S2、S3的哨兵节点开始进行选举。
   • 步骤3：S1、S2、S3的哨兵节点相互通信，比较各个候选节点（R2、R3）的健康状态、复制偏移量、优先级等因素。
   • 步骤4：S2和S3一致地选择R2为新的主节点，并将其升级为主节点。
   • 步骤5：S1检测到大多数哨兵节点选择了R2，同意R2作为新的主节点。
   • 步骤6：客户端被通知重新连接到R2，R2成为新的主节点，负责处理写操作和读操作。

在这两种情况下，哨兵节点通过协调和选举来选择新的主节点，并保持系统的连续性和高可用性。选举过程确保了选出的新主节点是唯一且一致的，并确保在主节点故障时能够快速选举出新的主节点，实现故障转移。这样，Redis能够保持服务的连续性，并提供高可靠性的数据存储和访问。

Demo2

如果Redis的主节点（Master）在故障后重新上线，哨兵节点会检测到主节点的重新上线并采取相应的操作来恢复主从复制关系。下面是主节点故障后重新上线的过程：

1. 主节点故障：
   • 步骤1：主节点（M）发生故障，哨兵节点将其标记为主观下线。
   • 步骤2：哨兵节点开始进行选举，选择一个从节点（Slave）升级为新的主节点。
2. 主节点重新上线：
   • 步骤3：主节点（M）修复故障并重新上线。
   • 步骤4：哨兵节点检测到主节点（M）重新上线，将其标记为主观上线。
3. 重新建立主从复制关系：
   • 步骤5：哨兵节点发送命令给主节点（M），要求其成为主节点。
   • 步骤6：主节点（M）接受命令，成为新的主节点。
   • 步骤7：哨兵节点更新配置信息，将主节点（M）重新设置为主节点，并将其他从节点（Slaves）重新配置为复制主节点（M）。

通过上述步骤，哨兵节点能够检测到主节点的重新上线，并重新建立主从复制关系。主节点（M）恢复为主节点角色，并负责处理写操作。其他从节点（Slaves）则重新配置为复制主节点（M），继续接收来自主节点的数据复制。

需要注意的是，在主节点重新上线的过程中，可能会发生主从切换。如果通过选举选择的新主节点仍然处于上线状态且健康，那么它将继续保持主节点角色。否则，当原主节点重新上线时，它有可能重新成为主节点。

这种机制确保了Redis集群的高可用性和容错性。即使主节点在故障后重新上线，哨兵节点能够检测到这一变化，并重新建立主从复制关系，确保数据的持久性和系统的连续性。