关于后端:Redis系列四哨兵机制详解

首发博客地址

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 版本引入了一些新的哨兵配置选项，以适应新的性能和改良。以下是一些常见的配置选项：

   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 版本中，启动哨兵节点的命令为：

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

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

   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。

本文由 mdnice 多平台公布