4. 哨兵机制详解

有的时候博客内容会有变动，首发博客是最新的，其他博客地址可能会未同步, 认准https://blog.zysicyj.top

前面我们说过，redis 采用了读写分离的方式实现高可靠。后面我们说了，为了防止主节点压力过大，优化成了主 - 从 - 从模式

思考一个问题，主节点此时挂了怎么办

这里主从模式下涉及到的几个问题：

  1. 主库真的挂了吗？
  2. 我们应当选择哪个从库作为主库？
  3. 怎样让其他从库知道新的主库信息呢？
  4. 中断的数据如何恢复？

哨兵机制就完美的解决了以上问题。

什么是哨兵机制？

Redis 引入哨兵（Sentinel）机制的主要目的是为了增强其高可用性和自动故障恢复能力。在分布式系统中，特别是用作数据存储的数据库系统中，保障高可用性是至关重要的，以确保系统在面对节点故障等情况时能够继续提供服务。

以下是引入 Redis 哨兵机制的原因：

  1. 故障检测和自动故障切换：
    哨兵允许您配置多个 Redis 节点，并监视它们的运行状况。如果主节点（Master）出现故障，哨兵可以自动检测到并执行故障切换，将一个可用的从节点（Slave）晋升为新的主节点，从而保证服务的可用性。

  2. 自动配置更新： 当 Redis 节点的拓扑结构发生变化（比如添加或移除节点）时，哨兵能够自动地通知客户端和其他 Redis 节点进行配置更新，从而确保整个集群的正确配置。

  3. 监控和报警： 哨兵不仅监视节点的健康状态，还可以提供有关节点运行状况的信息，例如主从复制是否正常、延迟情况等。这可以帮助管理员及时发现问题并采取措施。

  4. 无需人工干预的恢复： 哨兵允许自动故障切换，这意味着当主节点出现问题时，系统可以自动将一个从节点提升为新的主节点，而无需管理员手动介入，从而缩短恢复时间。

Redis 引入哨兵机制使得在分布式环境中更容易实现高可用性和故障恢复，而无需太多手动操作。哨兵机制可以确保 Redis 集群在节点故障时继续提供稳定的服务，对于那些对于高可用性要求较高的应用场景非常有用。

哨兵机制的基本流程

哨兵其实就是一个运行在特殊模式下的 Redis 进程，其随着主从实例同时运行。

那么哨兵负责哪些活呢？主要是以下三点：

  1. 监控
  2. 选主（选择主库）
  3. 通知

哨兵机制的三项任务与目标

监控

Redis 哨兵的监控流程涉及多个步骤，用于实时监控 Redis 集群中各个节点的状态并采取必要的措施来确保集群的可用性和稳定性。

  1. 节点发现和配置： 哨兵通过配置文件指定要监控的主节点和从节点。启动哨兵后，它会连接到指定的节点，并获取有关其他节点的信息，形成一个初始的监控拓扑。

  2. 心跳检测： 哨兵会定期向监控的节点发送 PING 命令来检测节点是否存活。这些节点可以是主节点、从节点或其他哨兵节点。如果哨兵在一定时间内没有收到响应，它会认为节点不可用。

  3. 节点状态变更： 当哨兵连续多次无法连接到一个节点时，它会将该节点标记为主观下线。当多个哨兵都将节点标记为主观下线时，这个节点会被认为是客观下线。

  4. 故障判断和选举： 当主节点被标记为客观下线时，哨兵会执行故障判断。它会从剩余的健康主节点中选举一个作为新的主节点，并将该信息广播给其他哨兵和客户端。故障判断的逻辑考虑了多个因素，包括优先级、最近一次复制偏移量等。

  5. 自动故障切换： 如果主节点被标记为客观下线，哨兵会通知从节点晋升为新的主节点。同时，哨兵会更新其他从节点的配置，使其复制新的主节点。这确保了即使主节点发生故障，集群仍然可以继续提供服务。

  6. 监控从节点： 哨兵还会监控从节点的状态，包括从节点是否与主节点保持同步，以及从节点的复制延迟情况。如果从节点无法同步或者复制延迟过高，哨兵会将其标记为不健康。

  7. 节点恢复： 如果一个节点从客观下线状态恢复，哨兵会将其标记为健康，并将其重新纳入集群中。从节点恢复后，它会重新同步主节点的数据。

  8. 配置更新： 如果集群的拓扑发生变化，例如添加或移除节点，哨兵会自动更新配置，以便客户端能够正确连接到集群。

  9. 事件通知： 哨兵通过发布订阅机制向订阅者（通常是客户端）发送有关集群状态变化的消息。这使得应用程序能够根据实时的集群状态做出相应的决策。

  10. 持续监控： 哨兵会持续地监控集群中的节点，定期执行心跳检测、状态更新和故障判断，以确保集群的稳定运行。

