哨兵机制Sentinel

哨兵机制Sentinel

主从复制：读写分离，多读少写，单点故障（主机宕机，从机不能自动切换），负载压力（客户端请求，并发），数据集中存储（主从数据是完全一致）

哨兵机制：主从故障转移，从切换为主，数据集中存储（主从数据是完全一致）

1 哨兵机制

哨兵机制的出现是为了解决主从复制的缺点，不能自动实现故障转移

哨兵模式是Redis的高可用解决方案之一，它旨在提供自动故障转移和故障检测的功能。在传统的Redis部署中，单个Redis节点可能成为单点故障，一旦该节点宕机，整个系统将不可用。为了解决这个问题，哨兵模式引入了多个Redis节点，其中一个节点被选为主节点，其他节点作为从节点。

2 哨兵机制作用

• 监控

  • 不断的检查 master 和 slave 是否正常运行。

  • master 存活检测、master与slave运行情况检测。

• 通知（提醒）

  • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。

• 自动故障转移

  • 断开 master 与 slave 连接，选取一个 slave 作为 master，将其他 slave 连接到新的 master，并告知客户端新的服务器地址。

3 哨兵模式场景应用

• 高可用性要求较高的场景：通过自动故障转移，确保服务的持续可用。

• 数据备份和容灾恢复：在主从复制的基础上，提供自动故障转移功能。

哨兵模式在主从复制模式的基础上实现了自动故障转移，提高了系统的高可用性。然而，它仍然无法实现数据分片。如果需要实现数据分片和负载均衡，可以考虑使用Cluster模式。

4 sentinel高可用

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

4.1 哨兵的定时监控任务

任务1：

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：

每个哨兵节点每隔2秒会向redis数据节点的指定频道(主节点)上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

任务3：

每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

主观下线和客观下线

主观下线是指一个哨兵节点认为主节点不可用，但它并不确定其他哨兵节点是否也认为主节点不可用。当一个哨兵节点在一定时间(配置参数：down-after-milliseconds)内无法与主节点通信（比如发送PING命令没有收到响应），它会认为主节点下线。但在这个阶段，其他哨兵节点并不知道这个节点的状态，仅有一个哨兵主观地认为主节点宕机。

客观下线是指一个主节点被多数哨兵节点认定为不可用。当一个哨兵节点认为主节点宕机后，它会向其他哨兵节点询问对主节点的状态，并请求其他哨兵进行确认。当超过quorum（选举）个数（大多数至少需要半数加1）的哨兵节点都认为主节点不可用，那么主节点就会被判定为客观下线。客观下线意味着主节点的状态在整个哨兵集群中得到了确认。

主观下线和客观下线的引入是为了避免误判。如果只有一个哨兵节点认为主节点下线，那么很可能是网络抖动等原因导致的，此时并不应该进行故障转移。只有多数的哨兵节点都确认主节点下线，才能确保故障转移的正确性，保证整个集群的稳定性。

哨兵模式使用主观下线和客观下线状态的组合来实现可靠的主节点故障检测和故障转移，从而确保Redis集群的高可用性。

4.2 领导者哨兵选举流程

在多Sentinel模式下，各节点会相互监控主从节点的健康状态。当主节点发生故障时，首先由Sentinel节点之间基于Raft算法进行投票选举，按照谁发现主节点故障谁去处理的原则，选举出一个领头Sentinel节点（Leader Sentinel）。这个领头Sentinel节点负责进行故障转移操作。

• 每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；

• 当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

• 如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

4.3 故障转移机制

故障转移过程中，领头Sentinel节点会根据一定的规则在所有从节点中选择一个最优的从节点作为新的主节点（Master）。一般会选择复制偏移量最大且优先级较高的从节点作为新的主节点。然后，领头Sentinel节点通过发布订阅功能，通知其他从节点更改配置文件，将它们的连接从原来的主节点转移到新的主节点上。

1. 由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

1. 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

1. 故障转移详细流程-确认主节点

   • 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

   • 选择salve-priority从节点优先级最高（redis.conf）的

   • 选择复制偏移量最大，指复制最完整的从节点

2. 由Sentinel3领导者节点执行故障转移，但是自动执行

   • 将slave-1脱离原从节点，升级主节点

   • 将从节点slave-2指向新的主节点

   • 通知客户端主节点已更换

   • 将原主节点（oldMaster）变成从节点，指向新的主节点

1. 故障转移后的redis sentinel的拓扑结构图

5 部署哨兵

以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

5.1 准备

先搭好一主两从redis的主从复制

5.2 配置文件

配置多个哨兵节点sentinel.conf，三个配置除端口外，其它一样。

复制解压目录下的sentinel.conf到安装目录下，修改sentinel.conf配置文件，几个哨兵，几个配置文件：

保留一个哨兵不做后端启动

# 端口号
port 26379
​
# 后端启动
daemonize no
​
# 不受保护
protected-mode no 
​
pidfile "/var/run/redis-26379.pid"
​
logfile "/opt/redislog/26379.log"
​
# 监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
sentinel monitor mymaster 192.168.190.128 6370 2
​
# 主机认证密码
sentinel auth-pass mymaster 123
​
# 故障转移时最多可以有2从节点同时对新主节点进行数据同步
sentinel config-epoch mymaster 2 
​
sentinel leader-epoch mymaster 2
​
# 故障转移超时时间180s
# a.如果转移超时失败，下次转移时时间为之前的2倍；
# b.从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过180S时，则故障转移失败
# c.从节点复制新主节点时间超过180S转移失败
sentinel failover-timeout mymasterA 3000
​
# sentinel节点定期向主节点ping命令，当超过了300S时间后没有回复，可能就认定为此主节点出现故障
sentinel down-after-milliseconds mymasterA 3000
​
# 故障转移后，1代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销
sentinel parallel-syncs mymasterA 1 

5.3 启动redis服务

启动主从服务，先启动主再启动从

# 主机
./redis-server conf/6370.conf 
​
# 从机
./redis-server conf/6380.conf 
./redis-server conf/6390.conf     

5.4 启动哨兵节点

启动哨兵节点，多个都启动

./redis-sentinel conf/26370.conf
./redis-sentinel conf/26380.conf
./redis-sentinel conf/26390.conf

到此服务全部启动完毕

5.5 测试哨兵机制

连接到6370的redis的服务，可看到6370就是主节点，他有6380和6390两个从节点

杀掉6370的redis服务

kill -9 6370pid值

可以看到杀掉6370以后6390变为了主节点，6380变为了6390的从节点

重新启动6370以后变为6380的从节点

6 部署建议

• sentinel节点应部署在多台物理机（线上环境）

• 至少三个且奇数个sentinel节点

• 3个sentinel可同时监控一个主节点或多个主节点

• 监听N个主节点较多时，如果sentinel出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的网络连接，一般线上还是， 3个sentinel监听一个主节点