Redis哨兵（Sentinel）

Redis哨兵

‌[Redis哨兵]（Sentinel）是Redis的一个高可用性解决方案，主要用于监控和管理多个Redis服务器，确保Redis系统的高可用性‌。哨兵通过实时监测主节点和从节点的状态，及时发现并自动处理故障，保证系统的稳定运行‌

作用：

‌监控‌：定期检查Redis实例的健康状态。

‌故障转移‌：当主节点发生故障时，自动将一个从节点提升为新的主节点，并重新配置其他从节点同步新主节点的数据。

‌通知‌：在Redis实例发生故障或恢复时，向管理系统发送通知。

‌配置管理‌：客户端可以通过哨兵获取当前主节点的地址，实现动态路由‌

常用名词

配置参数说明

重点配置参数说明

①sentinel monitor <master-name> <ip> <redis-port> <quorum>：设置要监控的master服务器。quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数（我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。）

②sentinel auth-pass <master-name> <password>：master设置了密码，指定连接master服务的密码

其它配置参数说明

①sentinel down-after-milliseconds <master-name> <milliseconds>：

指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

②sentinel parallel-syncs <master-name> <nums>：

表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

③sentinel failover-timeout <master-name> <milliseconds>：

故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

④sentinel notification-script <master-name> <script-path> ：

配置当某一事件发生时所需要执行的脚本

⑤sentinel client-reconfig-script <master-name> <script-path>：

客户端重新配置主节点参数脚本

哨兵自动恢复主节点故障

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

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

具体来说，Redis的主从节点负责存储数据和处理客户端请求，Sentinel节点则负责监控和管理Redis数据节点的状态以及执行故障转移等任务。客户端可以连接到任何一个Redis节点，通过Sentinel节点来获取集群的状态信息和执行故障转移等操作，从而实现对Redis集群的管理和监控。

需要注意的是，在这种架构下Redis数据节点和Sentinel节点都是独立部署的，它们之间没有直接的数据交互，而是通过网络进行通信。

注意：上图中的监控是指这些进程之间会建立tcp长连接，通过这样的长连接定期发送心跳包。这种分布式架构使得整个系统更具弹性和容错能力，即使某个物理节点出现故障，也不会影响整个系统的正常运行。

针对主节点故障转移流程大致如下∶

主节点故障，从节点同步连接中断，主从复制停止。

哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商，达成多数认同主节点故障的共识。这步主要是防止该情况：出故障的不是主节点，而是发现故障的哨兵节点或者是因为网络问题，该情况经常发生于哨兵节点的网络被孤立的场景下。

哨兵节点之间使用Raft算法选举出一个领导角色，由该节点负责后续的故障转移工作。

哨兵领导者开始执行故障转移：从节点中选择一个作为新主节点，让其他从节点同步新主节点。该工作也就是前面我们说到的人工操作恢复故障的工作。

哨兵节点会自动的通知客户端程序告知新的主节点是谁，并且后续客户端再进行写操作,就会针对新的主节点进行操作了。

哨兵重新选取主节点的流程（原理）

哨兵重新选取主节点的前提是多个哨兵节点确定主节点挂掉了。注意：是多个哨兵节点判断主节点挂掉了。怎么就多个哨兵节点可以都判断该主节点挂掉了呢？因此在 Redis 哨兵（Sentinel）中，sdown 表示主观宕机（Subjectively Down），odown 表示客观宕机（Objectively Down）。

sdown 是指单个哨兵节点认为某个 master 节点宕机了。具体来说，如果一个哨兵节点向 master 发送 ping 命令（心跳机制），在超过指定的毫秒数之后没有收到有效回复，那么这个哨兵就会主观认为 master 宕机，将其标记为 sdown。
odown 则是指多个哨兵节点都认为某个 master 节点宕机了。当一个哨兵将 master 标记为 sdown 后，它会在指定时间内，每秒向其他哨兵发送消息来询问它们是否也认为该 master 是 sdown。如果收到该消息的其他哨兵中，有达到法定票数的数量（可配置的最小数量）的哨兵都认为那个 master 是 sdown，那么就可以认为是 odown，即客观认为 master 宕机。

多个哨兵需要判定主节点是否挂了，这样才更加安全。但是有的时候可能因为特殊情况，比如主节点仍然工作正常，但是哨兵节点自己网络出问题了，无法访问到主节点了。此时就可能会使该哨兵节点认为主节点下线而出现误判。使用投票的方式来确定主节点是否真的挂了是更稳妥的做法，需要多个哨兵都认为主节点挂了，即票数>=法定票数之后才会真的认为主节点是挂了。

