Redis 哨兵机制

哨兵机制概念

先抽象的理解，哨兵就像是监工，节点不干活了，就要有行动了。

Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于客户规模大的应⽤来说，这种⽅案是⽆法接受的（可用性低）。

Redis哨兵机制（Sentinel）是一种Redis的高可用解决方案，它由一组Redis服务器组成，这些服务器负责监控Redis主节点和从节点的健康状态，并在主节点发生故障时自动进行故障转移，选举出一个新的主节点，从而确保系统的稳定性和数据的完整性

相关知识铺垫

1. 各节点概念

Redis 主节点 ： 提供主服务，是⼀个独⽴的 redis-server 进程。

Redis 从节点 ： 提供从服务 ，是⼀个独⽴的 redis-server 进程。

Redis 数据节点： 数据节点通常指的是存储实际数据的Redis实例，包括主节点和从节点。

Redis 哨兵节点： 哨兵节点（Sentinel Nodes）是负责监控Redis主节点和从节点状态的特殊Redis实例。它们是Redis哨兵机制的核心组成部分。具体表现为⼀个独⽴的 redis-sentinel 进程。

Redis 哨兵节点集合： 若⼲哨兵节点的抽象组合，具体表现为多个 redis-sentinel 进程。

Redis 哨兵（Sentinel：） Redis 提供的⾼可⽤⽅案 哨兵节点集合 和 Redis 主从节点

Redis 应⽤⽅： ⼀个或多个连接 Redis 的客户端进程

2. 心跳包概念

心跳包（Heartbeat Packets）是一种在客户端和服务器之间定期发送的、用来确认通信链路是否存活的数据包。它们用于检测网络连接的状态，确保通信双方仍然在线并且能够正常通信。心跳包的发送频率通常由应用或协议自行定义。

主从复制缺陷

回顾主从复制的作用：

第⼀，作为主节点的⼀个备份，⼀旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上
来，并且保证数据尽量不丢失（主从复制表现为最终⼀致性）。
第⼆，从节点可以分担主节点上的读压⼒，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上

分析主从复制的不足：
1.主节点发⽣故障时，进⾏主备切换的过程是复杂的，需要完全的⼈⼯参与，导致故障恢复时间⽆法保障。
2. 主节点可以将读压⼒分散出去，但写压⼒/存储压⼒是⽆法被分担的，还是受到单机的限制。其中第⼀个问题是⾼可⽤问题，即 Redis 哨兵主要解决的问题。

哨兵机制主要解决第一个不足。

哨兵工作流程

当主节点出现故障时，Redis Sentinel 能⾃动完成故障发现和故障转移，并通知应⽤⽅，从⽽实现真正的⾼可⽤。Redis Sentinel 是⼀个分布式架构，其中包含若⼲个 Sentinel 节点和 Redis 数据节点，每个Sentinel 节点会对数据节点和其余 Sentinel 节点进⾏监控，当它发现节点不可达时，会对节点做下线。如果下线的是主节点，它还会和其他的 Sentinel 节点进⾏ “协商”，当⼤多数 Sentinel 节点对主节点不可达这个结论达成共识之后，它们会在内部 “选举” 出⼀个领导节点来完成⾃动故障转移的⼯作，同时将这个变化实时通知给 Redis 应⽤⽅。整个过程是完全⾃动的，不需要⼈⼯介⼊。

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

② 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商，达成多数认同主节点故障的共识。这步主要是防⽌该情况：出故障的不是主节点，⽽是发现故障的哨兵节点，该情况经常发⽣于哨兵节点的⽹络出现故障的场景下。
(也就是说多个哨兵认为主节点故障，主节点才会被认为故障)

③ 哨兵节点之间使⽤ Raft 算法选举出⼀个新的主节点，由该节点负责后续的故障转移⼯作。
(通过投票的形式选出新的主节点，投票的依据是Raft 算法，Raft 算法可反应的节点的工作性能)
(为了避免平票的可能发生，哨兵节点集合中的哨兵节点数目通常为奇数个）

④ 哨兵领导者开始执⾏故障转移：从节点中选择⼀个作为新主节点；让其他从节点同步新主节点；通知应⽤层转移到新主节点。

选举具体流程

1. 多个哨兵同时确认主节点客观故障

2. 确认主节点故障后要选出一个新的主节点，这个⼯作不需要所有的哨兵都参与。只需要选出个代表哨兵 (称为 leader), 由 leader 负责进⾏ slave 升级到 master 的提拔过程。每个哨兵根据算法（该算法反应节点性能）推荐一个自认为合适从节点作为新的主节点，其他所有节点对所有被推荐的节点进行投票，有被推荐的节点票数过一半则结束其他所有的投票，直接得出新的主节点。

理解注意事项

• 哨兵节点不能只有⼀个. 否则哨兵节点挂了也会影响系统可⽤性.
• 哨兵节点最好是奇数个. ⽅便选举 leader, 得票更容易超过半数.
• 哨兵节点不负责存储数据. 仍然是 redis 主从节点负责存储.
• 哨兵 + 主从复制解决的问题是 “提⾼可⽤性”, 不能解决 “数据极端情况下写丢失” 的问题.
• 哨兵 + 主从复制不能提⾼数据的存储容量. 当我们需要存的数据接近或者超过机器的物理内存, 这样的结构就难以胜任了.