为什么需要 Redis 哨兵？

在说哨兵之前，我们先说下主从复制，Redis 的主从复制模式，一旦主节点出现故障无法提供服务，需要人工介入手工将从节点调整为主节点，同时应用端还需要修改新的主节点地址，这种故障转移的方式对于很多应用场景是不能容忍的。正式由于这个问题，Redis 提供了 Sentinel(哨兵) 架构来解决这个问题。

Redis Sentinel 是一个分布式的架构，它本身也是一个独立的 Redis 节点，只不过它不存储数据，只支持部分命令，它能够自动完成故障发现和故障转移，并通知应用方，从而实现高可用。Redis Sentinel 包含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其他 Sentinel 节点进行监控，当发现节点异常时，会对节点做下线标识，如果被标识的是主节点，此时会与其他Sentinel 节点进行协商，当大多数Sentinel 节点都人为主节点不可达时候，会发起选举，选出一个 Sentinel 节点来完成自动故障转移的工作，同时会将这个变化通知给 Redis 的应用方。这个过程是完全自动化的，无需人工干预。Sentinel 主要提供以下几个功能：

• 监控：定期检测Redis 数据节点、其他 Sentinel 节点是否可达。
• 通知：将故障转移的结果通知给应用方。
• 主节点故障转移：实现从节点晋升为主节点，并维护后续正确的主从关系
• 配置提供者：客户端在初始化的时候连接 Sentinel 节点集合，从中获取主节点信息。

多个 Sentinel 节点来共同判断故障，可以有效防止误判，同时如果个别 Sentinel 节点不可用，整个 Sentinel 节点集合依然是高可用的。

 部署说明3 个 Sentinel 节点 、1 个主节点 、2 个从节点。部署数据节点

部署 sentinel 节点sentinel 默认 的端口是 26379，这里我们创建三个 sentinel 节点，端口分别是 26379、26380、26381。

部署 sentinel 节点sentinel 默认 的端口是 26379，这里我们创建三个 sentinel 节点，端口分别是 26379、26380、26381。

配置说明：

sentinel monitor

• port 指定 sentinel 节点的端口

• sentinel monitor master-name 是给要监控的节点起一个名字，ip 和 port 表示监控一个主节点，quorum 表示要判断主节点最终不可达所需要的票数。同时这个参数还与选举领导者有关，至少需要max(quorum,num/2+1)个节点参与选举，才能选出领导者 sentinel，从而完成故障转移。比如总共有 5 个 sentinel 节点，quorum =4 ，name 至少需要 4 个sentinel 节点才可以进行领导者的选举。

当所有节点启动时候，配置文件会发生变化，包括：

• sentinel 自动发信了从节点以及其他 sentinel 节点。
• 去掉里面默认配置，例如 parallel-sync failover-timeout 参数。
• 添加了配置 纪元相关参数。

sentinel down-after-milliseconds配置

每个 sentinel 节点都要定期发送 ping 命令来判断 redis 数据节点和其他 sentinel 节点是否可达，如果超过了down-after-milliseconds 配置的时间且没有有效回复，则判断节点不可达。times 单位是毫秒。down-after-milliseconds虽然以为参数，但实际上对 Sentinel节点、主节点、从节点的失败判定同时有效。sentinel parallel-syncs配置：

当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节 点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点， 但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和 磁盘IO开销。

sentinel failover-timeout配置：

failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段:

• 选出合适从节点；
• 晋升选出的从节点为主节点；
• 命令其余从节点复制新的主节点；
• 等待原主节点恢复后命令它去复制新的主节点。

failover-timeout的作用具体体现在四个方面：

• 如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主 节点做故障转移的起始时间是failover-timeout的2倍；

• 在晋升选出的从节点为主节点阶段时，如果Sentinel节点向a)阶段选出来的从节点执行slaveof no one一直失败(例如该从节点此时出现故障)，当此过程超过 failover-timeout时，则故障转移失败；

• 在晋升选出的从节点为主节点阶段如果执行成功，Sentinel节点还会执行info命令来确认a) 阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failover- timeout时，则故障转移失败；

• 如果命令其余从节点复制新的主节点阶段执行时间超过了failover-timeout(不包含复制时间)， 则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从 节点去同步最新的主节点。

部署注意事项

• sentinel 节点不应该部署在同一台物理机上；
• 至少要部署三个以上的奇数 sentinel 节点；
• 选一套还是多套 sentinel，如果选一套可以一定程度降低维护成本，但是如果 sentinel 节点出现异常，可能会多多个 redis 数据节点造成影响，如果是多套，会造成资源浪费，但是每套 sentinel 都彼此隔离。

文章参考自公众号阿文CSDN