Redis哨兵模式

---

---

1. 前言

前面我们已经了解了Redis Replication机制, 该机制可以做到在master宕机时, 可以由slave节点来代替。然而, 将slave节点切换为master需要人为干预。此外, 还会造成一段时间内服务器处于不可用状态，因此主从模式的可用性较低，不适用于线上生产环境。

可用性标准如下:

可用性级别	系统可用性%	宕机时间/年	宕机时间/月	宕机时间/周	宕机时间/天
不可用	90%	36.5 天	73 小时	16.8 小时	144 分钟
基本可用	99%	87.6 小时	7.3 小时	1.68 小时	14.4 分钟
较高可用	99.9%	8.76 小时	43.8 分钟	10.1 分钟	1.44 分钟
高可用	99.99%	52.56 分钟	4.38 分钟	1.01 秒	8.64 秒
极高可用	99.999%	5.26 分钟	26.28 秒	6.06 秒	0.86 秒

本篇我们聊聊Redis官方推荐的一种解决方案，Redis Sentinel。Sentinel通过监控的方式获取主机的工作状态是否正常。当主机发生故障时,Sentinel会自动进行Failover（即故障转移）并将其监控的从机提升为主服务器（master）,从而保证系统的高可用性。

2. 高可用基本原理

1. 冗余性原理: 当某个组件故障时切换到备用组件;
2. 负载均衡原理: 将压力分摊在多个组件上, 降低单个组件故障风险;
3. 监控原理: 实时监控组件运转状态, 及时发现故障和问题, 避免问题扩大;
4. 自动化原理: 通过自动化手段进行故障的处理和恢复, 减少人为干预导致的问题;
5. 弹性原理: 通过弹性架构实现系统的扩缩容, 兼顾成本和大流量下的任务处理;
   

3. 单哨兵模式

3.1 拓扑结构

3.2 Failover过程

1. 哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令，并通过 Redis 节点的回复来判断其运行状态;
2. 当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台将机器，并其提升为主服务器;
3. 使用Redis发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器;

3.3 存在问题

在实际生产情况中，哨兵是集群的高可用的保障，为避免 一个哨兵节点 发生意外，它一般是由 3～5 个节点组成，并且各个哨兵之间还会互相进行监控，这样就算挂了个别节点，该集群仍然可以正常运转。

4. 多哨兵模式

4.1 拓扑结构

4.2 Failover过程

1. 主观下线
   主观下线，适用于主服务器和从服务器。如果在规定的时间内(配置参数：down-after-milliseconds),某个sentinel节点没有收到目标服务器的有效回复，则判定该服务器为“主观下线”。比如Sentinel1向主服务发送了PING命令，在规定时间内没收到主服务器PONG回复，则Sentinel1判定主服务器为“主观下线”，这个时候系统并不会马上进行failover过程，因为仅仅是Sentinel1主观的认为主服务器不可用。

2. 客观下线
   客观下线，只适用于主服务器。Sentinel1发现主服务器出现了故障，它会通过相应的命令，询问其它Sentinel节点对主服务器的状态判断。如果超过半数以上的Sentinel节点认为主服务器down掉，则Sentinel1节点判定主服务为“客观下线”。这里就下线这个状态达成共识。

3. 投票选举
   所有Sentinel节点会按照谁发现谁去处理的原则，通过投票选举发现节点为领头节点去做Failover（故障转移）操作。领头节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器，然后通过发布订阅功能通知其余的从节点（slave）更改配置文件，跟随新上任的主服务器（master）。至此就完成了主从切换的操作。

5. 客户端操作

1. Sentinel 负责监控主从节点的“健康”状态。当主节点挂掉时，自动选择一个最优的从节点切换为主节点。
2. 客户端来连接 Redis 集群时，会首先连接 Sentinel，通过 Sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。
3. 当主节点发生故障时，客户端会重新向 Sentinel 要地址，Sentinel 会将最新的主节点地址告诉客户端。因此应用程序无需重启即可自动完成主从节点切换。

6. 小结

本文介绍Redis主从模式的问题和官方推荐的解决方案之一–哨兵模式, 并介绍了哨兵模式下的典型拓补结构和Failover过程, 希望能帮助你对Redis高可用和Failover有更进一步的认识, 感谢您的阅读。