深入学习 Redis Sentinel - 基于 DockerCompose 编排哨兵分布式架构，理解工作原理

先看看主节点还能不能抢救，好不好抢救.
如果主节点这边出事的原因很难解决，就需要挑一个从节点，设置为新的主节点
1. 具体的，把选中的从节点，通过 slaveof no one，自立山头.
2. 其他的从节点，通过修改 slaveof，将 ip 和 port 改为新上任的主节点.
3. 告知客户端（修改客户端配置），让客户端能够连接新的主节点，用来完成修改数据的操作.
4. 最后，如果之前挂了的主节点修好了，就可以将其作为一个新的从节点，加入到这个机器当中.

Ps：

1.只要是涉及到人工干预，不说繁琐，至少是很烦人的~

2.另外，这个操作过程一旦出错了，就可能让问题更加严重。

3.通过人工干预的做法，就算程序员第一时间看到了报警信息，第一时间处理，也至少需要半个小时以上的恢复时间，也就是说，这半个小时里，整个 redis 就一直不能写？显然不合适。

为了提高 “可用性” 引入以下架构模式~

1.2、Redis Sentinel 分布式架构

1.2.1、概述

Redis Sentinel 是⼀个分布式架构，其中包含若干个 Sentinel 节点（哨兵）和 Redis 数据节点，这两种结点之间的哨兵机制，是通过独立的进程来体现的，和 redis-server 是不同进程！redis-sentinel 不负责存储数据，只是对其他的 redis-server 进程起到监控的效果.

1.2.2、工作原理（redis 哨兵的核心功能）

1. 监控：

a）redis sentinel 进程，会监控现有的主从结点（这里的监控就是指，sentinel 进程会和主从结构进程之间建立 tcp 长连接，通过这样的长连接，定期发送心跳包，看主节点是否挂了，如果心跳包没有如果如约而至，就说明 redis 主节点挂了）.

b）如果是从节点挂了，其实没关系，如果是主节点挂了，哨兵就要发挥作用了，此时一个哨兵发现了主节点挂了，还不够，需要多个哨兵来认同这件事，主要防止出现误判（网络抖动，导致心跳包丢失）.

c）如果主节点确实挂了，这些哨兵结点中，就会选举出一个 leader，由这个 leader 负责从现有的从节点中，挑选出一个新的主节点.

2. 自动故障转移：

d）挑选出新的主节点之后，哨兵结点就会自动控制被选中的结点，执行 slaveof no one，让他先自立山头，然后再控制其他从节点，修改 slaveof 到新的主节点上.

3. 通知

e）哨兵结点会自动通知客户端程序，告知新的主节点是谁，后续，客户端再进行写操作，就会针对新的主节点进行操作了.

Ps：以上这三大点，也是 redis 哨兵的核心功能.（这里只是粗略的讲了以下 “哨兵重新选取主节点的流程” ，后面会详细讲！这是面试经常会问的问题！）

1.2.3、问题：哨兵结点只有一个可以么？

redis 哨兵结点，只有一个也是可以的.

但值得注意的是，再分布式系统中，应该避免 “单点” 问题（1.一个服务器挂了，整个就服务就瘫痪了；2.并发量有限）.

在 redis 中可能会导致以下问题：

一个哨兵结点，自身也是容易出现问题的，万一这一个哨兵结点挂了，后续 redis 结点挂了，就无法进行自动恢复了.
出现误判的概率也比较高，因为网络传输数据是容易出现抖动、延迟、丢包等问题的.

Ps：哨兵结点，最好搞奇数个，最少也要有 3 个

1.3、使用 Docker 和 DockerCompose 模拟部署哨兵模式

1.3.1、前言

这里我们将以下图为例，通过 Docker 和 DockerCompose 部署和编排 3 个哨兵和 1 个主 2 个从结点.

案例说，这 6 个结点是要部署到 6 个不同的服务器主机上的.

但我这里只有一个云服务器（实际的工作中，上述结点放在一个云服务器上事没有意义的，这么做也是没办法，经济有限），如果直接部署，就需要小心避开这些冲突：端口号、配置文件、数据文件....

使用 docker 就可以有效解决上述问题~

虚拟机，就是在电脑上通过软件模拟出另外一些硬件（构造了一个台虚拟电脑），也就是说，通过虚拟机这样的软件，就可以使用一个计算机，来模拟出多个电脑的情况.

但是虚拟机有个很大的问题：很吃配置，这个事情对于我的云服务器来说，压力山大~

docker 可以认为是一个 “轻量级” 的虚拟机（现在后端开发很流行这个组件），既不吃很多的硬件资源，又可以起到虚拟机这样的隔离环境的效果（即使你云服务器配置很低，也能构造出好几个这样的虚拟环境）.

1.3.2、准备工作

a）首先要安装好 docker 和 docker-compose.

这里我之前有出过专门的文章，可以去翻翻.

b）停止之前的 redis 服务器

如果是通过 redis-server 启动服务器，就必须搭配 kill 命令来停止.
如果是通过 service redis-server start 启动服务器，必须搭配 service redis-server stop 来停止.
如果使用 kill 命令停止 service redis-server start ，这个 redis-server 进程会自动启动.

