Redis哨兵

10.1 介绍

• 哨兵巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务，俗称无人值守运维

10.2 哨兵的作用

• 监控redis运行状态，包括master和slave
• 当master down机，能自动将slave切换成新master

10.3 哨兵的四个功能

• 主从监控
  监控主从redis库运行是否正常
• 消息通知
  哨兵可以将故障转移的结果发送到客户端
• 故障转移
  如果master异常，则会进行主从切换，将其中一个slave作为新master
• 配置中心
  客户端通过连接哨兵来获得当前Redis服务的主节点地址

10.4 基本操作

Redis Sentinel架构

• 3个哨兵
  • 自动监控和维护集群，不存放数据，只是监控
• 1主2从
  • 用于数据读取和存放

步骤

注意： 由于虚拟机运行内存问题，将哨兵放在一台机器上，真正部署项目时要分开

1. 在 /myredis 目录新建或者拷贝 sentinel.conf

2. 先看看redis解压目录下默认的sentinel.conf文件的内容

3. 哨兵sentinel文件参数（先导）

• bind 服务监听地址，用于客户端连接
• daemonize 是否以后台daemon方式运行
• protected-mode 安全保护模式
• port 端口
• logfile 日志文件路径
• pidfile pid日志路径
• dir 工作目录
• sentiel monitor
  • 设置要监控的master
  • quorm 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
    • 网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
• sentiel auth-pass 通过密码连接master
• 其他
• 

4. 哨兵sentinel文件配置

• sentinel26379.conf

• 

• sentinel26380.conf

• 

• sentinel26381.conf

• 

5. 启动一主二从

• 架构说明

• 

• 按照上章配置的一主二从基础上，需要对主机redis6379.conf进行更改

• 

• 6379后续可能会变成从机，需要设置访问新主机的密码， 请设置masterauth项访问密码为111111

• 启动一主二从

  6379.conf
  	redis-server /myredis/redis6379.conf 
  	redis-cli -a 111111
  
  6380.conf
  	redis-server /myredis/redis6380.conf 
  	redis-cli -a 111111 -p 6380
  
  6381.conf
  	redis-server /myredis/redis6381.conf 
      redis-cli -a 111111 -p 6381
  

6. 启动哨兵

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

哨兵日志

7. 关闭6379服务器，模仿master挂了

• 两台从机的数据不会丢失
• 会从其他两台从机选出一个新的master
• 挂掉的master重连回来，直接变成新master的从机

注意：

• 本文中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf会在运行中进行动态更改
• 在master-slave切换中，会自动多一行slaveof的配置，sentinel.conf的监控目标会随之调换

常见问题

broken pipe

哨兵运行流程和选举原理

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于接替原master的工作，主从配置中其他redis服务器自动指向新的master同步数据。一般建议sentinel采用奇数台，防止某一台sentinel无法连接到master导致误切换、

SDOWN 主观下线

• SDOWN 是单个sentinel 自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
• sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度

ODWON 客观下线

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

选举出领导者哨兵

• 当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点并由该领导者节点进行failover（故障迁移）

选取leader哨兵

• Raft算法 选出leader哨兵

由领导者节点开始推动故障切换并选出一个新master

• 新主登基
  • 某个slave 备选成为新 master
  • 在剩余slave节点健康前提下

    • 

    • redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高) redis7 默认是100

    • 复制偏移量位置offset最大的从节点 假如有十条数据，正常是写一条复制一条，如果一个从机宕机之后，再从连 需要复制跟进主机，这两个从机就产生了差距

    • 最小Run ID 的从节点 根据字典顺序 ASCII码

• 群臣俯首
  • 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
  • Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
  • Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave
• 旧主拜服
  • 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点
  • Sentinel leader会让原来的master降级为slave并恢复工作
• 以上的failover都是sentinel自己独立完成，完全无需人工干预

10.5 使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数个
• 各个哨兵节点的配置应该一致
• 如果哨兵节点部署在Docker等容器里，要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据零丢失