哨兵模式·

哨兵简介

 

1. 引入的原因

• 现象：master 宕机
• 解决：
  • 将宕机的master 下线
  • 找一个slave 作为master
  • 通知所有的slave 连接新的master
  • 启动新的master 与 slave
  • 全量复制*N + 部分复制*N
• 上述解决方案引出的问题
  • 谁来确定master 宕机？
  • 找一个master ？ 怎么找？
  • 修改配置后，原始的master 恢复了怎么办？
• 引入哨兵来解决上述引出的问题！！

2. 哨兵

• 定义：是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master 并将所有的slave 连接到新的master
• 作用
  • 监控
    • 不断的检查master 和 slave 是否正常运行
    • master 存活检测、master与slave 运行情况检测
  • 通知
    • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
  • 自动故障转移
    • 断开master 与 slave 连接，选取一个slave 作为master，将其他slave连接到新的master，并告知客户端新的服务器地址
• 注意
  • 哨兵也是一台redis 服务器，只是不提供数据服务
  • 通常哨兵配置数量为单数（避免投票打平）

启用哨兵模式

配置哨兵

• 配置一拖二的主从结构
• 配置三个哨兵（配置相同，端口不同）
  • 参看sentinel.conf
• 启动哨兵

redis-sentinel sentinel-端口号.conf

哨兵工作原理

主从切换

• 哨兵在进行主从切换过程中经历三个阶段
  • 监控
  • 通知
  • 故障转移

阶段一：监控阶段

• 用于同步各个节点的状态信息
  • 获取各个sentinel 的状态（是否在线）
  • 获取master 的状态
    • master 属性
      • runid
      • role：master
    • 各个slave 的详细信息
  • 获取所有slave 的状态（根据master 中的slave 信息）
    • slave 属性
      • runid
      • role：slave
      • master_host、master_port
      • offset
      • ...
  • 具体过程

  • 

阶段二：通知阶段

注意：不一定是sentinel1 通过建立的cmd 连接进行publish sentinel :hello 命令的传输，任何一个哨兵都可能行使该动作，并且获得该命令的回复结果之后，会在所有哨兵之间快速传播。这一阶段是redis 集群长期处于的阶段。

阶段三： 故障转移阶段

•  首先某一台sentinel（以sentinel1为例）给master 照常发送hello 指令时，发现超过配置的时间还没有信息返回，则将master 标记为 SRI_S_DOWN，也称为主观下线
• 在sentinel 认定master 宕机之后，会给其他哨兵发送 is-master-down-by-addr....信息，其他哨兵收到信息之后给master 发送hello 信息
• 其他哨兵当发送hello 之后同样在规定的时间内获取不到答复，则也会给其他哨兵发送master已经宕机的信息，当半数以上（这个数量是在配置文件中进行配置的，一般在生产环境下设置为半数以上）的哨兵认为主机宕机，则会将主机标记为SRI_O_DOWN，也称为客观下线
• 客观下线之后，所有哨兵会进行投票，选出进行处理故障的哨兵。投票过程是所有的哨兵向其他的哨兵发送 sentinel is-master-down-by-addr.... 挂的ip + 挂的端口 + 竞选次数 + 自己的runid。哨兵将票投给接收到的第一个该信息对应的哨兵，其中票数最多的当选。如果存在凭票继续进行下一轮竞选。

• 

• 当选的哨兵会开始对故障进行处置，即从服务器列表中挑选备用master，首先必须选择在线的，并且需要过滤响应慢的 以及 与原master断开时间久的。之后根据优先原则进行选择，优先原则包括优先级，offset（主要是判别数据的新旧），runid（选runid小的）。按照上述的过程即可选出新的master
• 当选的哨兵首先会给新的master发送 slaveof no one 指令，之后向其他slave 发送slaveof 新masterIP 端口 的指令