redis之哨兵

redis之哨兵

背景

• 将宕机的master下线
• 找一个slave作为master
• 通知所有的slave连接新的master
• 启动新的master与slave
• 全量复制N+部分复制N
• 谁来确认master宕机了
• 找一个主？怎么找法
• 修改配置，原始的主恢复了怎么办

哨兵

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

哨兵的作用

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

注意

• 哨兵也是一台redis服务器，只是不提供数据服务
• 通常哨兵的配置数量为单数（投票机制问题）

启用哨兵

配置哨兵

• 配置一拖二的主从结构

• 配置三个哨兵（配置相同，端口不同）
  参看sentinel.conf

• 启动哨兵

	·redis-sentinel sentinel-端口号.conf

# 哨兵服务占用的端口
port 26379
# dir存放哨兵工作日志
dir /tmp
# mymaster：表示哨兵监控的master，名字可以任意取   
# 2：如果有2个哨兵认为mymaster挂了，那这个master就真的挂了，通常设置为哨兵总数的一半 + 1
sentinel monitor mymaster 127.0.0.1 6379 2
# mymaster 30000ms没响应，哨兵就认为mymaster挂了
sentinel down-after-milliseconds mymaster 30000
# 新的master选出来后，一次和几个slave进行数据同步
# 这个值越小，对服务器压力越小，同步速度越慢；这个值越大，对服务器压力越大，同步速度越快
sentinel parallel-syncs mymaster 1
# 如果同步时间超过180000ms，就认为数据同步超时
sentinel failover-timeout mymaster 180000

修改一下哨兵日志目录
哨兵启动日记

在哨兵服务器上不能执行数据操作，只能执行哨兵对应的一些指令，我们输入info命令查看信息

当我们一旦启动哨兵配置文件会发生变化
启动前：

启动后：



26379哨兵服务器端也有2638哨兵监视master的提示信息。，每启动一个新的哨兵去监视同一个master，哨兵之间都可以相互识别

3个哨兵监视同一个master，三个哨兵的配置文件以及终端提示信息都是相互的，都能互相检测到

验证哨兵的作用

如果master宕机了，哨兵会找一个slave作为master，通知其他所有的slave连接新的master。

我们在哨兵配置文件中设置的是，30000ms内master没有响应，哨兵则认为master已经宕机，30000ms后，哨兵1的终端有如下提示信息：

作为master的6379下线后，主要过程就是所有哨兵都去确认6379是否真的下线，都确定6379下线后开始投票，从slave中选出新的master，然后为其他的slave更改master。并把下线的旧6379master设置为slave，后面6379上线后直接就是slave

6379成为slave

工作原理

阶段一：监控阶段

• 获取各个sentinel的状态（是否在线）
  • 获取master的状态
    • master属性
      • runid
      • role：master
    • 各个slave的详细信息
  • 获取所有的slave的状态（根据master中的slave信息）
    • slave属性
      • runid
      • role：slave
      • master_host, master_port
      • offset
      • …

详细图解
1.

第一个哨兵上线连接master，拿到master的info，同时master也拿到哨兵的info。然后根据从master拿到的有关slave的信息，去连接slave，然后再拿到slave的info，第一个哨兵就拿到了master和所有slave的info

2.
第二个哨兵上线连接master，从master拿到info，从master的info就可以知道当前主从环境中master、slave、sentinel的数量以及ip:port，然后这个哨兵就去找其他的slave和sentinel交换信息拿信息的同时会在sentinel之间建立发布-订阅通道，以共享info

第三个sentinel连接master上线后，就会获取当前所有的master、slave、sentinel的info，并加入sentinel的发布-订阅通道

阶段二：通知阶段

sentinel会轮流询问master和slave的信息，然后在sentinel的朋友圈发布，其他sentinel进行订阅

阶段三：故障转移阶段

首先sentinel1不断询问master，没有响应，直到超过哨兵配置文件中的时间就会认为这个master挂了，所以sentinel1把master的状态标记为sdown（主观下线），然后会在“”朋友圈“发信息说master挂了
所以其他的sentinel也不断询问master，看看有无响应。如果超过半数的sentinel也觉得master挂了，那就会把master的状态标记为odown（客观下线）

master一旦标记为odown，sentinels就会开会投票，通过一定的算法选出一个sentinel去从slave中挑选新的master

挑选master的规则：sentinel会根据以下原则选出新的master：在线的、响应快的、与原master信息交互多等等
优先原则：优先级，offset大的（数据同步及时），runid：

选出新的master后，sentinel会做如下操作：

• 给新的master发送salve of no one，断开新master与原master的主从关系
• 向其他slave发送新master的ip端口，让其他slave重新确定master