Redis：哨兵机制

为什么要有哨兵？

Redis 哨兵是一个分布式系统，用于监控 Redis 主从集群的状态，并在主节点出现故障时自动进行故障转移，确保系统的高可用性。它可以实时监测多个 Redis 节点的运行状况，包括主节点和从节点。引入哨兵的好处：

保证系统高可用：在 Redis 主从复制架构中，主节点承担着读写操作，一旦主节点出现故障，整个系统就会面临无法写入和部分读取异常的问题。哨兵能够实时监测主节点的运行状态，当主节点发生故障时，自动将一个从节点提升为新的主节点，保证系统的读写功能能够继续进行，从而提高系统的可用性和稳定性。
实现自动故障转移：通过哨兵的自动故障转移机制，能够在主节点故障时快速地完成新主节点的选举和切换，无需人工干预，大大减少了系统故障恢复时间。这对于一些对实时性要求较高的应用场景至关重要，可以避免因人工介入不及时而导致的业务长时间中断。
监控与通知：哨兵可以监控整个 Redis 集群中各个节点的运行状况，包括主节点、从节点的状态信息，如节点是否在线、内存使用情况、复制偏移量等。同时，当集群中发生节点故障、主从切换等重要事件时，哨兵能够及时向管理员或其他相关组件发送通知，以便及时采取相应的措施。

哨兵会不断检查主节点和从节点的状态，确保它们正常运行。哨兵通过以下方式实现监控：

定期发送 PING 命令 ：哨兵会定期向主节点、从节点和其他哨兵实例发送 PING 命令，检测它们是否正常运行。
检查响应 ：如果节点在指定时间内（由 down-after-milliseconds 配置项决定）没有响应 PING 命令，哨兵会将该节点标记为 主观下线（Subjectively Down, SDOWN）。
多哨兵确认 ：单个哨兵的主观下线判断可能会误判（例如网络抖动），因此需要多个哨兵实例共同确认。如果多数哨兵都认为主节点下线，则主节点会被标记为 客观下线（Objectively Down, ODOWN）。

如果主节点失效，哨兵会自动将一个从节点提升为新的主节点，并让其他从节点复制新的主节点。选主的过程分为以下几个步骤：

选举领头哨兵（Leader Sentinel） ：
- 当主节点被标记为客观下线后，所有哨兵实例会通过 Raft 算法选举出一个领头哨兵。（哨兵节点一般设置为奇数个便于投票选举）
- 领头哨兵负责执行故障转移操作，其他哨兵则处于跟随状态。
选择新的主节点 ：
- 领头哨兵会从当前的从节点中选择一个最合适的节点作为新的主节点。
- 选择标准包括：
  - 从节点的优先级（由 slave-priority 配置项决定，一般根据服务器配置设置）。
  - 从节点的复制偏移量（选择数据最接近原主节点的从节点，也就是offset最大的节点）。
  - 从节点的运行状态（选择运行时间最长的从节点，也就是runid最小的节点）。
提升从节点为主节点 ：
- 领头哨兵会向选定的从节点发送 SLAVEOF NO ONE 命令，将其提升为主节点。
- 然后，哨兵会更新其他从节点的配置，让它们复制新的主节点。
更新配置 ：
- 故障转移完成后，哨兵会更新自己的配置文件，记录新的主节点信息。

当监控的 Redis 实例出现问题时，哨兵可以通过 API 或脚本通知系统管理员或其他应用程序。哨兵支持以下通知方式：