确定master客观下线后，要让多个哨兵节点选出一个leader节点，由这个leader负责选一个从节点作为新的主节点。怎么选出一个leader呢？

Raft 算法是一种被广泛应用于分布式系统中的共识算法，用于确保系统中的多个节点能够达成一致的决策。在 Redis 哨兵集群中，Raft 算法通常用于选举领导者（leader），以协调故障转移过程。

假设我们有三个哨兵节点：S1、S2 和 S3。在故障转移过程中，哨兵节点之间会相互发起选举，以下是大致的选举流程：

①拉票请求发起：每个哨兵节点都会向其他所有哨兵节点发起拉票请求，表达自己的候选人意愿。例如，哨兵节点 A（S1）会给哨兵节点 B（S2）和哨兵节点 C（S3）发送拉票请求，哨兵节点 B（S2）会给哨兵节点 A（S1）和哨兵节点 C（S3）发送拉票请求，以此类推。 ②投票响应：收到拉票请求的哨兵节点会根据自身的情况作出投票决定，并回复投票响应。每个哨兵节点只有一票，并且只能投给一个候选人。如果收到的是第一次拉票请求，那么响应方将投票给拉票方。如果已经给其他候选人投过票，那么就不再投票。

③选举结果确认：在一轮投票结束后，如果有一个候选人收到了超过半数的选票，那么它将自动成为领导者。例如，如果 S1 和 S2 都投给了 S3，那么 S3 将成为领导者。如果没有候选人获得半数以上的选票，则会重新进行选举。

④领导者选举完成：新选出的领导者负责挑选一个从节点升级为新的主节点。例如，如果 S3 成为了领导者，它将选择一个从节点升级为新的主节点。其他哨兵节点会观察到新的主节点的出现，从而确认选举过程已经结束通过上述流程我们能够看出Raft 算法的核心理念是“先下手为强”，即率先发起拉票请求的候选人更有可能成为领导者。选举的结果可能受到网络延迟的影响，因此选举过程中会有一定的随机性。

在 Redis 哨兵集群中，确保哨兵节点数量为奇数有助于降低出现平票的可能性，从而减少额外的选举开销。偶数个哨兵节点出现的平票概率相对来说大意是点。这一过程确保了集群在主节点故障时能够快速有效地进行故障转移。

选出leader后，那么由该leader选出一个从节点作为新的主节点，那么这里问题又来了：选哪个从节点呢？这里也是有挑选规则的：

①比较优先级。优先级高(数值小的)的上位，优先级是配置文件中的配置项(slave-priority或者replica-priority )；

②比较replication offset谁复制的数据多，高的上位。offset 为从节点从主节点这边同步数据的进度。数值越大说明从节点的数据和主节点就越接近；

③比较run id ,谁的id 小，谁上位。这个run id生成的大小是随机的。(此时选谁都可以了，随便挑一个)。

把新的主节点指定好了之后，leader就会控制这个这个节点执行slave no one，成为master。再控制其他节点,执行slave of ，让这些其他节点,以新的 master作为主节点了。

注意事项：

哨兵节点数量： 哨兵节点尽量不要只有一个，因为如果唯一的哨兵节点挂了，将会影响系统的可用性。建议至少使用三个哨兵节点，以确保高可用性。
奇数个哨兵节点： 最好将哨兵节点配置为奇数个。这样做有利于选举领导者，因为得票超过半数的概率更高，从而降低了出现平票的可能性。
哨兵节点的角色： 哨兵节点不负责存储数据，它们的主要作用是监控和管理 Redis 主从节点。实际的数据存储仍然由 Redis 主从节点负责。
提高可用性： 哨兵节点和主从复制结合解决了提高系统的可用性的问题，但无法解决数据丢失的问题。在极端情况下（主节点没来得及同步就挂了），可能会发生写入数据丢失的情况，因此需要结合其他机制来确保数据的持久性和一致性。
存储容量限制： 哨兵节点和主从复制不能提高数据的存储容量。当需要存储的数据接近或超过服务器的物理内存时，单纯依靠这种结构将难以满足需求。为了扩展存储容量，需要引入集群架构，如 Redis Cluster，以实现数据的分片和分布式存储。