主观下线与客观下线

在 Redis 的哨兵监控机制中，有两个关键概念：主观下线（Subjective Down）和客观下线（Objective Down）。这些概念帮助哨兵判断节点的可用性和故障状态。

  1. 主观下线（Subjective Down）：
    主观下线是指单个哨兵节点认为一个特定的 Redis 节点（主节点、从节点或其他哨兵）不可用。主观下线是一种主观的判断，是基于单个哨兵节点的观察结果得出的。当一个哨兵无法连接到某个 Redis 节点，它会将该节点标记为主观下线。多个哨兵节点可能会对同一个节点发出主观下线标记。

  2. 客观下线（Objective Down）：
    客观下线是指在整个哨兵集合中达成一致，认为某个特定的 Redis 节点不可用。客观下线是一种更客观的判断，需要多个哨兵节点共同达成一致。当多个哨兵节点都主观下线同一个 Redis 节点时，这个节点会被认为是客观下线。

举例说明：

  • 假设有三个哨兵节点：Sentinel A、Sentinel B 和 Sentinel C，以及一个主节点 Master 和一个从节点 Slave。如果 Sentinel A 无法连接到
    Master 节点，它会将 Master 标记为主观下线。同样地，如果 Sentinel B 也无法连接到 Master 节点，它也会将 Master
    标记为主观下线。但这还不足以让 Master 被认为是客观下线。

  • 当 Sentinel A 和 Sentinel B 都主观下线了 Master 节点，并且他们相互通信时发现了这个情况，他们就会在达成一致意见后将
    Master 节点标记为客观下线。这时，整个哨兵集合达成一致，认为 Master 节点已下线。

客观下线是一个更严格的判断，需要多个哨兵节点一致认为某个节点不可用，才会触发后续的故障判断和自动故障切换等动作。这种机制确保了在一个哨兵节点认为某节点下线时，不会立即触发故障切换，以避免误判造成不必要的切换。只有多个哨兵节点一致认为节点下线，才会触发后续的故障处理流程。

客观下线的判断

如何选定新主库

在 Redis Sentinel 模式中，当主节点（Master）发生故障导致下线后，哨兵会通过选举过程选择一个新的主节点（Master）来取代原来的主节点。选定新主库的过程如下：

  1. 主观下线和客观下线判断： 当哨兵节点主观下线（单个哨兵认为不可用）一个主节点时，如果多数哨兵都主观下线了同一个主节点，那么这个主节点会被标记为客观下线（多数派共识）。

  2. 选举新主节点： 当一个主节点被标记为客观下线后，哨兵节点会开始选举一个新的主节点。选举过程如下：

    • 哨兵会在所有没有下线的从节点（Slaves）中选择一个作为新主节点。** 哨兵会选择一个延迟最小、复制偏移量最大的从节点作为新主节点
      **。这确保了新主节点是最接近原主节点的从节点。
    • 如果没有合适的从节点，哨兵会选择一个具备最高优先级的从节点，将其升级为主节点。如果优先级相同，那么哨兵会选择一个复制偏移量最大的从节点。

  3. 故障转移和切换： 一旦新主节点被选定，哨兵会发起故障转移操作。旧主节点会变成新主节点的一个从节点。其他从节点会重新配置，指向新的主节点。这个过程会保证尽量不丢失数据，并且保证整个集群的高可用性。

