Redis 哨兵(Sentinel)

Redis Sentinel 相关名词解释

主从复制的问题

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

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

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

1. 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。
2. 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。

其中第一个问题是高可用问题，即 Redis 哨兵主要解决的问题。第二个问题是属于存储分布式的问留给 Redis 集群去解决。

人工恢复主节点故障

Redis主从复制模式下，主节点故障后需要进行的人工工作是比较繁琐的。

Redis 主节点故障后需要进行的操作

1）运维人员通过监控系统，发现 Redis 主节点故障宕机。

2）运维人员从所有节点中，选择一个从节点执行 slaveof no one，使其作为新的主节点。

3）运维人员让剩余从节点执行 slaveof {newMasterIp} {newMasterPort} 从新主节点开始数据同步。

4）更新应用方连接的主节点信息到 {newMasterIp} {newMasterPort}。

5）如果原来的主节点恢复，执行 slaveof {newMasterIp} {newMasterPort} 让其成为一个从节点。

上述过程可以看到基本需要人工介入，无法被认为架构是高可用的。而这就是 Redis Sentinel 所要做 的。

哨兵自动恢复主节点故障

当主节点出现故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

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

这里的分布式架构是指：Redis 数据节点、Sentinel 节点集合、客户端分布在多个物理节点上

Redis Sentinel 架构

Redis Sentinel 相比于主从复制模式是多了若(建议保持奇数) Sentinel节点用于实现监控数据节点，哨兵节点会定期监控所有节点(包含数据节点和其他哨兵节点)。针对主节点故障的情况，故障转移流程大致如下：

1）主节点故障，从节点同步连接中断，主从复制停止。

2）哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商，达成多数认同主节点故障的共识。这步主要是防止该情况：出故障的不是主节点，而是发现故障的哨兵节点，该情况经常发生于哨兵节点的网络被孤立的场景下。

3）哨兵节点之间使用 Raft 算法选举出一个领导角色，由该节点负责后续的故障转移工作。

4）哨兵领导者开始执行故障转移：从节点中选择一个作为新主节点，让其他从节点同步新主节点，通知应用层转移到新主节点。

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

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

安装部署(基于docker)

安装docker环境(Ubuntu)

docker 安装

检查卸载老版本 docker

ubuntu 下自带了 docker 的库，不需要添加新的源。

但是 ubuntu 自带的 docker 版本太低，需要先卸载旧的再安装新的。

注：docker 的旧版本不一定被称 为docker，docker.io 或 docker-engine 也有可能，所以我们卸载的命令为：

sudo apt-get remove docker docker-engine docker.io containerd runc

安装步骤

1.更新软件包

在终端中执行以下命令来更新 Ubuntu 软件包列表和已安装软件的版本:

sudo apt updatesudo apt upgrade

2.安装docker依赖

Docker 在 Ubuntu 上依赖一些软件包。执行以下命令来安装这些依赖:

sudo apt-get install ca-certificates curl gnupg lsb-release

3.添加Docker官方GPG密钥

执行以下命令来添加Docker官方的GPG密钥:

curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -

4.添加Docker软件源

行以下命令来添加Docker的软件源：

sudo add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"

5.安装docker

sudo apt-get install docker-ce docker-ce-cli containerd.io

6.配置用户组（可选）

默认情况下，只有root用户和docker组的用户才能运行Docker命令。我们可以将当前用户添加到docker组，以避免每次使用Docker时都需要使用sudo。命令如下：

sudo usermod -aG docker $USER

7.运行docker

我们可以通过启动docker来验证我们是否成功安装。命令如下：

systemctl start docker

8.安装工具

apt-get -y install apt-transport-https ca-certificates curl software-properties-common

9.验证是否成功

sudo docker run hello-world

10.查看版本和镜像

sudo docker versionsudo docker images

docker-compose安装

# ubuntusudo apt install docker-compose# centossudo yum install docker-compose

准备工作

1）停止之前的 redis-server

# 停⽌ redis-serversudo service redis-server stop# 停⽌ redis-sentinel如果已经有的话sudo service redis-sentinel stop

2）使用 docker 获取 redis 镜像

sudo docker pull redis

编排 redis 主从节点

1）编写 docker-compose.yml

