redis哨兵模式查看key值 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 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作⽤：

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

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

1. 主节点发⽣故障时，进⾏主备切换的过程是复杂的，需要完全的⼈⼯参与，导致故障恢复时间⽆法保障。
2. 主节点可以将读压⼒分散出去，但写压力/存储压力是⽆法被分担的，还是受到单机的限制。其中第⼀个问题是⾼可⽤问题，即 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

注意：

1. 一定要留意每行开头的空格。
2. 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。
• 主节点端⼝。
• 法定票数, 哨兵需要判定主节点是否挂了。但是有的时候可能因为特殊情况, ⽐如主节点仍然⼯作正常, 但是哨兵节点⾃⼰⽹络出问题了, ⽆法访问到主节点了. 此时就可能会使该哨兵节点认为主节点下线, 出现误判. 使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法. 需要多个哨兵都认为主节点挂了, 票数 >= 法定票数 之后, 才会真的认为主节点是挂了。

理解 sentinel down-after-milliseconds

主节点和哨兵之间通过⼼跳包来进⾏沟通. 如果⼼跳包在指定的时间内还没回来, 就视为是节点出现故障。

既然内容相同, 为啥要创建多份配置⽂件?

redis-sentinel 在运⾏中可能会对配置进⾏ rewrite, 修改⽂件内容. 如果⽤⼀份⽂件, 就可能出现修改混乱的情况。

2.3.3. 🍋启动所有容器🍋

docker-compose up -d

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

2.3.4 🍋查看运⾏⽇志🍋

docker-compose logs

可以看到, 哨兵节点已经通过主节点, 认识到了对应的从节点。

2.3.5 🍋观察 redis-sentinel 的配置 rewrite🍋

打开sentinel1.conf文件：

其余的我就不打开了，对⽐这三份⽂件, 大家可以看到配置内容是存在差异的。

---

3 🍑重新选举🍑

3.1 🍎验证🍎

我们手动模拟redis-master 宕机，刚开始时是这样的：

然后执行docker stop redis-master干掉redis-master。

此时我们观察哨兵日志：

我们可以看到这样的1串信息，表示sentinel1自己给自己投了一票，并且sentinel2和sentinel3赞同也给sentinel1投了一票，达到法定得票, 于是master 被判定为 odown。

在这里补充一点：

• 主观下线 (Subjectively Down, SDown): 哨兵感知到主节点没⼼跳了. 判定为主观下线。
• 客观下线 (Objectively Down, ODown): 多个哨兵达成⼀致意⻅, 才能认为 master 确实下线了。

接下来, 哨兵们挑选出了⼀个新的 master，在日志中可以看到：

此时, 对于 Redis 来说仍然是可以正常使⽤的。
我们还可以启动redis客户端来进行验证：

此刻我们又⼿动把 redis-master 启动起来：

docker start redis-master

观察哨兵⽇志：

还可以观察redis客户端：

结论

• Redis 主节点如果宕机, 哨兵会把其中的⼀个从节点, 提拔成主节点。
• 当之前的 Redis 主节点重启之后, 这个主节点被加⼊到哨兵的监控中, 但是只会被作为从节点使⽤。

3.2 🍎选举原理🍎

假定当前环境如上⽅介绍, 三个哨兵(sentenal1, sentenal2, sentenal3), ⼀个主节点(redis-master), 两个从节点(redis-slave1, redis-slave2)

主观下线

当 redis-master 宕机, 此时 redis-master 和三个哨兵之间的⼼跳包就没有了。此时, 站在三个哨兵的⻆度来看, redis-master 出现严重故障. 因此三个哨兵均会把 redis-master 判定为主观下线 (SDown)

客观下线

此时, 哨兵 sentenal1, sentenal2, sentenal3 均会对主节点故障这件事情进⾏投票. 当故障得票数 >= 配置的法定票数之后,此时意味着 redis-master 故障这个事情被做实了. 此时触发客观下线 (ODown)

选举出哨兵的 leader

接下来需要哨兵把剩余的 slave 中挑选出⼀个新的 master。 这个⼯作不需要所有的哨兵都参与. 只需要选出个代表 (称为 leader), 由 leader 负责进⾏ slave 升级到 master 的提拔过程。这个选举的过程涉及到 Raft 算法。

leader 挑选出合适的 slave 成为新的 master
挑选规则:

1. ⽐较优先级. 优先级⾼(数值⼩的)的上位. 优先级是配置⽂件中的配置项( slave-priority 或者replica-priority )。
2. ⽐较 replication offset 谁复制的数据多, ⾼的上位。
3. ⽐较 run id , 谁的 id ⼩, 谁上位。（随机的）

---

4 🍑小结+思考🍑

• 哨兵节点不能只有⼀个，否则哨兵节点挂了也会影响系统可⽤性。
• 哨兵节点最好是奇数个，⽅便选举 leader, 得票更容易超过半数。
• 哨兵节点不负责存储数据，仍然是 redis 主从节点负责存储。
• 哨兵 + 主从复制解决的问题是 “提⾼可⽤性”, 不能解决 “数据极端情况下写丢失” 的问题。
• 哨兵 + 主从复制不能提⾼数据的存储容量，当我们需要存的数据接近或者超过机器的物理内存, 这样的结构就难以胜任了。

为了能存储更多的数据, 就引⼊了集群，集群我们将放在下一篇文章介绍。