【Redis】哨兵机制

1 🍑基本概念🍑

由于对 Redis 的许多概念都有不同的名词解释，所以在介绍 Redis Sentinel 之前，先对⼏个名词概念进⾏必要的说明。

名词	逻辑结构	物理结构
主节点	Redis 主服务	⼀个独⽴的 redis-server 进程
从节点	Redis 从服务	⼀个独⽴的 redis-server 进程
Redis 数据节点	主从节点	主节点和从节点的进程
哨兵节点	监控 Redis 数据节点的节点	⼀个独⽴的 redis-sentinel 进程
哨兵节点集合	若⼲哨兵节点的抽象组合	若⼲ redis-sentinel 进程
Redis 哨兵（Sentinel）	Redis 提供的⾼可⽤⽅案	哨兵节点集合和 Redis 主从节点
应⽤⽅	泛指⼀个多多个客⼾端	⼀个或多个连接 Redis 的进程

1.1 🍎主从复制的问题🍎

如果还没有了解过主从复制的老哥建议先看看博主讲解过的：

Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作⽤：

第⼀，作为主节点的⼀个备份，⼀旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上来，并且保证数据尽量不丢失（主从复制表现为最终⼀致性）。
第⼆，从节点可以分担主节点上的读压⼒，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。

但是主从复制模式并不是万能的，它同样遗留下以下⼏个问题：

主节点发⽣故障时，进⾏主备切换的过程是复杂的，需要完全的⼈⼯参与，导致故障恢复时间⽆法保障。
主节点可以将读压⼒分散出去，但写压力/存储压力是⽆法被分担的，还是受到单机的限制。其中第⼀个问题是⾼可⽤问题，即 Redis 哨兵主要解决的问题。第⼆个问题是属于存储分布式的问题，留给 Redis 集群去解决，本章我们集中讨论第⼀个问题。

1.2 🍎人工恢复主节点故障🍎

Redis 主从复制模式下，主节点故障后需要进⾏的⼈⼯⼯作是⽐较繁琐的：
1）运维⼈员通过监控系统，发现 Redis 主节点故障宕机。
2）运维⼈员从所有从节点中，选择⼀个节点执⾏ slaveof no one，使其作为新的主节点。
3）运维⼈员让剩余从节点执⾏ slaveof {newMasterIp} {newMasterPort} 从新主节点开始数据同步。
4）更新应⽤⽅连接的主节点信息到 {newMasterIp} {newMasterPort}。
5）如果原来的主节点恢复，执⾏ slaveof {newMasterIp} {newMasterPort} 让其成为⼀个从节点。

上述过程可以看到基本需要⼈⼯介⼊，⽆法被认为架构是⾼可⽤的。⽽这就是 Redis Sentinel 所要做的。

1.3 🍎哨兵自动恢复主节点故障🍎

当主节点出现故障时，Redis Sentinel 能⾃动完成故障发现和故障转移，并通知应⽤⽅，从⽽实现真正的⾼可⽤。

Redis Sentinel 是⼀个分布式架构，其中包含若⼲个 Sentinel 节点和 Redis 数据节点，每个Sentinel 节点会对数据节点和其余 Sentinel 节点进⾏监控，当它发现节点不可达时，会对节点做下线表⽰。如果下线的是主节点，它还会和其他的 Sentinel 节点进⾏ “协商”，当⼤多数 Sentinel 节点对主节点不可达这个结论达成共识之后，它们会在内部 “选举” 出⼀个领导节点来完成⾃动故障转移的⼯作，同时将这个变化实时通知给 Redis 应⽤⽅。整个过程是完全⾃动的，不需要⼈⼯介⼊。

在这里插入图片描述

Redis Sentinel 相⽐于主从复制模式是多了若⼲Sentinel 节点（建议保持奇数）⽤于实现监控数据节点，哨兵节点会定期监控所有节点（包含数据节点和其他哨兵节点）。针对主节点故障的情况，故障转移流程⼤致如下：
1）主节点故障，从节点同步连接中断，主从复制停⽌。
2）哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商，达成多数认同主节点故障的共识。这步主要是防⽌该情况：出故障的不是主节点，⽽是发现故障的哨兵节点，该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下。
3）哨兵节点之间使⽤ Raft 算法选举出⼀个领导⻆⾊，由该节点负责后续的故障转移⼯作。
4）哨兵领导者开始执⾏故障转移：从节点中选择⼀个作为新主节点；让其他从节点同步新主节点；通知应⽤层转移到新主节点。

通过上⾯的介绍，可以看出 Redis Sentinel 具有以下⼏个功能：

监控: Sentinel 节点会定期检测 Redis 数据节点、其余哨兵节点是否可达。
故障转移: 实现从节点晋升（promotion）为主节点并维护后续正确的主从关系。
通知: Sentinel 节点会将故障转移的结果通知给应⽤⽅。

2 🍑基于 docker安装部署🍑

2.1 🍎准备工作🍎

2.1.1 🍋安装 docker🍋

参考博主之前的文章：

2.1.2 🍋安装 docker-compose🍋

# ubuntu
apt install docker-compose
# centos
yum install docker-compose

当 docker安装成功后使用docker info可以验证：

