redis之哨兵

Eugene03

已于 2023-04-25 10:54:29 修改

阅读量368

点赞数

分类专栏： redis 文章标签： redis 数据库缓存

于 2022-10-21 21:35:30 首次发布

本文链接：https://blog.csdn.net/Eugene03/article/details/127453448

版权

redis 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

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：