选定新主库的过程是一个由哨兵节点协同工作的流程，确保了在主节点故障的情况下，尽可能地选择一个合适的从节点作为新的主节点，实现集群的高可用性和数据完整性。

新主库的选择

如何配置哨兵

  1. 哨兵配置文件： 在 Redis 6.x 版本中，哨兵的配置文件名称默认为redis-sentinel.conf。

  2. 配置变化： Redis 6.x 版本引入了一些新的哨兵配置选项，以适应新的功能和改进。以下是一些常见的配置选项：

    1
    2
    3
    4
    5
    sentinel monitor mymaster 127.0.0.1 6379 2   # 监控名为 "mymaster" 的主节点，2 表示至少需要 2 个哨兵同意主观下线才会执行故障转移
    sentinel down-after-milliseconds mymaster 5000   # 主观下线判定为 5 秒无响应
    sentinel parallel-syncs mymaster 1   # 执行故障转移时同时同步的从节点数量
    sentinel failover-timeout mymaster 10000   # 故障转移超时时间为 10 秒
    sentinel auth-pass mymaster mypassword   # 主节点的访问密码

  3. 启动哨兵节点： 在 Redis 6.x 版本中，启动哨兵节点的命令为：

    1
    redis-server /path/to/redis-sentinel.conf --sentinel

  4. 查看哨兵状态： 使用以下命令查看 Redis 6.x 版本哨兵节点的状态：

    1
    2
    3
    4
    redis-cli -p 26379
    sentinel master mymaster   # 查看主节点的信息
    sentinel slaves mymaster   # 查看从节点的信息
    sentinel sentinels mymaster   # 查看其他哨兵节点的信息

哨兵是如何互相发现的？

我们查看配置可以看到，我们并没有配置从节点的哨兵，我们只配置了主节点地址。

那么哨兵之间是如何互相发现通信的呢？

在 Redis Sentinel（哨兵）集群中，哨兵节点之间通过发布订阅机制来互相发现和通信。这种方式使得哨兵节点能够监控主节点和从节点的状态，并进行故障检测和故障转移。

以下是哨兵集群如何通过发布订阅机制互相发现的工作流程：

  1. 初始连接： 在启动时，每个哨兵节点会尝试连接到指定的主节点。这些哨兵节点通过配置文件中的 sentinel monitor
    命令指定要监控的主节点信息。

  2. Sentinel 命令发布：
    当一个哨兵节点成功连接到主节点后，它会开始定期向主节点发送 PING 命令，以确保主节点处于活跃状态。如果哨兵节点检测到主节点不可用，它会将一个 +switch-master
    命令发布到频道中，通知其他哨兵节点。

  3. 发布订阅机制：
    Redis 的发布订阅机制允许一个节点（发布者）向一个或多个节点（订阅者）广播消息。在哨兵集群中，每个哨兵节点都订阅了一个名为 __sentinel__:hello
    的频道，用于接收其他哨兵节点发送的信息。

  4. 发现其他哨兵节点： 当一个哨兵节点成功连接到主节点后，它会向 __sentinel__:hello 频道发布一个”Hello”
    消息，其中包含它自己的信息（如 IP 地址和端口号）。其他哨兵节点通过订阅这个频道，可以获取所有其他哨兵节点的信息。

  5. 收集哨兵信息： 每个哨兵节点通过订阅 __sentinel__:hello 频道，收集到其他哨兵节点的信息。这使得每个哨兵节点都知道了集群中其他哨兵节点的存在。

  6. 故障检测和转移： 当一个哨兵节点检测到主节点不可用时，它会通过发布 +switch-master
    命令来通知其他哨兵节点。这个命令包含了新的主节点信息，以及在执行故障转移时需要的其他信息。其他哨兵节点收到这个命令后，会进行判断并可能发起故障转移。

通过以上机制，哨兵节点可以相互发现和通信，共同监控主节点和从节点的状态，并在主节点下线时协同执行故障转移操作。这种发布订阅机制确保了哨兵集群中节点之间的实时信息传递和协作。