c）使用 docker 获取 redis 镜像

通过以下命令，就可以从 docker hb 上拉取 redis 5.0.9 的镜像

docker pull redis:5.0.9

1.2.3、基于 docker 搭建 redis 哨兵环境

Ps：此处涉及到多个 redis server 和多个 redis 哨兵结点，每一个 redis server 和每一个 redis 哨兵结点都是作为一个单独的容器（按照案例，这里总共要部署 6 个容器），为了方便部署，使用 docker-compose 进行容器编排.

a）分配文件目录结构

由于 redis 哨兵结点是单独的 redis 服务器进程，因此之后对于哨兵和主从结点的 yml 配置文件要分开！！！

虽然也可以使用一个 yml 文件直接启动 6 个容器，但是如果 6 个容器同时启动，可能是哨兵先启动完成，数据节点后启动完成，哨兵可能就会先认为是数据结点挂了！虽然从大体上来看不影响，但是会影响到我们对执行日志的观察.

b）编写 yml 配置文件

这里分别在 redis-data 目录和 redis-sentinel 目录下创建一个 yml 配置文件（注意，文件名必须是 docker-compose.yml）

分别用来描述 3 个数据结点和 3 个哨兵结点，具体要创建哪些容器，每个容器运行的各种参数，描述清除。

后续通过一个简单的命令，就可以批量进行启动/停止这些容器了.

Ps：下来讲到的配置文件不需要记，只需要了解其中一些参数的意思即可，实际工作中不可能让你去写，只会让你去 copy 现有的，对关键参数进行修改.

数据结点配置文件如下：

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

对一些关键参数的解释：

image：当前容器是基于哪个镜像创建的（镜像就相当于模板，启动镜像就可以构建出容器）.
container_name：自定义容器的名字。docker 中可以通过容器名字, 作为 ip 地址, 进⾏相互之间的访问.
restart：容器遇到一些异常情况终止了，是否重启（always 表示一旦遇到异常情况，立刻重启）.
command：用什么命令来启动服务.
ports：这里的规则是 [宿主机端口] [容器内部端口]。上述配置文件中，要启动三个容器（master、slave1、slave2），这三个容器的内部端口号都是自成一个小天地，也就是说，容器 1 的 6379 和容器 2 的 6379 之间是不会有冲突的（两个容器可以视为两个主机）；有的时候，希望容器外访问容器内部的端口，需要进行端口映射，把容器内吨端口映射到宿主机上，后续访问宿主机这个端口，就相当于在访问对应容器的对应端口了.

Ps：站在宿主的角度，访问上述几个端口的时候，也不知道这个端口是一个宿主机上的服务，还是来自于容器内部的服务，只要正常使用即可。这里的映射过程很像 NAT.

哨兵结点配置文件如下：

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

对一些关键参数的解释：

volumes：建立映射. 哨兵结点在运行的过程中，会对配置文件进行自动修改，因此就不能只拿 /etc/redis/sentinel.conf 这一个配置文件，给三个容器分别进行映射. 以上 volumes 的内容，就需要我们在当前目录下（redis-sentinel目录下）继续创建三个 conf 文件.

c）编写哨兵结点的三个 conf 配置文件

创建 sentinel1.conf、sentinel2.conf、sentinel2.conf 这三个配置文件，内容可以是一样的，容器启动后，会自动对这三个 conf 文件进行修改.

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

参数解释：

bind 0.0.0.0：表示让其他结点进行访问.
port：容器内部使用的端口.
sentinel monitor redis-master 6379 2：这里是告诉哨兵结点，需要监控哪个 redis 服务器. redis-master 这里其实是 ip 地址，是使用 docker 自动进行域名解析. 最后的 2 表示法定票数，这里的票数就是为了更稳健的确认，当前 redis-server 是否挂了，不能只听一个哨兵的一面之词.
sentinel down-after-milliseconds redis-master 1000：这里表示心跳包的超时时间.（此处是 1000ms）.

d）使用 docker-compose 启动数据结点

使用 docker-compose up -d 命令（-d 表示后天运行）启动所有容器（必须和 docker-compose.yml 同文件路径下）

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

如果出现以下错误，说明 yml 中配置的 version 不支持，修改成报错信息中支持的版本即可（以下报错中提示，只支持 version 为 2.2 或者 3.3 的版本）

如下信息为启动成功

通过 redis-compose logs 命令查看运行日志信息

e）验证

通过连接 redis 验证主从结构

连接主节点：redis-cli -p 6379

连接第一个从节点：redis-cli -p 6380

连接第二个从节点：redis-cli -p 6381

f）使用 docker-compose 启动 redis-sentinel 结点

在 redis-sentine 目录下，使用 docker-compose up -d 启动所有容器

通过 docker-compose logs 查看日志文件

日志里为什么全都是报错信息呢？都是什么意思？（重！）

docker-compose 一下启动了 N 个容器，此时 N 个容器都是处于同一个 “局域网” 中，可以使这 N个容器之间可以互相访问~

