[Redis]哨兵机制

哨兵机制概念

在传统主从复制机制中，会存在一些问题：

1. 主节点发生故障时，进行主备切换的过程是复杂的，需要人工参与，导致故障恢复时间无法保障。

2. 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。

哨兵机制就是为了解决第一个高可用问题的

当主节点出现故障时，哨兵机制能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。哨兵机制是一个分布式架构，其中包含若干个redis哨兵节点和Redis数据节点，每个哨兵节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果下线的是主节点，它还会和其他的哨兵节点进行“协商”，当大多数哨兵节点对主节点不可达这个结论达成共识之后，它们会在内部“选举”出一个领导节点来完成自动故障转移的工作，同时将这个变化实时通知给Redis应用方。整个过程是完全自动的，不需要人工介入。

环境规划

redis版本：5.0.9

我们将使用docker搭建redis哨兵环境

docker-compose 来进行容器编排

1）创建三个容器，作为redis的数据节点（主从结构，一主两从）

2）创建三个容器，作为redis的哨兵节点

目录结构：

搭建数据节点

docker-compose.yml是 Docker Compose 使用的配置文件，它定义了多个 Docker 容器的服务、网络和卷的配置。通过这个文件，你可以使用一条命令来批量启动多个docker容器

配置docker-compose.yml

version: '3.7'
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: '3.7'指定 Docker Compose 文件的版本。版本 3.7 支持更高级的功能和配置选项。

services:定义一组服务，每个服务对应一个容器。在这里，我们定义了三个服务，分别是主节点master和两个从节点slave。

image：指定要使用的镜像，这里是我们提前拉取的redis:5.0.9镜像

container_name: 指定容器的名称。这样，你可以通过这个名称来引用和管理容器。

restart: always：指定容器的重启策略。在这里配置为always，表示无论容器是因何原因退出，Docker 都会自动重启该容器。

command：设置启动命令，为主节点和从节点配置不同的命令

ports：映射主机端口到容器端口。前一个是主机端口，后一个是容器端口。就是说，在主机里这三个redis分别是6379,6380,6381端口，映射到各自容器的6379端口

启动docker compose配置的服务

在docker-compose.yml配置文件同级目录下使用命令：

sudo docker-compose up -d

up表示构建、（重新）创建、启动并连接配置文件中定义的所有服务。如果某些服务已经在运行，up命令会重新启动它们。

-d表示 --detach 选项，它会将服务在后台运行。如果没有-d选项，服务将会在前台运行，并输出日志信息到当前终端窗口

如果启动后发现前面的配置有误,需要重新操作,使用 docker-compose down 即可停止并删除刚才创建好的容器.

查看运行日志

同级目录下使用命令：

sudo docker-compose logs

可以看见成功加载了三个容器

也可以使用命令：

sudo docker ps -a

显示容器的列表

可以在最后一列看到名字分别是redis-slave1、redis-slave2、redis-master代表三个数据节点

搭建成功

验证

连接主节点

可以看到，主节点，有两个连接的从节点

搭建哨兵节点

（其实也可以把哨兵节点的yml配置文件和上面的配置文件写到一起，这里分成两组，主要是为了方便观察）

哨兵节点配置

放在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表示监听的redis节点，第一个redis-master是给哨兵内部的名字，第二个是主节点ip，但是这里用的是docker，所以就写容器名，会自动DNS成对应的ip，6379表示端口，2表示票数，如果有哨兵节点觉得主节点挂了，那就投1票，当票数大于等于2时，就认为主节点真的挂了，就会启动后面的流程

sentinel down-after-milliseconds redis-master 1000主节点和哨兵之间通过心跳包来进行沟通.如果心跳包在指定的时间（1000ms）内还没回来,就视为是节点出现故障.

为什么要创建三个一样的文件，而不用同一个呢？

因为redis-sentinel 在运行中可能会对配置进行重写,修改文件内容.如果用一份文件,就可能出现修改混乱的情况.

配置docker-compose.yml

version: '3.7'
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