创建 /root/redis/docker-compose.yml，同时 cd 到 yml 所在目录中。

注意：docker 中可以通过容器名字，作为 ip 地址，进行相互之间的访问

GNU nano 6.2docker-compose.ymlversion: '3.7'services:master:image: 'redis:5.0.9'container_name: redis-masterrestart: alwayscommand: redis-server --appendonly yesports:- '6379:6379'slave1:image: 'redis:5.0.9'container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- '6380:6379'slave2:image: 'redis:5.0.9'container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- '6381:6379'

2）启动所有容器

docker-compose up -d

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

3）查看运行日志

docker-compose logs

上述操作必须保证工作目录在 yml 的同级目录中,才能工作

4）验证

连接主节点

root@taeyeon:~/redis# redis-cli -p 6379127.0.0.1:6379> info replication# Replicationrole:masterconnected_slaves:2slave0:ip=172.18.0.4,port=6379,state=online,offset=238,lag=0slave1:ip=172.18.0.3,port=6379,state=online,offset=238,lag=1master_replid:ab428b92c96df020907fd1790bf388d56ffd0b90master_replid2:0000000000000000000000000000000000000000master_repl_offset:252second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:252

连接从节点

root@taeyeon:~/redis# redis-cli -p 6380127.0.0.1:6380> info replication# Replicationrole:slavemaster_host:redis-mastermaster_port:6379master_link_status:upmaster_last_io_seconds_ago:5master_sync_in_progress:0slave_repl_offset:322slave_priority:100slave_read_only:1connected_slaves:0master_replid:ab428b92c96df020907fd1790bf388d56ffd0b90master_replid2:0000000000000000000000000000000000000000master_repl_offset:322second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:322root@taeyeon:~/redis# redis-cli -p 6381127.0.0.1:6381> info replication# Replicationrole:slavemaster_host:redis-mastermaster_port:6379master_link_status:upmaster_last_io_seconds_ago:1master_sync_in_progress:0slave_repl_offset:406slave_priority:100slave_read_only:1connected_slaves:0master_replid:ab428b92c96df020907fd1790bf388d56ffd0b90master_replid2:0000000000000000000000000000000000000000master_repl_offset:406second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:1repl_backlog_histlen:406

编排 redis-sentinel 节点

也可以把 redis-sentinel 放到和上面的 redis 的同⼀个 yml 中进行容器编排。此处分成两组，主要是为了两方面：

• 观察日志方便
• 确保 redis 主从节点启动之后才启动 redis-sentinel。如果先启动 redis-sentinel 的话，可能触发额外的选举过程，混淆视听。(不是说先启动哨兵不行，而是观察的结果可能存在一定随机性)。

1）编写 docker-compose.yml

创建 /root/redis-sentinel/docker-compose.yml，同时 cd 到 yml 所在目录中

注意：每个目录中只能存在⼀个 docker-compose.yml 文件.

version: '3.7'services:sentinel1:image: 'redis:5.0.9'container_name: redis-sentinel-1restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel1.conf:/etc/redis/sentinel.confports:- '26379:26379'sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- '26380:26379'sentinel3:image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- '26381:26379'networks:default:external:name: redis_default

2）创建配置文件

创建 sentinel1.conf sentinel2.conf sentinel3.conf .三份文件的内容是完全相同的

都放到 /root/redis-sentinel/ 目录中

bind 0.0.0.0port 26379sentinel monitor redis-master redis-master 6379 2sentinel 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，修改文件内容，如果用一份文件，就可能出现修改混乱的情况

3）启动所有容器

docker-compose up -d

4）查看运行日志

docker-compose logs

5）观察 redis-sentinel 的配置 rewrite

再次打开哨兵的配置文件，发现文件内容已经被自动修改了。

GNU nano 6.2sentinel1.confbind 0.0.0.0port 26379sentinel myid 28433f3341363b97751daf01b5cf9c7f0198d37bsentinel deny-scripts-reconfig yes# Generated by CONFIG REWRITEdir "/data"sentinel monitor redis-master 172.18.0.2 6379 2sentinel down-after-milliseconds redis-master 1000sentinel config-epoch redis-master 0sentinel leader-epoch redis-master 0sentinel known-replica redis-master 172.18.0.3 6379sentinel known-replica redis-master 172.18.0.4 6379sentinel known-sentinel redis-master 172.18.0.7 26379 d5f3d90de013386e32a776a32955fe344a33a6d4sentinel known-sentinel redis-master 172.18.0.5 26379 67d5998c4a5e3bd8e26093d6dba83c5144341341sentinel current-epoch 0

