redis并没有提供自动master选举功能，

  • 而是需要借助一个哨兵来进行监控

哨兵的作用就是监控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节点建立长连接

master的故障发现

  • sentinel节点会定期向master节点发送心跳包来判断存活状态，
  • 一旦master节点没有正确响应，
  • sentinel会把master设置为“主观不可用状态”，
  • 然后它会把“主观不可用”发送给其他所有的sentinel节点去确认，
  • 当确认的sentinel节点数大于>quorum时，
  • 则会认为master是“客观不可用”，
  • 接着就开始进入选举新的master流程；
  • 那谁来决策选择哪个节点作为maste呢？
  • 这里用到了一致性算法Raft算法、它和Paxos算法类似，都是分布式一致性算法。
  • 但是它比Paxos算法要更容易理解；
  • Raft和Paxos算法一样，也是基于投票算法，
  • 只要保证过半数节点通过提议即可;

配置实现

  • 在其中任意一台服务器上创建一个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
  • 两种方式启动哨兵
  • 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角色加入到整个集群中