上篇文章我们讲述了Redis中的主从复制（Redis分布式系统中的主从复制-CSDN博客），本篇文章针对主从复制中的问题引出Redis中的哨兵，希望本篇文章会对你有所帮助。
文章目录
一、引入哨兵机制
二、基本概念
三、主从复制的问题
四、哨兵自动恢复主节点故障
五、哨兵重新选取主节点的流程（原理）
🙋♂️ 作者：@Ggggggtm 🙋♂️
👀 专栏：Redis 👀
💥 标题：Redis中的哨兵💥
❣️ 寄语：与其忙着诉苦，不如低头赶路，奋路前行，终将遇到一番好风景 ❣️
一、引入哨兵机制
Redis中的主从复制最大的问题就是在主节点上。现在我们具体来分析一下其原因。假如现在主从复制当中，有一个从节点因为网络抖动或者其他原因与主节点断开连接，这时候对其他的节点影响大吗？实际上影响并不大的，Redis的客户端可以从其他的从节点正常读取数据，并且也不影响对主节点的读和写操作。等网络稳定，或者该从节点再次主动执行slaveof来接入该主从复制结构，最坏的情况也就是全量复制同步数据。
如果主节点挂了呢？主节点挂了从节点就迷茫了。虽然能够提供读操作，但是从节点不能自动的升级成主节点，也就是不能替换原有主节点对应的角色。此时就需要程序猿/运维手工的恢复主节点。通常情况下，管理员需要手动选择一个从节点作为新的主节点，并更新其他从节点的配置，将其设置为新主节点的从节点（slaveof masterhost masterport）。这个过程可能涉及到修改配置文件、执行命令等操作。 过程繁杂，且有可能出现意外情况。
针对上述的情况，Redis引入了哨兵（Sentinel）机制。Redis Sentinel是一个分布式系统，用于监控Redis集群中各个节点的状态，并在发现故障时自动进行故障转移。它可以自动识别主节点的故障，并将一个从节点晋升为主节点，从而实现故障恢复的自动化。通过Redis Sentinel的监控和自动化故障处理机制，可以大大提高系统的可用性和稳定性，降低故障恢复的时间成本，从而保证系统能够在面对各种故障和异常情况时依然能够正常运行。
下面我们来详细学习Redis Sentinel中的细节。
二、基本概念
由于对 Redis的许多概念都有不同的名词解释，所以在介绍Redis Sentinel之前，先对几个名词概念进行必要的说明，如表所示。
注意：哨兵节点是一个单独的进程，此功能并不是集成在主从复制当中的。哨兵机制就是通过哨兵节点来解决 Redis 主节点挂掉的问题的方法。哨兵节点不负责存储数据，主要是用来监控监控 Redis 主从服务器是否正常运行，并且在主节点挂掉后能够自动完成切换主节点，也就是故障转移工作。
考虑到单个哨兵节点挂掉时，监控与自动切换主节点无法正常完成，因此通常会部署多个哨兵节点构成一个集合。这样即使一个哨兵节点挂掉，其他哨兵节点仍然可以监控 Redis 主节点的状态，并且当主节点出现故障时，其他哨兵节点可以通过投票来选举出一个新的主节点。这种方式确保了 Redis 集群的高可用性和容错性。
Redis Sentinel 是 Redis 提供的高可用实现方案。在实际的生产环境中，它扮演着关键的角色，为系统提供了稳定可靠的服务。在面对可能的故障时，Redis Sentinel能够迅速识别问题并采取必要的措施，确保系统持续运行。
三、主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：
- 第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶”上来，并且保证数据尽量不丢失(主从复制表现为最终一致性)。
- 第二，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。
但是主从复制模式并不是万能的，它同样遗留下以下几个问题:
- 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。
- 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。其中第一个问题是高可用问题，即 Redis哨兵主要解决的问题。第二个问题是属于存储分布式的问题，留给Redis集群去解决，本篇文章我们集中讨论第一个问题。
接下来我们来还原以下主从复制模式中的主节点出现问题的场景。
现有如下主从复制结构：
有如下突发情况：大半夜Redis主从复制中的主节点挂掉了，领导打电话让你赶快重新配置一下。此时的你一脸高兴（我上早八）的从床上爬起来，打开电脑连接到公司的电脑。然后你选择先看看主节点还能不能抢救了，好不好抢救。如果主节点这边是啥原因挂的不好定位，或者原因知道但是短时间难以解决，就需要挑一个从节点设置为新的主节点让Redis保持正常工作。然后你开始做了：
- 把选中的从节点通过slaveof no one，与主节点断开主从关系，自己成为一个主节点；
- 把其他的从节点修改slaveof的主节点ip port，连上新的主节点；
- 告知客户端(修改客户端的配置)，让客户端能够连接新的主节点，用来完成修改数据的操作。
- 再去产看之前的主节点。当之前的挂了的主节点修好了之后，在修改一下该主节点的配置文件，就可以作为一个新的从节点挂到这组机器中。
上述过程顺利的话你可能一个小时就完成了。但是在顺利的情况下你勉强能接受，不顺利呢？半夜的你的状态、心情等等因素，即使你的状态不错，但凡涉及到人工去修改，就会有概率出错！可能会导致问题更加严重。半夜起来修改不说，结果弄的一团糟~~
其次你在修改的工程中，Redis客户端的写操作怎么办呢？主节点都挂了还要怎么写啊！显然上述的过程不是很靠谱。
四、哨兵自动恢复主节点故障
当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方从而实现真正的高可用。
Redis Sentinel是一个分布式架构，其中包含若干个Sentinel（哨兵）节点和Redis数据节点（主从节点），每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线表示。如果下线的是主节点，它还会和其他的Sentinel节点进行“协商”，当大多数Sentinel节点对主节点不可达这个结论达成共识之后，它们会在内部“选举”出一个领导节点来完成自动故障转移的工作，同时将这个变化实时通知给Redis应用方。整个过程是完全自动的，不需要人工介入。
具体来说，Redis的主从节点负责存储数据和处理客户端请求，Sentinel节点则负责监控和管理Redis数据节点的状态以及执行故障转移等任务。客户端可以连接到任何一个Redis节点，通过Sentinel节点来获取集群的状态信息和执行故障转移等操作，从而实现对Redis集群的管理和监控。
需要注意的是，在这种架构下Redis数据节点和Sentinel节点都是独立部署的，它们之间没有直接的数据交互，而是通过网络进行通信。注意：上图中的监控是指这些进程之间会建立tcp长连接，通过这样的长连接定期发送心跳包。这种分布式架构使得整个系统更具弹性和容错能力，即使某个物理节点出现故障，也不会影响整个系统的正常运行。
上图我们也能看出： Redis Sentinel引入多个Sentinel节点，系统具备了更强的可靠性和容错能力。当有多个Sentinel节点同时监控集群时，即使部分Sentinel节点出现故障或无法正常工作，仍然可以保证集群的监控和管理功能不受影响。为了确保在进行故障检测和故障转移时能够达成多数派的共识，建议使用奇数个Sentinel节点（后续会解释）。
现在Sentinel节点监控现有的redis master 和 slave，如果是slave挂了，并没有任何关系。但是主节点挂了， Redis Sentinel就要进行故障转移了。针对主节点故障转移流程大致如下∶
- 主节点故障，从节点同步连接中断，主从复制停止。
- 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商，达成多数认同主节点故障的共识。这步主要是防止该情况：出故障的不是主节点，而是发现故障的哨兵节点或者是因为网络问题，该情况经常发生于哨兵节点的网络被孤立的场景下。‘
- 哨兵节点之间使用Raft算法选举出一个领导角色，由该节点负责后续的故障转移工作。
- 哨兵领导者开始执行故障转移：从节点中选择一个作为新主节点，让其他从节点同步新主节点。该工作也就是前面我们说到的人工操作恢复故障的工作。
- 哨兵节点会自动的通知客户端程序告知新的主节点是谁，并且后续客户端再进行写操作,就会针对新的主节点进行操作了。
通过上述我们也能分析出redis哨兵核心功能：
- 监控数据节点，主要是主节点；
- 自动的故障转移；
- 通知客户端。
注意redis 哨兵节点只有一个也是可以的。如果哨兵节点只有一个，它自身也是容易出现问题的。万一这个哨兵节点挂了，后续redis主节点也挂了，就无法进行自动的恢复过程了。
出现误判的概率也比较高，毕竟网络传数据是容易出现抖动或者延迟或者丢包的。如果只有一个哨兵节点出现上述因网络问题造成误判之后，影响就比较大。
五、哨兵重新选取主节点的流程（原理）
假定当前环境有三个哨兵(sentenal1, sentenal2, sentenal3),一个主节点(redis-master),两个从节点(redis-slave1, redis-slave2)。当主节点出现故障,就会触发重新一系列过程。
哨兵重新选取主节点的前提是多个哨兵节点确定主节点挂掉了。注意：是多个哨兵节点判断主节点挂掉了。怎么就多个哨兵节点可以都判断该主节点挂掉了呢？因此在 Redis 哨兵（Sentinel）中，sdown 表示主观宕机（Subjectively Down），odown 表示客观宕机（Objectively Down）。
sdown 是指单个哨兵节点认为某个 master 节点宕机了。具体来说，如果一个哨兵节点向 master 发送 ping 命令（心跳机制），在超过指定的毫秒数之后没有收到有效回复，那么这个哨兵就会主观认为 master 宕机，将其标记为 sdown。
odown 则是指多个哨兵节点都认为某个 master 节点宕机了。当一个哨兵将 master 标记为 sdown 后，它会在指定时间内，每秒向其他哨兵发送
i消息来询问它们是否也认为该 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，以实现数据的分片和分布式存储。
