Redis7之哨兵(九)

9.1介绍

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

  • 作用

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

  • 哨兵的四个功能

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

9.2 基本操作

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

    在这里插入图片描述

    • sentienl26381.conf
      在这里插入图片描述

  5. 先启动一主二从

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

      • 在这里插入图片描述

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

    • 启动一主二从

      • 6379.conf
	redis-server /myredis/redis6379.conf 
	redis-cli -a 123456

6380.conf
	redis-server /myredis/redis6380.conf 
	redis-cli -a 123456 -p 6380

6381.conf
	redis-server /myredis/redis6381.conf 
    redis-cli -a 123456 -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的配置
哨兵运行流程和选举原理

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

  • SDOWN主观下线

    • SDOWN 是单个sentinel 自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件

    • sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度

      在这里插入图片描述

  • ODOWN客观下线

    • ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机 在这里插入图片描述

  • 选举出领导者哨兵

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

    • Raft算法 选出领导者节点

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

    • 新主登基
      • 某个slave 备选成为新 master
    • 群臣俯首
      • 一朝天子一朝臣，重新认老大
    • 旧主拜服
      • 老master回来也得怂

  • 以上的failover都是sentinel自己独立完成，完全无需人工干预

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