redis 哨兵_Redis哨兵机制的原理介绍

php中文网最新课程

每日17点准时技术干货分享

本篇文章给大家带来的内容是介绍Redis的哨兵机制，让大家了解哨兵机制的原理和如何实现。有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。

概述

Redis的复制有一个缺点，当主机 Master 宕机以后，我们需要人工解决切换，比如使用slaveof no one 。实际上主从复制并没有实现，高可用，高可用侧重备份机器，利用集群中系统的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务。

主从复制的问题

一旦主节点宕机，写服务无法使用，就需要手动去切换，重新选取主节点，手动设置主从关系。

那么如何解决呢？如果我们有一个监控程序能够监控各个机器的状态及时作出调整，将手动的操作变成自动的。Sentinel的出现就是为了解决这个问题。

哨兵机制的原理及实现

Redis Sentinel

Redis Sentinel 是一个分布式架构，其中包含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，当它发现节点不可达时，会对节点做下线标识。

如果被标识的是主节点，它还会和其他 Sentinel 节点进行“协商”，当大多数 Sentinel 节点都认为主节点不可达时，它们会选举出一个 Sentinel 节点来完成自动故障转移的工作，同时会将这个变化实时通知给 Redis 应用方。

整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了 Redis 的高可用问题。

如图所示：

基本的故障转移流程

1)主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。

2)每个 Sentinel 节点通过定期监控发现主节点出现了故障

3)多个 Sentinel 节点对主节点的故障达成一致会选举出其中一个节点作为领导者负责故障转移。

4)Sentinel 领导者节点执行了故障转移，整个过程基本是跟我们手动调整一致的，只不过是自动化完成的。

5)故障转移后整个 Redis Sentinel 的结构,重新选举了新的主节点。

实例

使用docker创建如下redis容器

redis-sentinel1 172.10.0.9 22530 -> 22530 sentinel

redis-sentinel2 172.10.0.10 22531 -> 6379 sentinel

redis-sentinel3 172.10.0.11 22532 -> 6379 sentinel

redis-master2 172.10.0.5 6383 -> 6379 Master

redis-slave2 172.10.0.6 6384 -> 6379 Slave

redis-slave3 172.10.0.7 6385 -> 6379 Slave

配置

Sentinel 的核心配置

sentinel monitor mymaster 127.0.0.1 7000 2

监控的主节点的名字、IP 和端口，最后一个2的意思是有几台 Sentinel 发现有问题，就会发生故障转移，例如配置为2，代表至少有2个 Sentinel 节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为 Sentinel 节点的一半加1。

sentinel down-after-millseconds mymaster 30000

这个是超时的时间(单位为毫秒)。打个比方，当你去 ping 一个机器的时候，多长时间后仍 ping 不通，那么就认为它是有问题。

sentinel parallel-syncs mymaster 1

当 Sentinel 节点集合对主节点故障判定达成一致时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出 Sentinel 属于并发还是串行。1代表每次只能复制一个，可以减轻 Master 的压力。