由哪个哨兵执行主从切换？

客观下线具体判断流程

  1. 故障检测： 哨兵节点定期向集群中的所有主节点和从节点发送 PING 命令来检测节点的可用性。如果一个哨兵节点连续一定次数没有收到节点的回复，就会将该节点标记为可能进入客观下线状态。

  2. Quorum 判断： 在判断一个节点是否客观下线时，需要考虑 Quorum 的概念。Quorum 是指一个最小的投票数，当达到或超过这个投票数时，哨兵认为节点可能进入客观下线状态。Quorum 的值通常设置为哨兵节点数量的一半加一。

  3. 投票过程： 当哨兵节点开始怀疑某个节点可能客观下线时，它会向其他哨兵节点发送一个 SENTINEL
    is-master-down-by-addr 命令，询问其他哨兵节点是否也认为该节点客观下线。其他哨兵节点会对此做出回应，根据回应的数量来判断是否达到 Quorum。

  4. 达到 Quorum： 如果收到的回应数量达到或超过 Quorum，那么哨兵节点就会认为该节点进入客观下线状态。这表示集群中有足够多的哨兵都认为该节点可能下线，进而触发后续的主从切换流程。

  5. 执行后续操作： 一旦一个节点被认为客观下线，哨兵节点将开始执行故障转移操作，选择新的主节点并开始同步数据。这将最终导致一个新的主节点被选出，从而实现高可用性。

选举 Leader 流程

Redis Sentinel（哨兵）是用于监控和管理 Redis 主从复制以及自动故障切换的工具。当主节点失效时，哨兵会协调选择一个从节点作为新的主节点，这涉及到选举 Leader 的过程。详细流程如下：

  1. 监控主节点： 哨兵持续监控 Redis 主节点的状态，包括主节点是否在线，主从复制是否正常，以及哨兵和其他节点的通信情况。

  2. 检测主节点失效： 当哨兵检测到主节点失效（例如，无法响应 PING 命令），它会将主节点标记为“主观下线”。

  3. 广播主观下线状态： 一旦主观下线状态被确认，哨兵会广播该信息给其他哨兵和节点，告知主节点已经“主观下线”。

  4. 投票： 当其他哨兵收到关于主观下线状态的广播时，它们会进行投票来决定是否需要进行领导者选举。

  5. 选举 Leader： 如果多个哨兵都认为主节点失效，它们将进入领导者选举过程。选举过程使用了 Raft 算法的变体。

  6. 提议投票： 在选举过程中，哨兵会提议自己作为领导者，然后请求其他哨兵投票支持。

  7. 投票表决： 哨兵在收到提议后会表决是否支持该提议。通常，哨兵会投票给具有最高配置版本号的提议者。

  8. Quorum 判断： 在选举过程中，哨兵需要收集足够数量的投票，达到 Quorum（大多数）的支持才能选举成功。

  9. 选出新领导者： 如果某个哨兵获得足够多的投票，超过了 Quorum，那么它将被选为新的领导者。

  10. 通知其他节点： 新选出的 Leader 会向其他哨兵和节点广播其成为领导者的消息，确保集群中的所有节点都知道领导者的变更。

  11. 故障切换： 一旦新的 Leader 选举完成，哨兵会协调进行故障切换，将一个从节点提升为新的主节点，使整个集群继续正常运行。

  12. 恢复正常状态： 一旦故障切换完成，新的主节点将开始处理客户端请求，集群会恢复到正常运行状态。

需要注意的是，Redis Sentinel 的选举 Leader 过程受到 Paxos 算法和 Raft 算法等分布式一致性算法的影响，以保证在主节点失效时能够选择合适的节点作为新的主节点，从而保持数据的一致性和高可用性。

TIP

  1. 如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得 2 票，而不是 1
    票。所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。因此，通常我们至少会配置 3 个哨兵实例。

  2. 要保证所有哨兵实例的配置是一致的，尤其是主观下线的判断值 down-after-milliseconds。down-after-milliseconds。