但是！！！三个 redis-server 结点是一个局域网，三个哨兵结点是另外一个局域网，默认情况下，这两网络是不互通的！！！

解决方案：

可以使用 docker-compose 把此处两组服务放到同一个局域网中.

具体的，使用 docker network ls 列出当前 docker 中的局域网，就可以拿到 redis-data 服务的 docker-compose 文件所在目录名（用来修改配置文件）

修改哨兵结点中配置文件，在之前配置文件的基础上加上如下配置：

networks:
  default:
    external:
      name: redisdata_default

然后再启动哨兵，观察日志如下：

打开 sentinel1.conf 文件，就可以看到，哨兵结点启动之后，自动进行修改的内容如下：

1.2.4、展现哨兵机制

哨兵存在的意义，就是在 redis 主从机构出现问题的时候（主节点挂了），此时哨兵结点能够自动帮我我们重新选出一个主节点，来代替之前挂了的结点，保证整个 redis 仍然是可用的状态.

这里我们可以通过 docker stop redis-master 命令手动把主节点干掉，然后观察哨兵日志，可以看到

sdown 主观下线：本哨兵结点，认为该主节点挂了.
odown 客观下线：好几个哨兵都认为该主节点挂了，也就是达到了法定票数，此时这个主节点挂了的事情就被实锤了.

此时就需要先选出一个 leader哨兵，由这个 leader 哨兵结点选出一个从节点，作为新的主节点.

接着往下看日志，就可以看出 3 个哨兵的投票过程.

1.2.5、哨兵重新选取主节点的流程

1. 主观下线（sdown）：哨兵节点通过心跳包，判定 redis 服务器是否正常工作. 如果心跳包没有如约而至，就说明 redis 服务器挂了.

Ps：此时还不能排除网络波动的影响，因此就只能单方面的认为这个 redis 结点挂了.

比如是否可能出现非常严重的网络波动，导致所有哨兵都联系不上 redis 主节点，误判成挂了呢？

当然可能是有的！如果出现这个情况，怕是用户的客户端也连接不上 redis 主节点，此时这个主节点基本上也就无法正常工作了.

“挂了” 不一定是进程崩了，只要无法正常访问，都可以视为挂了.

2. 客观下线（odown）：多个哨兵都认为主节点挂了，（认为挂了的哨兵数目到达 “法定票数”），哨兵们就认为这个主节点是客观下线.

3. 多个哨兵结点会通过投票的方式，选出一个 leader 哨兵结点，有这个 leader 负责选出一个从节点作为新的主节点.

具体的，每个哨兵手里只有一票（接下来的投票过程，就是看谁反应快，网络延迟小）

1 号哨兵第一个发现当前是客观下线之后，就立即给自己投了一票（推举自己成为 leader），并且告诉 2 3 ，我来负责这个事情（2 3 当他们没有投出这一票的时候，拉票请求，就会投出去，如果有多个拉票请求，就投给最先到达的），如下：

2 号哨兵不乐意，认为自己和 1 号同时发现，也给自己投了一票，3 号哨兵慢了半拍，才发现是客观下线，就把这一票投给了 1 号哨兵，如下：

如果总的票数到达了哨兵总数的一半，选举就完成了.（把哨兵个数设置成奇数个结点，就是为了方便投票）.

4. 此时 leader 选举完毕，leader 需要挑选出一个从节点，作为新的主节点.

具体的挑选从节点的规则如下：

a）优先级：每个 redis 数据结点，都会在配置文件中有一个优先级的设置（slave-priority）优先级高的从节点，就会胜出（如果没有设置，默认优先级都是一样的）. 如果当前优先级一样，就看下一个规则.

b）offset ：offset 就是从节点从主节点这边同步数据的进度，数值越大，说明从结点的数据和主节点的数据越接近，因此，最大的胜出. 如果当前优先级一样，就看下一个规则.

c）run id：每个 redis 结点启动的时候随机生成一串数字（大小全随机），这时候就是相当于是随机了.

这就像是，大学的学生如果和辅导员有亲戚关系，那么班长就是钦定的，如果没有关系，那么就看谁更听她的话，如果都是刺头，那就只能看谁名字好听了~

5. 新的主节点指定好了之后，leader 就会控制这个结点，执行 slave no one，让其独立山头，成为 master，然后再控制其他节点，执行 slave of，让其他节点以新的 master 作为主节点.

6. 最后，如果之前挂掉的主节点修复了，就直接让这个节点变为从节点加入到机器中（为什么不在成为主节点？因为成为主节点，还需要通过 slave of 修改正在运行的主节点，这个过程，可能会丢失数据）.

使用 docker start redis-master 命令启动恢复之前挂掉的主节点后，会发现，已经变为从节点

1.2.6、缺陷

哨兵 + 主从解决的问题是 “提高可用性”，不能解决极端情况下写丢失的问题~

最关键的一点就是，在数量十分庞大的情况下，这种模式就难以胜任了！

因此，redis 集群，就是解决存储容量问题的有效方案.