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

Redis-哨兵

news 2025/7/15 9:07:21

概念

Redis Sentinel 相关名词解释

注意:

哨兵机制不负责存储数据,只是对其它的redis-server进程起到监控的作用
哨兵节点,也会搞一个集合,防止一个挂了

⼈⼯恢复主节点故障

用户监控:

实际开发中,对于服务器后端开发,监控程序,是很重要的

服务器长期运行,总会有一些意外,具体什么时候出现意外,无法预知,就写一个监控程序,来监控服务器的运行状态

监控程序,往往搭配报警程序

服务器出现状态异常,就触发报警程序,给程序员报警

程序员如何恢复?

1.先看看主节点能不能抢救,好不好抢救

2.如果主节点短时间内难以恢复,就挑一个从节点,设置为新的主节点

a)选中新的主节点,通过slaveof no one自立山头

b)把其他的从节点,修改slaveof发主节点IP port,连上新的主节点

c)告知客户端,让客户端能够连接新的主节点,完成修改操作

当之前挂的主节点,修改好之后,就可以作为一个新的从节点,挂到这组机器中

当然,这个人工干预的做法,十分繁琐

哨兵⾃动恢复主节点故障

当主节点出现故障时，RedisSentinel能⾃动完成故障发现和故障转移，并通知应⽤⽅，从⽽实现真正的⾼可⽤

Redis Sentinel 架构

这三个哨兵进程会监控现有的redis master和slave

(监控:这些进程之间,会建立tcp长连接,定期发送心跳包)

借助上述的监控机制,就可以及时发现,某个主机是否挂了

如果从节点挂了,无影响

如果主节点挂了,问题就大了,哨兵就要发挥作用了

此时,一个哨兵节点发现主节点挂了,不够,需要多个哨兵节点共同认同这件事,防止出现误判
主节点确实是挂了,这些哨兵节点,就会推举出一个leader,由这个leader负责从现有的从节点,挑选出一个作为新的主节点
挑选出新的主节点之后,哨兵节点,就会自动控制被选中的节点,执行slave no one,并且控制其它从节点,修改slaveof到新的主节点
哨兵节点会自动通知客户端程序,告知新的主节点是谁,后续客户端就会针对新的主节点进行写操作了

RedisSentinel核心功能

监控:Sentinel节点会定期检测Redis数据节点、其余哨兵节点是否可达

故障转移:实现从节点晋升（promotion）为主节点并维护后续正确的主从关系

通知:Sentinel节点会将故障转移的结果通知给应⽤⽅

安装部署(基于docker)

引入

这里涉及到六个节点,此时,只有一个云服务器,就在这里完成搭建

由于这些节点很多,相互之间容易打架,依赖的端口号/配置文件/数据文件...

如果直接部署,就需要去避开这些冲突,这种方式比较繁琐

下面用docker去解决上述问题:

docker可以认为是一个"轻量级"的虚拟机,起到了虚拟机这样的的隔离环境的效果,但是又没有吃很多的硬件资源,即使是比较拉跨的云服务器,也能构造出好几个这样的虚拟的环境

docker中关键概念"容器",看作一个轻量级的虚拟机

docker中"镜像"和"容器"的关系,相当于"可执行程序"和"进程"关系

拉取到的镜像,里面包含一个精简的linux操作系统,并且上面会安装redis,只要基于这个镜像创建一个容器跑起来,此时,redis服务器就搭建好了

准备工作

①安装docker和docker-compose

apt install docker-compose

②停⽌之前的redis-server

service redis-server stop

# 停⽌ redis-sentinel 如果已经有的话

service redis-sentinel stop

③ 使⽤docker获取redis镜像

#配置

vim /etc/docker/daemon.json

{

"registry-mirrors":["https://dockerpull.com"]

}

sudo systemctl daemon-reload

sudo systemctl restart docker

docker pull redis:5.0.9

编排redis主从节点

docker-compose进行容器编排

此处涉及多个redis server,也有多个redis哨兵节点

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

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

注意:

redis哨兵节点,有一个也是可以的,也能完全上面的功能

1.如果哨兵节点只要一个,自身是容易出现问题的

2.出现误判的概率比较高

毕竟网络传输是容易出现抖动或者延迟,丢包的,如果只有一个,出现问题的影响就很大

基本原则 :

在分布式系统中,避免"单点"

哨兵节点,最好奇数个,最少3个

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

1)创建三个容器,作为redis的数据节点(一主,两从)

2)创建三个容器,作为redis的哨兵节点

其实也是可以用一个yml文件,直接启动6个容器,但是如果同时启动,可能是哨兵先启动完成,数据节点后启动完成,哨兵可能就会认为数据节点挂了,会影响观察执行日志的过程

version: '3.7'
services:master:image: 'redis:5.0.9'container_name: redis-masterrestart: alwayscommand: redis-server --appendonly yesports:- 6379:6379slave1:image: 'redis:5.0.9'container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6380:6379slave2:image: 'redis:5.0.9'container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6381:6379
~

docker容器,可以理解成是一个轻量的虚拟机,在这个容器里,端口号和外面宿主机的端口号是两个体系

如果容器外面使用了5000端口,内部也可以使用,彼此不会冲突

三个容器,每个容器内部的端口号都是自成一派的,容器1的6379和2的6379之间是不会有冲突的,可以把两个容器视为两个主机

有的时候,希望在容器外面能够访问到容器里面的端口,就可以把容器内部的端口映射成宿主机的端口,后续防伪码宿主机的这个端口,就相当于在访问在访问对应容器的对应端口

站在宿主的角度,访问上述几个端口的时候,也不知道这个端口实际上一个宿主机的服务,还是来自容器内部的服务,只要正常去使用即可

此处不必写主节点ip,直接写主节点的容器名

容器启动之后,被分配的ip是啥也不知道

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

启动所有容器:

docker-compose up -d

查看正在运行的容器:

docker ps -a

编排 redis-sentinel节点

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:26379sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3: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

哨兵节点,会在运行过程中,对配置文件进行自动的修改

因此,就不能拿一个配置文件,给三个容器分别映射

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

redis-sentinel 在运⾏中可能会对配置进⾏rewrite,修改⽂件内容.

如果⽤⼀份⽂件,就可能出现修改混乱的情况

这里的票数,是为了更稳健的确认,当前的redis-server是否挂了,不能听一个哨兵的一面之词

docker的一个核心功能,能够进行端口的映射,容器内使用什么端口都行,但是映射出去之后,还是要确保端口不能重复

sentinel1:

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

sentinel2和sentinel3:

启动所有容器:

查看运⾏⽇志:

此处这个哨兵节点,不认识redis-master

docker-compose一下子启动了N个容器,此时N个容器处于同一个"局域网"中

可以使这个N个容器之间相互访问

三个redis-server节点,是一个局域网

三个哨兵节点,是另一个局域网,是新创建的

默认情况下,这两个网络不互通

解决方案:可以使用docker-compose把此处的两组服务给放到同一个局域网中

互通

docker network ls列出当前docker中的局域网

在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:26379sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3:image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- 26381:26379networks:default:external:name: redis-data_default