Redis哨兵模式的学习(三)

一、Redis哨兵(sentinel)

1.1、Redis哨兵是什么？

在主从复制的基础上，添加一个哨兵角色，用于巡查监控后台master服务器是否故障，如果故障那么根据投票数自动将某一个slave服务器变为master服务器，继续对外提供服务。

1.2、具体功能：

• 主从监控（Monitoring）：Sentinel 会不断地检查你的master和slave是否运作正常。
• 消息通知：哨兵可以将故障转移的结果发送给客户端。
• 故障转移：如果master故障，则会进行主从切换，将其中一个slave作为新的master
• 配置中心：客户端通过连接哨兵来获取当前redis服务器的主节点地址

二、具体操作

2.1、搭建哨兵

因为奇数好投票，所以在之前的一主一仆的架构上，再加三个哨兵节点。

• 1. 将sentinel.conf复制进自己的redis目录下，注意是6379master的机器上
• 2. 修改sentinel.conf文件
  • sentinel monitor
    • master-name：自定义redis主机名
    • ip地址：master主机的ip地址
    • redis-port：master的端口号
    • quorum: 客观投票数,这里设置为2，即哨兵集群中至少有2个哨兵认为master宕机，则认为是宕机------客观下线
  • sentinel auth-pass #master主机设置有密码，这里也需要配置密码，才能访问master主机
  • sentinel down-after-milliseconds # 主观下线，如果master主机在milliseconds时间内无响应，则哨兵主动认为master宕机，同上面的客观下线（投票）有一定区别。
  • sentinel parallel-syncs # 指旧master故障后，最多可以允许多少个slave同时对新的master进行数据复制-----看需要
  • sentinel failover-timeout # 指在某个sentinel认为master宕机后，重新选择一台新的master的整个流程的超时时间，如果超时，则转移失败------------看需要
  • sentinel notification-script # 当某一事件发生后，需要执行的脚本------看需要
  • sentinel client-reconfig-script #客户端重新配置主节点参数脚本---------看需要
  • redis6379.conf中需要配置masterauth，可能某天6379从主机变为从机。

2.2、 启动哨兵

设置三个哨兵，并且sentinel默认端口号是26379，所以将sentinel.conf文件分别复制3份，并且修改端口号，三个哨兵的端口号分别是26379、26380、26381

• 启动命令

redis-sentinel sentinel26379.conf
# 或者
redis-server sentinel26379.conf --sentinel

• 查看哨兵26379日志
  

• 再次查看sentinel26379.conf文件，发现新增了哨兵信息
  

2.3、模拟master主机故障

• 主动关闭6379主机，查看哨兵日志，直接shutdown即可。
  

现在查看从机6380，发现连接不上，还在等待，难道哨兵没起作用？

• 再等一会，会发现6380变成了master主机。
  

• 查看哨兵日志
  

2.4、6379主机恢复

• 恢复6379主机，会发现6380主机变成了slave
  

• 查看redis6379.conf文件，发现添加新主机节点信息
  

• 查看redis6380.conf文件，之前的replicaof信息被删除
  
  

• 查看哨兵配置文件
  

2.3、小结

• 1. 配置文件的内容在运行期间，会被sentinel进行动态修改
• 2. master-slave切换过程中，redis_master.conf和redis_slave.conf以及sentinel.conf都会发生改变，即redis_master.conf中会添加新的slave信息，redis_slave.conf中会删除replicaof信息，sentinel.conf中会更改监控的目标。

三、哨兵的运行流程

3.1、主观下线SDOWN（subjective down）

单个sentinel对服务器做出下线判断，即主观下线。依据是根据配置文件中的sentinel down-after-milliseconds来判断,默认是30S，如果在30s内，哨兵没受到master服务器的回复，则认为master宕机。

3.2、客观下线ODOWN（objective down）

odown需要一定数量的sentinel，多个sentinel达成一致意见，认为该master宕机，才算客观下线。

3.3、多个哨兵选出新的leader

通过raft算法，选出leader哨兵。

3.4、哨兵leader给出意见，选择新的master主机

其中一个哨兵对master进行主观下线--------->多个哨兵对master进行客观下线--------->选出leader哨兵，由leader哨兵选择新的master主机---->其他哨兵将旧的slave变为新的slave主机。

3.5、如何选出新的master主机

• 1. 新主登基，通过如下规则：
  • 过滤掉：不健康的slave节点
  • 先看优先级，优先级高的优先，配置文件中replica-priority(数字越小，优先级越高)。
  • 优先级相同，再看复制偏移量，偏移量大的优先，代表数据越完整。
  • 偏移量相同，再看运行ID，运行ID小的优先。
• 2. 群臣俯首，一朝天子一朝臣，换个码头重新拜：
  • sentinel leader会对选出来新master执行slaveof no one命令，让其成为master。
  • sentinel leader会向其他slave从机发送slaveof命令,让其他旧的slave变为新的master的从机.
• 3. 旧主拜服，老master回来也得臣服：
  • sentinel leader会让旧的master主机进行降级，会变为slave节点。

四、哨兵的使用建议：

• 1. 哨兵数量应该是多个，哨兵本身应该集群，保证高可用
• 2. 哨兵数量应该是奇数，保证投票的有效性
• 3. 各个哨兵的硬件配置应该是一样的
• 4. 如果哨兵配置再docker等容器中，要注意端口的正确映射
• 5. 哨兵集群 + 主从复制，并不能保证数据零丢失。