Redis-哨兵机制doctor环境搭建

接下来就需要将多个主从节点和哨兵节点部署到服务器上,目前手上只有一个服务器,只能在一台服务器上部署,但多个程序同时部署到一台机器上时,需要防止端口号冲突和相关配置文件的处理. 处理这个过程会非常麻烦,并且在实际应用的过程中,哨兵节点和数据节点只有部署在不同的机器上,才会真正发挥作用.

这里可以通过doctor虚拟机的方式解决这个问题.

虚拟机就是通过软件,在电脑上模拟出来得一些硬件,构造出来一些虚拟的电脑.

虚拟机存在的一个问题,就是比较消耗配置资源,目前手上的云服务器甚至电脑模拟不了几台虚拟机.

doctor就可以处理这个问题,他可以认为是一个"轻量级"的虚拟机.既然起到了虚拟机这样环境隔离的效果,还不消耗大量的硬件配置.

doctor也是目前后端开发中比较流行的组件.

下面进行docker环境搭建:

1.下载docker命令（ubuntu): 

snap install docker

2.下载docker-compose命令: 

apt install docker-compose

3.关掉之前开启的redis服务器程序:

根据开启时使用的不同的命令,关闭时使用对应的命令:

4.使用docker获取redis镜像:

docker pull redis:5.0.9

这一步若出现如下错误:

Error response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

请参考这篇博客:

https://blog.csdn.net/qingzhumuqingfeng/article/details/144094325

5.docker-compose容器编排

下面就要开始部署服务器了:

先创建一个redis文件夹,进入该文件夹;

再创建两个文件夹:redis-data,redis-sentinel.

6.编排redis主从节点:

这里我们创建3个节点,一个主节点,两个从节点.

进入redis-data文件夹:

创建并打开docker-compose.yml文件:

进行主从节点信息配置:

填入如下数据,保存并退出.

services:master:image: 'redis:5.0.9' //依赖的镜像container_name: redis-master //容器名字restart: always  //是否自动重启,设置永远允许command: redis-server --appendonly yes  //启动redis-server时,需要开启的命令行选项,此处开启aof文件ports:- 6379:6379 //端口映射slave1:image: 'redis:5.0.9'container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379 //这个是从节点,开启主节点容器名ports:- 6380:6379slave2:image: 'redis:5.0.9'container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6381:6379

端口映射: 

docker容器可以看成是一个轻量级的虚拟机,和外面的虚拟机各成一套体系,不会存在端口号冲突.  当外面的宿主机想要访问这个内部虚拟机的这个端口号的时候,可以通过端口映射的方法进行访问,

左边是外部宿主机的端口号,右边是虚拟机的端口号,

就是这个内部虚拟机的6379端口映射到外面宿主机的6379端口,当宿主机想要访问这个虚拟机的6379端口时,可以通过6379端口访问.

这个相当于这个虚拟机的6379端口映射到宿主机上的6380端口,当宿主机想要访问这个虚拟机的6379端口时,就可以通过6380端口访问了.

另一个同理.

7.启动节点程序

使用docker-compose up 命令,

若是docker-compose up -d命令,表示按照后台启动.

通过docker ps -a查询是否启动的redis服务器:

可以看到有一个主节点,两个从节点:

查询开放的端口号:netstat  -anp | grep  端口号:

登录一个redis客户端,查询相关信息:

8.启动哨兵节点

这里创建3个哨兵节点.

1. 先进入刚创建的redis-sentinel文件夹,创建并打开docker-compose.yml文件配置文件

2. 进入docker-compose.yml,添加配置项:

version: '3.7' 
services:sentinel1://哨兵节点1image: '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:  //哨兵节点2image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3:  //哨兵节点3image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- 26381:26379

3. 在redis-sentinel文件夹下 创建哨兵节点的配置文件:

 

保存并退出.

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 : ip地址,表示所有主机都可以访问

port 26379 : 哨兵节点 端口号

sentinel monitor redis-master redis-master 6379 2:

:哨兵节点要监控的主节点名redis-master ,(docker会自动根据域名解析端口映射)

主节点端口号 6379,

法定票数,当前只有3个哨兵节点,所以设置为2票

sentinel down-after-milliseconds redis-master 1000 :

哨兵节点发送心跳包,判定超时的超时时间,1000ms

4. 创建好后,再复制两份:命名为 sentinel2.conf ,sentinel3.conf:

现在就有3个配置文件了.

9.启动哨兵节点:

docker-compose up -d:按照后台进程启动

通过docker-compose logs命令查看哨兵节点的日志:

发现这里有报错:

意思是无法识别redis-master这个名字,是因为3个数据节点和这3个哨兵节点是在不同的局域网中的,不同的局域网无法进行数据访问,是不相通的.

这里需要使用docker-compose把两组服务器放到一个局域网中.

使用docker network ls命令查看当前存在的局域网:

最后面两个局域网是我们刚刚创建出来的两个:

接下来就是需要在创建3个数据节点后,会自动创建出来一个局域网,然后在创建3个哨兵节点的时候,不再创建新的局域网,而是让3个哨兵节点加入到已经创建的局域网中.

修改docker-compose.yml配置文件:

加上这几行配置:

networks:default:external:name: redis-data_default //注意这里的名字要和上面查到的数据节点所在的局域网名字一直

保存并退出.

然后重新启动容器:

先把容器关闭:

使用docker-compose down 命令关闭容器:

然后再重新启动:

再次查看日志:

已经正常启动服务器了.

这就完成启动服务器的启动了.

启动后打开配置文件再次查看:

查看剩余的两个配置文件,都是和原来不一样的,并且3个文件的数据修改的也是不同的,这也是为什么要给每个哨兵节点服务器配置一个conf文件的原因.

验证哨兵节点的功能:

终于配置好了服务器,接下来就要看看哨兵节点是否能发挥他们的功能了.

可以先查看当前启动的节点:

一共有6个,三个哨兵节点,3个数据节点.

现在主动停掉主节点:

再查看当前节点情况:

可以看到master节点已经处于停止状态了.

此时,哨兵节点应该已经采取行动了,接下来查看哨兵节点的日志:

查看哨兵节点3的日志:

可以看到这里有sdown命令和odown命令,

sdown: 代表主观认为主节点挂了,目前仅有一个哨兵节点任务主节点出故障了,此时还不能确定主节点是否是真的挂了;

odown: 代表客观下线,认为主节点处故障的哨兵节点达到了法定票数,

此时就要选一个从节点作为新的主节点:

看到这里主节点从172.18.0.4切换到了172.0.2,别的从节点也将以172.18.0.2作为主节点了.

下面尝试连接6379端口号的主节点,看是否还能连上:

这里看到已经无法连接了.

再尝试连接别的从节点:

连接6380端口的从节点,查看详细信息,发现他还是从节点,主节点的ip为172.18.0.2.

查看6381端口的信息:

可以看到6381端口号已经变成了主节点,连接的从节点有1个,因为原来的主节点挂了,还没重启,目前就剩两个节点了.

对其进行写操作:可以执行成功,说明他真的成为了主节点.

此时将刚才挂了的主节点再次启动起来:

连接客户端,查看相关日志:

发现该节点已经变成从节点了,其主节点ip为172.18.0.2

再看一下当前新的主节点的信息:

可以看到,此时已经接连了2个从节点了.