模式红色里守卫Redis用哨兵监听，redis怎么靠哨兵来盯着跑的

主要依据Redis官方文档关于哨兵的描述,并结合常见的分布式系统监控原理进行阐述）

Redis哨兵模式的核心目标，就是让Redis从单点服务变成一个高可用的服务，所谓高可用，简单说就是即使一台机器出问题了，整个Redis服务还能继续正常工作，不影响使用，而哨兵，就是实现这个目标的“守护者”或者“监控小组”。

这个“监控小组”具体是怎么盯着Redis运行的呢？整个过程可以分成几个关键的步骤,就像一支训练有素的安保团队在执行任务。

第一步：建立联系，获取情报

你需要部署多个哨兵实例，只部署一个哨兵是不安全的，因为如果这个哨兵自己宕机了，那就没人执行监控和切换任务了，哨兵的数量是奇数个，比如3个或5个,这样可以方便后续的投票决策。

每个哨兵启动的时候，你都需要告诉它主要监控哪个（或哪些）Redis主节点（Master），哨兵会先与这个主节点建立连接，建立连接后,哨兵会做两件重要的事：

1. 信息交换：哨兵会定期（比如每10秒）向主节点发送INFO命令，主节点会回复自己的详细信息，包括它的角色（是主节点）、它负责的从节点（Slave/Replica）有哪些、以及这些从节点的地址和端口，通过这个命令，哨兵就像从“指挥官”（主节点）那里拿到了一份完整的“部队花名册”，知道了整个Redis集群（这个主节点和它下面所有的从节点）的完整结构。
2. 发布订阅：哨兵会与主节点和所有通过INFO命令发现的从节点，都建立一个特殊的“发布订阅”连接，这个连接就像一个专用的广播频道,主要用于哨兵之间的通信。

第二步：持续心跳检测，判断生死

拿到了“花名册”后，哨兵就开始对名单上的每一个Redis节点（包括主节点和所有从节点）进行持续不断的“健康检查”，这个检查非常简单直接，就是哨兵定期（比如每秒）向所有节点发送一个PING命令。

正常情况下，节点会回复PONG，哨兵根据节点的回复情况和回复速度,来判断节点的状态：

• 正常在线：如果节点在配置的时间内回复了PONG，哨兵就认为它“健康”。
• 主观下线：如果某个节点（尤其是主节点）在指定的时间内没有回复PING命令，或者回复了一个错误信息，那么发起这次PING的哨兵就会“主观地”认为这个节点“失联”了，并将其标记为“主观下线”，注意，这只是这个哨兵“个人”的看法，可能存在误判（比如当时网络闪断了一下）。

第三步：集体决策，避免误判

一个哨兵认为主节点失联，这可能是个意外，为了确保判断的准确性，避免“冤假错案”，哨兵机制引入了“投票仲裁”。

当某个哨兵将主节点标记为“主观下线”后，它不会立即行动，它会通过之前建立的发布订阅连接，向其他哨兵发送一条消息，内容是：“我认为主节点XXX已经下线了，你们觉得呢？”

其他哨兵收到这条消息后，会各自独立地尝试连接这个主节点，用自己的方式去验证,它们也会通过这个发布订阅频道回复自己的判断结果。

如果同意主节点下线的哨兵数量达到了一个预先设定的“法定人数”（比如3个哨兵中至少有2个同意），主节点就会被正式标记为“客观下线”，这意味着整个哨兵团队达成了共识，认定主节点确实出了问题，这个“法定人数”通常是在哨兵的配置文件中提前设置好的。

第四步：故障转移，推举新主

一旦主节点被判定为“客观下线”，监控小组就不能只是看着了，必须采取行动——也就是启动“故障转移”流程，从剩下的从节点中选出一个新的主节点,来接替工作。

选举新主节点的过程同样是一个民主投票的过程：

1. 发起选举：其中一个哨兵（通常是第一个发现主节点客观下线的，或者通过某种规则选出的领头哨兵）会开始主持大局。
2. 筛选候选人：它会检查所有从节点的状态，过滤掉那些已经断线很久或者数据太旧的从节点,留下健康的从节点作为候选人。
3. 投票选举：这个主持的哨兵会向其他哨兵提议将某个从节点提升为新的主节点，每个哨兵都会投票同意或者反对，同样，只有当同意票数达到法定数量时,这个选举结果才有效。
4. 执行切换：选举通过后，主持的哨兵会执行一系列操作：让选中的从节点执行SLAVEOF NO ONE命令，让它转变为主节点；让其他从节点改为复制这个新的主节点；哨兵会更新自己的配置，将监控目标指向新的主节点，并通知可能的客户端（如果客户端支持哨兵协议）主节点已经变更。

通过以上这四个步骤的循环往复——持续监控、心跳检测、集体决策、故障转移——Redis哨兵系统就像一群不知疲倦的守卫，时刻紧盯着Redis主从集群的一举一动，一旦主节点发生故障，它们能够自动、快速地从内部达成一致，并完成领导权的平稳交接，从而保证了Redis服务的高可用性，整个过程尽可能地减少了人工干预,使得系统在面临单点故障时能够自我修复。

（字数统计：约1200字）