Redis集群模式之哨兵模式工作原理

---

前言 - 单机Redis的风险与问题

如果Redis设计成单节点, 会有如下风险:

• 问题1: 机器故障
  1. 现象: 硬盘故障, 系统崩溃, 造成数据丢失, 很可能对业务造成灾难性打击
  2. 结论: 用户基本上会放弃使用Redis.
• 问题2: 容量瓶颈
  1. 现象: 内存不足, 从16G升级到64G, 从64G升级到128G, 无限升级内存. 原因是项目资金不够, 硬件条件跟不上.
  2. 结论: 用户放弃使用Redis.

结论就是, 为了避免单点Redis服务器故障, 准备多台服务器, 互相连通. 将数据复制多个副本保存在不同的服务器上, 连接在一起, 并保证数据是同步的. 即使有一台服务器宕机, 其他服务器依然可以继续提供服务, 实现Redis的高可用, 同事实现数据冗余备份.

上篇文章介绍了Redis的主从复制Redis主从复制工作原理就是一种解决办法, 但是主从复制也会面临主节点宕机, 无法写入数据的情况. 因此产生了哨兵模式的工作机制. 接下来我们详细介绍.

2. 哨兵模式

2.1 哨兵简介

哨兵(sentinel)是一个分布式系统, 用于对主从结构中的每台服务器进行监控, 当出现故障时通过投票机制选择新的master并将所有slave连接到新的master.

哨兵的作用

• 监控
  1. 不断的检查master和slave是否正常运行.
  2. master存活检测, master与slave运行情况检测.
• 通知(提醒)
  1. 当被监控的服务器出现问题时, 向其他(哨兵间, 客户端)发送通知.
• 自动故障转移
  1. 断开master与slave连接, 选取一个slave作为master, 将其他slave连接到新的master, 并告知客户端新的服务器地址.

注意: 哨兵也是多台redis服务器, 只是不提供数据服务, 通常哨兵配置数量为单数.

2.2 哨兵工作原理

哨兵的作用就是监控Redis集群, 一旦Redis主节点宕机了, 需要将从节点选一个主节点, 哨兵在进行主从切换过程中经历三个阶段.

• 监控
• 通知
• 故障转移

2.2.1 阶段一: 监控阶段

哨兵节点用于同步各个节点的状态

• 哨兵连接主节点, 查看是否存活.
• 获取master的转态
  • master属性
    • runid
    • role: master
• 获取所有slave的转态(根据master中的slave信息)
  • slave属性
    • runid
    • role: slave
    • master_host, master_port
    • offset
    • …
• 哨兵连接从节点, 查看从节点是否存活
• 哨兵集群内部也要互相通信, 也就是哨兵集群之间也会有自己的朋友圈, 哨兵-1会把消息同步给其他哨兵, 其他哨兵也会去连接主从节点.

2.2.2 阶段二: 通知阶段

通知阶段主要的目的就是哨兵定期发送消息到Redis主从节点, 同时哨兵集群内部也要同步消息, 保证每个哨兵节点存储的redis集群消息是一致的.

• sentinel1(哨兵节点1)发送消息到主从节点, 观察redis集群健康转态
• 哨兵1将得到的健康状态同步到哨兵2,哨兵3
• 哨兵2也会去重复哨兵1的动作, 发送消息到主从节点, 并同步给其他哨兵节点
  

2.2.3 阶段三: 故障转移阶段

• 发现问题
  1. 哨兵-1 发送消息到master, 如果没有得到回复, 则把master标记为主观下线.
  2. 哨兵-1把master挂了的消息同步给哨兵-2, 哨兵-3, 然后哨兵-2和哨兵-3也发送消息到master确认是否能连通. 如果3个哨兵中超过一半也就是2个哨兵认为master挂了, 那么master就被标记为客观下线了.
     
• 哨兵集群内部竞选负责人, 负责人负责选出新的master.
  • 哨兵集群内部会进行投票选举, 类似于zk的选举机制, 选出哨兵负责人
• 哨兵负责人优选新的master
  • 肯定要挑选在线的服务器
  • 剔除响应慢的服务器
  • 剔除与原master断开时间久的服务器
  • 剩下的就采用优先原则了
    • offset偏移量小的
    • runid小的
• 新master上任, 其他slave切换master, 原master作为slave故障恢复后连接新master.