Redis之哨兵模式解读

目录

基本介绍

单哨兵模式

多哨兵模式

哨兵的本质

配置哨兵模式

故障恢复原理

哨兵监控工作流程

哨兵模式缺点 

---

基本介绍

当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。 

Redis Sentinel（哨兵）是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程, 这些进程使用 gossip协议(基于流行病传播方式的节点或者进程之间信息交换的协议，在分布式系统中被广泛使用) 来接收关于Master是否下线的信息,并使用投票协议(agreement protocols) 来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master (raft算法)

单哨兵模式

• 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器
• 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机
• 然而一个哨兵进程对Redis服务器进行监控,可能会出现问题(比如哨兵死了),为此,我们可以使用多个哨兵进行监控。 各个哨兵之间还会进行监控,这样就形成了多哨兵模式

多哨兵模式

• 假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。
• 当后面的哨兵也检测到主服务器不可用,并且数量达到一 定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover[故障转移]操作。
• 切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线

主观下线（sdown）

1、sdown（主观不可用）是单个哨兵自己主观上检测到的关于master的状态，从哨兵的角度来看，如果发送PING心跳后，在一定的时间内没有得到合法的回复，就达到了sdown的条件。

2、哨兵配置文件中down-after-milliseconds设置了判断主观下线的回复时间。

客观下线需要一定数量的哨兵，多个哨兵达成一致意见才能认为一个master客观上已经宕机了。

哨兵的本质

哨兵其实也是一台 Redis 服务器，只是不对外提供任何服务。稍后我们在配置时，你会看到实际上哨兵只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵。 

配置哨兵模式

这里只对关键点进行概述，具体可查阅其他资料

自定义目录下新建sentinel.conf文件,名字绝不能错

# sentinel monitor 被监控的名称 host port 1
# 其中mymaster为监控对象起的服务器名称,1 为至少有多少个哨兵同意迁移的数量。
sentinel monitor mymaster 127.0.0.1 6379 1

启动哨兵

# redis-sentinel  sentinel.conf 

故障恢复原理

• 新主登机:从下线的主服务器的所有从服务里面挑选一个从服务,将其转成主服务,选择条件依次是:选择优先级靠前的(优先级在redis.conf中默认：slave-priority 100,值越小优先级越高)选择偏移量最大的(是指获得原主机数据最全的)
• 群仆俯首:挑选出新的主服务之后sentinel向原主服务的从服务发送slaveof新主服务的命令,复制新master
• 旧主俯首:当已下线的服务重新上线时,sentinel会向其发送slaveof命令,让其成为新主的从
   

哨兵监控工作流程

• 哨兵启动后根据配置向master发送info指令，获取并保存所有哨兵状态，主节点和从节点信息。
• 主节点master会记录所有从节点和与它连接的哨兵实例的信息。
• 哨兵会根据在主节点拿到的从节点信息，给对应的从节点建立连接后发送info指令
• 之后哨兵2来了也是给master发送info指令，同时拿到了从节点和哨兵的实例信息
• 此时哨兵2也会保存跟哨兵1一样的信息，只不过它保存的哨兵信息是2个
• 这个时候为了每个哨兵的信息都一致它们之间建立了一个发布订阅，互相发送 ping 命令 保证信息长期对称
• 当再来一个哨兵3时，也会做同样的事情，给主节点和从节点发送info，并且跟哨兵1和哨兵2建立连接

哨兵模式缺点 

哨兵模式的缺点包括：

1. 延迟问题： 由于哨兵需要进行频繁的状态检查和转移操作，可能会对系统带来一定的延迟。
2. 复杂性增加：引入哨兵模式后，需要对集群进行额外的配置和管理，复杂度会增加。