基本介绍
当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。
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建立连接
哨兵模式缺点
哨兵模式的缺点包括：
- 延迟问题： 由于哨兵需要进行频繁的状态检查和转移操作，可能会对系统带来一定的延迟。
- 复杂性增加：引入哨兵模式后，需要对集群进行额外的配置和管理，复杂度会增加。