在这里插入图片描述
当 docker-compose安装成功后使用 docker-compose version我这里使用的是1.1版本的，配置比较低，我们可以去gitup上找一个高版本的：https://github.com/docker/compose/releases/tag/v2.24.6
大家选择下面的即可：
下载后使用rz命令上传到Linux中，然后将文件名字改为docker-compose,再将文件移动到/usr/local/bin目录下,将文件赋予可执行权限：

rz
mv docker-compose-linux-x86_64 docker-compose
mv docker-compose /usr/local/bin

再创建软链：

ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

最后测试是否安装成功：
在这里插入图片描述

2.1.3 🍋使⽤ docker 获取 redis 镜像🍋

docker pull redis:5.0.9

2.2 🍎编排 redis 主从节点🍎

2.2.1 🍋编写 docker-compose.yml🍋

创建 /root/redis-data/docker-compose.yml , 同时 cd 到 yml 所在⽬录中。注意docker-compose.yml是固定的不能够改变，但是前面的路径用户可以自定义。
同时这里补充一下什么是yml格式，这种格式类似于json，只不过json是使用的{}来进行组织数据，而yml则是使用缩进来表示的。

docker-compose.yml中的数据如下：

version: '2.2'
services:
  master:
    image: 'redis:5.0.9'
    container_name: redis-master
    restart: always
    command: redis-server --appendonly yes
    ports:
      - 6379:6379
  slave1:
    image: 'redis:5.0.9'
    container_name: redis-slave1
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6380:6379
  slave2:
    image: 'redis:5.0.9'
    container_name: redis-slave2
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6381:6379

注意：

一定要留意每行开头的空格。
version后面的版本数据与我们使用docker-compose -v 命令查出来的要一致。

大家可能会对下面的数据感兴趣：

其中前面的端口号是宿主机的端口号，一般来说是不允许冲突的，而后面的端口号则是容器类的端口号，由于各个容器件都是互相隔离的，所以端口号即使相同也是不会冲突的。而上面下的意思就是将容器外面的端口(宿主端口)映射到容器内部的端口，这样我们在宿主机上就能够访问到容器内部的端口了。
在这里插入图片描述

本来在这里是要使用具体的ip地址的，但是由于docker容器的ip地址并不是固定的，所以在这里我们只需要写上容器的名字即可，docker会自动将其转化为ip地址。(docker 中可以通过容器名字, 作为 ip 地址, 进⾏相互之间的访问)

2.2.2 🍋启动所有容器🍋

docker-compose up -d

其中-d选项是以后台进程的方式运行。

在这里插入图片描述
如果启动后发现前⾯的配置有误, 需要重新操作, 使⽤ docker-compose down 即可停⽌并删除刚才创建好的容器。

我们还可以使用ps命令来进行查看：
在这里插入图片描述
还可以使用docker-compose logs查看运⾏⽇志：

注意：查看运⾏⽇志必须保证⼯作⽬录在 yml 的同级⽬录中, 才能⼯作。

我们分别登录到主节点以及从节点各自使用info replication命令来进行查看：

在这里插入图片描述

通过对比不难发现已经成功了。

2.3 🍎编排 redis-sentinel 节点🍎

也可以把 redis-sentinel 放到和上⾯的 redis 的同⼀个 yml 中进⾏容器编排. 此处分成两组, 主要是为了两⽅⾯:

观察⽇志⽅便；
确保 redis 主从节点启动之后才启动 redis-sentinel. 如果先启动 redis-sentinel 的话, 可能触发额外的选举过程, 混淆视听. (不是说先启动哨兵不⾏, ⽽是观察的结果可能存在⼀定随机性)

2.3.1 编写 🍋docker-compose.yml🍋

先要创建 /root/redis-sentinel/docker-compose.yml , 同时 cd 到 yml 所在⽬录中:

version: '2.2'
services:
  sentinel1:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-1
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel1.conf:/etc/redis/sentinel.conf
    ports:
      - 26379:26379
  sentinel2:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-2
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel2.conf:/etc/redis/sentinel.conf
    ports:
      - 26380:26379
  sentinel3:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-3
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel3.conf:/etc/redis/sentinel.conf
    ports:
      - 26381:26379
networks:
  default:
    external:
      name: redis-data_default

大家注意到最后添加的这几行：
在这里插入图片描述
这个是由于如果我们不加上这几行，那么我们启动的数据节点与哨兵节点就会在两个不同的局域网，这时是不能够通信的，我们可以使用docker network ls命令来查看局域网：

我们发现局域网的名字前缀是以存放yml文件的目录。

2.3.2 🍋创建配置⽂件🍋

创建 sentinel1.conf sentinel2.conf sentinel3.conf . 三份⽂件的内容是完全相同的。都放到 /root/redis-sentinel/ ⽬录中

bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

在这里插入图片描述

理解 sentinel monitor

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数

主节点名, 这个是哨兵内部⾃⼰起的名字。
主节点 ip, 部署 redis-master 的设备 ip. 此处由于是使⽤ docker, 可以直接写 docker 的容器名, 会被⾃动 DNS 成对应的容器 ip。
主节点端⼝。
法定票数, 哨兵需要判定主节点是否挂了。但是有的时候可能因为特殊情况, ⽐如主节点仍然⼯作正常, 但是哨兵节点⾃⼰⽹络出问题了, ⽆法访问到主节点了. 此时就可能会使该哨兵节点认为主节点下线, 出现误判. 使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法. 需要多个哨兵都认为主节点挂了, 票数 >= 法定票数之后, 才会真的认为主节点是挂了。