当前位置：首页 > ai >正文

Redis 哨兵

ai 2025/5/11 7:59:22

哨兵机制

名词	逻辑结构	物理结构
主节点	Redis 主服务	一个独立的 redis-server 进程
从节点	Redis 从服务	一个独立的 redis-server 进程
Redis 数据节点	主从节点	主节点和从节点的进程
哨兵节点	监控 Redis 数据节点的节点	一个独立的 redis-sentinel 进程
哨兵节点集合	若干哨兵节点的抽象组合	若干 redis-sentinel 进程
Redis 哨兵(Sentinel)	Redis 提供的高可用方案	哨兵节点集合和 Redis 主从节点
应用方	泛指一个或多个客户端	一个或多个连接 Redis 的进程

哨兵机制，是通过独立的进程来体现的，和之前的 redis-server 是不同的进程

redis-sentinel 不负责存储数据，只是对其他的 redis-server 进程起到监控的效果

通常哨兵节点也会形成一个集合（多个哨兵节点构成最好是奇数个，便于选举）——>

1）如果哨兵节点只有一个也是可以的，但是如果哨兵节点挂了，后续 Redis 主节点也挂了，就无法进行自动的主从复制恢复过程

2）出现误判的概率高，网络传输数据容易出现抖动或者丢包

Redis 哨兵核心功能：

1）监控

2）自动的故障转移

3）通知

恢复 Redis 主从复制

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

1）作为主节点的备份，一旦主节点出现故障不可达的情况，从节点可以晋升成主节点，并且保证数据尽量不丢失（主从复制表现为最终一致性）

2）从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上

同时也存在以下问题：

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

2）主节点可以将读请求分散出去，但是写请求是无法被分担的，还是受到单机限制

问题 1）是高可用问题，即 Redis 哨兵解决的问题

问题 2）是属于存储分布式的问题，留给 Redis 集群去解决

人工恢复

1）选择一个从节点，执行 slaveof no one，使其成为新的主节点

2）让其余的从节点，执行 slaveof{newMasterIp}{newMasterPort}，从新的主节点开始同步数据

3）更新的客户端的配置到{newMasterIp}{newMasterPort}

4）如果主节点恢复，执行 slaveof{newMasterIp}{newMasterPort}，让其成为一个从节点

自动恢复

当主节点出现故障，Redis Sentinel 能自动地完成故障发现和故障转移，并通知客户端，实现高可用性

Redis Sentinel 是一个分布式架构，包含若干个 Sentinel 节点和 Redis 数据节点

此处的分布式是指 Redis 数据节点，Sentinel 节点集合，客户端分布在多个物理节点上，与 Redis Cluster 分布式不同

1）哨兵节点通过定期监控发现主节点出现故障，哨兵节点之间进行协商，达成多数认同主节点故障的共识（防止哨兵节点被网络孤立）

2）哨兵节点推举出一个新的 leader，由这个 leader 负责从现有的从节点中，挑选一个作为新的主节点

3）挑选出新的主节点后，哨兵节点会自动控制被选中的节点，执行 slaveof no one，并且控制其他的从节点，修改 slaveof 到新的主节点上

4）哨兵节点会通知客户端，告知新的主节点是谁，并且后续客户端再进行写操作，就会针对新的主节点进行操作了

使用 Docker 搭建环境

以下以设置三个哨兵节点和三个 Redis 数据节点为例：

按理说，上述的六个节点是要部署到六个不同的服务器主机上的

但是只有一个云服务器，如果都部署到一台云服务器上，会导致不同节点依赖的端口号/配置文件/数据文件 ... 冲突

虚拟机：通过软件，在电脑上模拟出另外的一些硬件（构造了一个虚拟的电脑）

docker 一个“轻量化”的虚拟主机

docker 安装

docker 安装

sudo apt-get update

sudo apt-get install docker.io

docker-compose 基于 docker 的容器编排工具（docker “容器“”：可以看做一个轻量级的虚拟机）

一个机器上可以通过 docker 创建出多个容器，使用 docker-compose 可以比较方便的管理一组 docker 容器

docker-compose 安装

apt install docker-compose

可通过命令行输入 docker ,docker-compose 检验是否安装完成

1）安装 docker 和 docker-compose

2）停止之前的 redis 服务器

3）使用 docker 获取到 redis 镜像 docker pull redis:5.0.9

git pull 使用 git 从中央仓库拉取代码

docker pull 使用 docker 从中央仓库（默认是从 docker hub）来拉取镜像

搭建 redis 哨兵环境

基于 docker 搭建哨兵环境，docker-compose 来进行容器编排

每个 redis server 或者每个 redis 哨兵节点都是作为一个单独的容器

通过一个配置文件，把具体要创建的哪些容器，每个容器的具体参数描述清楚，后续通过一个简单的命令，就能批量的启动 / 停止这些容器了

此处使用 yml 这样的格式来作为配置文件

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

mkdir redis

cd redis

mkdir redis-data

mkdir redis-sentinel

cd redis-data/

vim docker-compose.yml

image：镜像版本

container_name：容器名

restart：在出现故障时尝试自动重启

command：redis 相关配置

在配置从节点时，不必直接写主节点的IP，直接写主节点的容器名（容器启动后，分配的IP是未知的），也可以配置静态IP

容器名类似域名一样，docker 自动进行域名解析，得到对应的 ip

port：端口映射

docker 容器可以理解成一个轻量型的虚拟主机，在容器里，端口号和外面宿主机的端口号彼此不会冲突

希望在容器外面能够访问到容器里面的端口号，可以把容器内部的端口映射到宿主机的端口，后续访问宿主机的这个端口时，就相当于是访问对应容器的对应端口 ——> 类似 NAT

两个容器可以视为两个主机，容器1 和容器2 同时使用 6379 端口，不会冲突

docker ps - a

查看所有 docker 容器

redis-cli -p 6379

info replication

查看 redis 服务器情况

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

cd ..

cd redis-sentinel/

vim docker-compose.yml

vim sentinel1.conf

cp sentinel1.conf sentinel2.conf

cp sentinel1.conf sentinel3.conf

初始情况下，这三个文件的内容可以是一样的

1）绑定的 IP 地址，允许其他节点进行访问

2）在容器内部使用的端口

3）告诉哨兵节点，需要监控哪个 redis 服务器 redis-master为容器名，实际需要容器 IP，此处 docker 自动进行域名解析 2 为法定票数，判断节点是否挂掉

4）心跳包的超时时间

docker-compose up -d

按照后台进程的方式进行启动

docker-compose logs

查看日志

docker-compose 一下启动 N 个容器，此时 N 个容器都处于一个“局域网”中，N 个容器键可以互相访问

三个 redis-server 节点和三个哨兵节点是不同的局域网，互不相同 ——>

使用 docker-compose 把两组服务放到同一个局域网中

先启动了三个 redis server 节点，相当于是创建了一个局域网

再启动后面的三个哨兵节点，直接让这三个节点加入到上面的局域网中

在 sentinel 下的 docker-compose.conf 加入以下配置