redis（七）哨兵

简介

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

作用：

• 监控

  ​ 不断的检查master和slave是否正常运行。 master存活检测、master与slave运行情况检测

• 通知（提醒）

  ​ 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。

• 自动故障转移

  ​ 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服 务器地址

注意：

哨兵也是一台redis服务器，只是不提供数据服务

通常哨兵配置数量为单数 因为要投票，双数有可能会打平

配置哨兵模式

1.配置一拖2的主从结构

​ 之前已经有一主一从了，现在启动第三台

docker run -p 6381:6381 --name redis-6381 -v /usr/local/docker/redis/conf:/etc/redis/ -v /usr/local/docker/redis/data:/data -d redis redis-server /etc/redis/redis-6381.conf

现在有6379、6380、6381三台redis 主为6379

2.配置三个哨兵（配置相同，端口不同）

• 下载sentinel.conf

• 新建文件配置拷贝进去作为备份

  vim sentinel-common.conf
  

• 配置sentinel.conf

cat sentinel-common.conf |grep -v "#" | grep -v "^$" > sentinel-26379.conf   去掉# 和空格

cp sentinel-26379.conf  sentinel-26380.conf

cp sentinel-26379.conf  sentinel-26381.conf

• 修改文件内的对应的端口26379 26380 26381

  添加验证密码用于连接主节点的时候密码验证

sentinel auth-pass mymaster zhao56

目录结构如下

配置如下

日志放到了data文件夹中

3.启动三个哨兵

docker run -p 26379:26379 --name sentinel-26379 -v /usr/local/docker/redis/conf:/etc/redis/ -v /usr/local/docker/redis/data:/data -d redis  redis-sentinel /etc/redis/sentinel-26379.conf

docker run -p 26380:26380 --name sentinel-26380 -v /usr/local/docker/redis/conf:/etc/redis/ -v /usr/local/docker/redis/data:/data -d redis  redis-sentinel /etc/redis/sentinel-26380.conf

docker run -p 26381:26381 --name sentinel-26381 -v /usr/local/docker/redis/conf:/etc/redis/ -v /usr/local/docker/redis/data:/data -d redis  redis-sentinel /etc/redis/sentinel-26381.conf

查看生成的日志文件

26379.log

26380.log

26381.log

• 连接哨兵23679

docker exec -it sentinel-26379 redis-cli -p 26379

get 命令不能用

执行info 命令会发现

• 现在停掉6379的redis即master

docker stop redis-6379

查看26379日志

可以看出发现6379掉线，然后投票3/2 三个哨兵都说6379掉线了，大于设置的数量2

所以选举出新的master 为6381

• 验证master掉线

6380只允许读不允许写6381可以设置name成功

• 重新启动6379

过一会发现

6379 重新连上来了，变成了slave

哨兵模式原理

哨兵在进行主从切换过程中经历三个阶段

1.监控

2.通知

3故障转移

1.监控阶段

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

1.当第一个sentinel连接以后会想master发送info指令

2.建立cmd连接方便之后发命令，并且双方保存一些信息

3.向slave发info命令

4.第二胎sentinel连接上以后也会连接master发现已经连过了， 所以也会连接之前的sentinel

此时两个sentinel信息不同，所以建立发布订阅，相互发送ping命令，相互同步信息

2.通知阶段

sentinel1通过建立的连接向几个服务端发送命令，然后将反馈的状态共享给其他sentinel，下次可能是sentinel2或sentinel3去发送命令

3故障转移阶段

1.故障验证

sentinel1会想master发送指令，当master宕机的时候会没有回应，sentinel1重复发很多次之后发现仍未有回应，就将master置为SRI_S_DIWN(主观下线)，此时将在sentinel共享中发送master下线的消息，其他sentinel会验证是否下线，超过半数投票master下线就将master置为SRI_O_DOWN(客观下线)

2.挑选领头的sentinel

sentinel会发送各自的信息进行投票，最终选择领头的sentinel，所以sentinel最好设置成单数，以防打平

3.处置

master下线，领头的sentinel需要将master下线，并挑选出新的master

原则：

• 在线的
• 剃掉响应慢的
• 剃掉与原master断开时间久的
• 优先原则
  • 优先级
  • offset 偏移量
  • runid

发送指令

想新的master发送slveof no one 断开连接

想其他slave发送消息连接新的master