三份文件里，配置内容是存在差异的。

重新选举

redis-master 宕机之后

手动把 redis-master 干掉

docker stop redis-master

观察哨兵的日志

可以看到哨兵发现了主节点sdown，进一步的由于主节点宕机得票达到 3/2，达到法定得票，于是 master 被判定为 odown。

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

接下来，哨兵们挑选出了一个新的 master。 在上图中是 172.22.04:6379 这个节点。此时对于 Redis 来说仍然是可以正常使用的。

redis-master 重启之后

手动把 redis-master 启动起来

docker start redis-master

观察哨兵日志

可以看到刚才新启动的 redis-master 被当成了 slave

+convent-to-slave slave 172.22.0.2:6379 172.22.0.2 6379 @ redis-master 172.22.0.4 6379

使用 redis-cli 也可以进一步的验证这一点

127.0.0.1:6379> info replication# Replicationrole:slavemaster_host:172.18.0.4master_port:6379master_link_status:upmaster_last_io_seconds_ago:1master_sync_in_progress:0slave_repl_offset:508612slave_priority:100slave_read_only:1connected_slaves:0master_replid:7631c271daacf2a9bfd9da4751d8df80d362109cmaster_replid2:0000000000000000000000000000000000000000master_repl_offset:508612second_repl_offset:-1repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:507047repl_backlog_histlen:1566

结论

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

选举原理

假定当前环境如上方介绍三个哨兵(sentenall,sentenal2,sentenal3)，一个主节点(redis-master)，两个从节点(redis-slavel,redis-slave2)。

当主节点出现故障，就会触发重新⼀系列过程。

1）主观下线

当 redis-master 宕机，此时 redis-master 和三个哨兵之间的心跳包就没有了。

此时，站在三个哨兵的角度来看，redis-master 出现严重故障因此三个哨兵均会把 redis-master 判定为主观下线(SDown)

2）客观下线

此时，哨兵sentenal1,sentenal2, sentenal3 均会对主节点故障这件事情进行投票，当故障得票数>=配置的法定票数之后

sentinel monitor redis-master 172.22.0.4 6379 2

在 这个地方配置的2，即为法定票数

此时意味着 redis-master 故障这个事情被做实了，此时触发客观下线(ODown)

3）选举出哨兵的 leader

接下来需要哨兵把剩余的 slave 中挑选出一个新的 master。这个工作不需要所有的哨兵都参与，只需要选出个代表(称为 leader)，由 leader 负责进行 slave 升级到 master 的提拔过程。

这个选举的过程涉及到 Raft 算法

假定一共三个哨兵节点,S1，S2，S3

1.每个哨兵节点都给其他所有哨兵节点，发起一个”拉票请求”(S1-> S2,S1-> S3,S2-> S1,S2->S3,S3 -> S1,S3 -> S2)

2.收到拉票请求的节点，会回复一个“投票响应响应的结果有两种可能，投 or 不投

比如 S1 给 S2 发了个投票请求,S2 就会给 S1返回投票响应
到底 S2 是否要投 S1 呢” />

这里的决定因素成了“网络延时”。网络延时本身就带有一定随机性

具体选出的哪个节点是 leader，这个不重要，重要的是能选出⼀个节点即可

4）leader 挑选出合适的 slave 成为新的 master

挑选规则：

1. 比较优先级，优先级高(数值小的)的上位，优先级是配置文件中的配置项( slave-priority 或者 replica-priority)
2. 比较 replication offset 谁复制的数据多，高的上位。
3. 比较 run id，谁的id小，谁上位

当某个 slave 节点被指定为 master 之后

1. leader 指定该节点执行 slave no one，成为 master
2. leader 指定剩余的 slave 节点，都依附于这个新 master

总结

上述过程都是”无人值守”，Redis 自动完成的。这样做就解决了主节点宕机之后需要人工干预的问题，提高了系统的稳定性和可用性

一些注意事项：

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

为了能存储更多的数据，就引入了集群