Redis学习14-认识哨兵机制

Redis哨兵(Sentinel)

哨兵解决了什么问题

主从复制的问题

Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：

第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上来，并且保证数据尽量不丢失（主从复制表现为最终一致性）。

第二，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。

但是主从复制模式遗留下几个问题：

1. 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。

2. 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。

第一个问题是高可用问题，即 Redis 哨兵主要解决的问题。

第二个问题是属于存储分布式的问题， Redis 集群解决的问题。

人工恢复主节点故障

Redis 主从复制模式下，主节点故障后需要进行的人工工作是比较繁琐的。

1）运维人员通过监控系统，发现 Redis 主节点故障宕机。
2）运维人员从所有节点中，选择一个（此处选择了 slave 1）执行 slaveof no one，使其作为新的主节点。
3）运维人员让剩余从节点（此处为 slave 2）执行 slaveof {newMasterIp} {newMasterPort} 从新主节点开始数据同步。
4）更新应用方连接的主节点信息到 {newMasterIp} {newMasterPort}。
5）如果原来的主节点恢复，执行 slaveof {newMasterIp} {newMasterPort} 让其成为一个从节点。
上述过程可以看到基本需要人工介入，无法被认为架构是高可用的。而这就是 Redis Sentinel 所要做的。

哨兵自动恢复主节点故障

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

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

故障转移流程

Redis Sentinel 相比于主从复制模式是多了若干（建议保持奇数）Sentinel 节点用于实现监控数据节点，哨兵节点会定期监控所有节点（包含数据节点和其他哨兵节点）。针对主节点故障的情况，故障转移流程大致如下：

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

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

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

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

基本概念

名词	逻辑结构	物理结构
主节点	Redis 主服务	一个独立的 redis-server 进程
从节点	Redis 从服务	一个独立的 redis-server 进程
Redis 数据节点	主从节点	主节点和从节点的进程
哨兵节点	监控 Redis 数据节点的节点	一个独立的 redis-sentinel 进程
哨兵节点集合	若干哨兵节点的抽象组合	若干 redis-sentinel 进程
Redis 哨兵（Sentinel）	Redis 提供的高可用方案	哨兵节点集合 和 Redis 主从节点
应用方	泛指一个多多个客户端	一个或多个连接 Redis 的进程