redis并无提供自动master选举功能,redis
- 而是须要借助一个哨兵来进行监控
哨兵的做用就是监控Redis系统的运行情况,算法
- 它的功能包括两个
- 监控master和slave是否正常运行
- master出现故障时自动将slave数据库升级为master
- 哨兵是一个独立的进程,使用哨兵后的架构图
- 为了解决master选举问题,又引出了一个单点问题,
- 也就是哨兵的可用性如何解决
- 在一个一主多从的Redis系统中,
- 可使用多个哨兵进行监控任务以保证系统足够稳定
- 时哨兵不只会监控master和slave,
- 同时还会互相监控;
- 这种方式称为哨兵集群,
- 哨兵集群须要解决
- 故障发现、和master决策的协商机制问题
- 哨兵集群须要解决
- sentinel之间的相互感知
- sentinel节点之间会由于共同监视同一个master从而产生了关联,
- 一个新加入的sentinel节点须要和其余监视相同master节点的sentinel相互感知
- 须要相互感知的sentinel都向他们共同监视的master节点订阅
- channel:sentinel:hello
- 新加入的sentinel节点向这个channel发布一条消息,
- 包含本身自己的信息,
- 这样订阅了这个channel的sentinel就能够发现这个新的sentinel
- 新加入的sentinel和其余sentinel节点创建长链接
- 须要相互感知的sentinel都向他们共同监视的master节点订阅
- 一个新加入的sentinel节点须要和其余监视相同master节点的sentinel相互感知
- sentinel节点之间会由于共同监视同一个master从而产生了关联,
master的故障发现数据库
- sentinel节点会按期向master节点发送心跳包来判断存活状态,
- 一旦master节点没有正确响应,
- sentinel会把master设置为“主观不可用状态”,
- 而后它会把“主观不可用”发送给其余全部的sentinel节点去确认,
- 当确认的sentinel节点数大于>quorum时,
- 则会认为master是“客观不可用”,
- 接着就开始进入选举新的master流程;
- 那谁来决策选择哪一个节点做为maste呢?
- 这里用到了一致性算法Raft算法(该算法用于哨兵的Master选举)、它和Paxos算法相似,都是分布式一致性算法。
- redis的master选举的时候会考虑slave的一些信息:
- 跟master断开链接的时长
- slave优先级
- 复制offset
- run id
- redis的master选举的时候会考虑slave的一些信息:
- 可是它比Paxos算法要更容易理解;
- Raft和Paxos算法同样,也是基于投票算法,
- 只要保证过半数节点经过提议便可;
- 这里用到了一致性算法Raft算法(该算法用于哨兵的Master选举)、它和Paxos算法相似,都是分布式一致性算法。
- 那谁来决策选择哪一个节点做为maste呢?
配置实现服务器
- 在其中任意一台服务器上建立一个sentinel.conf文件,文件内容
- sentinel monitor name ip port quorum
- 其中name表示要监控的master的名字,这个名字是本身定义。
- ip和port表示master的ip和端口号。
- 最后一个1表示最低经过票数,
- 也就是说至少须要几个哨兵节点统一才能够,
- sentinel monitor mymaster 192.168.11.131 6379 1
- sentinel down-after-milliseconds mymaster 5000
- --表示若是5s内mymaster没响应,就认为SDOWN
- sentinel failover-timeout mymaster 15000
- --表示若是15秒后,mysater仍没活过来,
- 则启动failover,从剩下的slave中选一个升级为master
- sentinel monitor name ip port quorum
- 两种方式启动哨兵
- redis-sentinel sentinel.conf
- redis-server /path/to/sentinel.conf --sentinel
- 哨兵监控一个系统时,
- 只须要配置监控master便可,
- 哨兵会自动发现全部slave;
- 这时候,咱们把master关闭,等待指定时间后(默认是30秒),会自动进行切换
- +sdown表示哨兵主观认为master已经中止服务了,
- +odown表示哨兵客观认为master中止服务了。
- 接着哨兵开始进行故障恢复,
- 挑选一个slave升级为master
- +try-failover表示哨兵开始进行故障恢复
- +failover-end 表示哨兵完成故障恢复
- +slave表示列出新的master和slave服务器,
- 咱们仍然能够看到已经停掉的master,
- 哨兵并无清楚已中止的服务的实例,
- 这是由于已经中止的服务器有可能会在某个时间进行恢复,
- 恢复之后会以slave角色加入到整个集群中