> 文章列表 > 【Redis7】 Redis7 哨兵(重点:哨兵运行流程和选举原理)

【Redis7】 Redis7 哨兵(重点:哨兵运行流程和选举原理)

【Redis7】 Redis7 哨兵(重点:哨兵运行流程和选举原理)

 【大家好,我是爱干饭的猿,本文重点介绍Redis7 哨兵,重点:哨兵运行流程和选举原理。

后续会继续分享Redis7和其他重要知识点总结,如果喜欢这篇文章,点个赞👍,关注一下吧】

上一篇文章:《【Redis7】Redis7 主从复制(重点:主从复制原理)》


目录

🥞1. 哨兵

1.1 概述

1.2 作用

1.3  Redis Sentinel架构

1.4 操作步骤

1.5 哨兵运行流程和选举原理

1.6 使用建议


🥞1. 哨兵

1.1 概述

吹哨人巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务

1.2 作用

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

1.3  Redis Sentinel架构

 Redis Sentinel架构如下图:

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

1.4 操作步骤

  1. 在 /myredis 目录新建或者拷贝 sentinel.conf
  2. 先看看redis解压目录下默认的sentinel.conf文件的内容
  3. 哨兵sentinel文件参数(先导)
    1. bind 服务监听地址,用于客户端连接
    2. daemonize 是否以后台daemon方式运行
    3. protected-mode 安全保护模式
    4. port 端口
    5. logfile 日志文件路径
    6. pidfile pid日志路径
    7. dir 工作目录
    8. sentinel monitor <master> <redis-port> <quorum>
       
      1. 设置要监控的master
      2. quorm 表示最少有几个哨兵认可客观下线,同意故障迁移的法定票数

       

    9. sentinel auth-pass <master-name> <password> 通过密码连接master
  4. 哨兵sentinel文件配置
    1. sentinel26381.conf
    2. sentinel26380.conf
    3. sentinel26379.conf
  5. 先启动一主二从

    1. 按照上章配置的一主二从基础上,需要对主机redis6379.conf进行更改
      1. 6379后续可能会变成从机,需要设置访问新主机的密码, 请设置masterauth项访问密码为123456

    2. 启动一主二从

      1. 6379.confredis-server /myredis/redis6379.conf redis-cli -a 1234566380.confredis-server /myredis/redis6380.conf redis-cli -a 123456 -p 63806381.confredis-server /myredis/redis6381.conf redis-cli -a 123456 -p 6381
  6. 启动哨兵

    1. redis-sentinel sentinel26379.conf --sentinel
      redis-sentinel sentinel26380.conf --sentinel
      redis-sentinel sentinel26381.conf --sentinel
  7. 关闭6379服务器,模仿master挂了

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

结论:

  • 本文中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf会在运行中进行动态更改
  • 在master-slave切换中,会自动多一行slaveof的配置

1.5 哨兵运行流程和选举原理

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

运行流程,故障切换:

  1. SDOWN主观下线
    1. SDOWN 是单个sentinel 自己主观上检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就达到了SDOWN的条件
    2. sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度
  2. ODOWN客观下线
    1. ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕机
  3. 选举出领导者哨兵
    1. 当主节点被判断客观下线以后,各个哨兵节点会进行协商,县选举出一个领导者哨兵节点并由该领导者节点进行failover(故障迁移)
    2. Raft算法 选出领导者节点
  4. 由领导者节点开始推动故障切换并选出一个新master
    1. 新主登基
      1. 某个slave 备选成为新 master
      2. 选出新master的规则,剩余slave节点健康前提下
        1. redis.conf文件中,优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)
        2. 复制偏移位置offset最大的从节点(log中记录最多条数的)
        3. 最小Run ID的从节点,也就是字典顺序,ASCII码
    2. 群臣俯首
      1. 一朝天子一朝臣,重新认老大
      2. 执行slaveof no one命令让选出来的从节点成为新的主节点,并通过slaveof命令让其他节点成为其从节点
      3. Sentinel leader会对选举出的新master执行slaveof no one操作,将其提升为master节点
      4. Sentinel leader向其它slave发送命令,让剩余的slave成为新的master节点的slave
    3. 旧主拜服
      1. 老master回来也得怂
      2. 将之前已下线的老master设置为新选出的新master的从节点,当老master重新上线后,它会成为新master的从节点
      3. Sentinel leader会让原来的master降级为slave并恢复正常工作。
  5. 以上的failover都是sentinel自己独立完成,完全无需人工干预

1.6 使用建议

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

分享到此,感谢大家观看!!!

如果你喜欢这篇文章,请点赞关注吧,或者如果你对文章有什么困惑,可以私信我。

🏓🏓🏓