Docker安装Redis哨兵

目录

Redis哨兵

一、哨兵模式的主要概念和组件

二、哨兵模式的工作流程

三、哨兵配置流程

1、创建Redis哨兵配置文件

2、启动哨兵

3、命令解读

4、 查看哨兵是否正常启动

5、测试主机宕机

四、哨兵运行流程

五、哨兵选举算法

六、哨兵使用建议

---

Redis哨兵

Redis哨兵模式（Sentinel Mode）是一种用于实现高可用性和自动故障转移的Redis架构。在哨兵模式中，有一个或多个哨兵进程监控着主服务器和从服务器的状态，并在主服务器宕机时自动将其中一个从服务器升级为新的主服务器，以保障系统的可用性。

一、哨兵模式的主要概念和组件

1、主服务器（Master）：主服务器是Redis集群中的核心组件，负责处理写操作和同步数据给从服务器。

2、从服务器（Slave）：从服务器复制主服务器的数据，并在主服务器故障时提供读服务。从服务器可以有多个。

3、哨兵（Sentinel）：哨兵是一个独立的进程，负责监控主服务器和从服务器的健康状态。每个哨兵都会定期向集群中的其他哨兵询问主服务器和从服务器的状态，并通过选举机制选择新的主服务器。

4、哨兵配置文件（sentinel.conf）：哨兵使用一个专用的配置文件来指定监控的主服务器和从服务器，以及进行故障转移所需的配置信息。

二、哨兵模式的工作流程

• 当一个哨兵发现主服务器不可用时，它会与其他哨兵进行协商并选择一个新的主服务器。
• 选举出的新主服务器会被通知，并开始接收客户端的写操作。
• 其他哨兵和从服务器会重新配置自己，将新的主服务器作为复制的目标。
• 当原来的主服务器恢复时，它会变成新的从服务器，并开始复制新的主服务器的数据。

哨兵模式作用

主从监控：监控主从redis库运行是否正常

消息通知：哨兵可以将故障转移的结果发送给客户端

故障转移：如果Master异常，则会进行主从切换，将其中一个Slave作为新Maste

配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

三、哨兵配置流程

1、创建Redis哨兵配置文件

首先，创建一个用于配置Redis哨兵的配置文件sentinel.conf

sentinel.conf文件详情

#是否后台运行，如果命令里加参数 -d 就不用修改了
daemonize no

#是否开启安全保护模式
protected-mode no

#监听的端口
port 26379

# 日志文件路径
logfile ""

#pid文件路径
pidfile /var/run/redis-sentinel.pid

#工作目录
dir /tmp

# 用于添加对指定主服务器的监控的命令。
# master-name: 主服务器的名称，需要在整个哨兵集群中唯一。
# ip: 主服务器的IP地址或域名。redis-port: 主服务器的Redis端口。
# quorum: 哨兵投票数，即在故障转移时需要的最小投票数。
sentinel monitor    


# 用于为指定的主服务器设置密码的命令
# master-name: 主服务器的名称。
# password: 设置的密码。
sentinel auth-pass  

#指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel down-after-milliseconds  


#表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel[parallel-syncs  


#故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel failover-timeout  

#配置当某一事件发生时所需要执行的脚本
sentinel notification-script   

#客户端重新配置主节点参数脚本
sentinel client-reconfig-script  

这里设置3个哨兵都配置在6379这台服务器里

26379哨兵配置文件，另外两个是一样的

protected-mode no
port 26379
pidfile /var/run/redis-sentinel26379.pid
logfile "/var/log/redis/26379.log"
dir "/data"
sentinel monitor mymaster 192.168.200.129 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 60000

2、启动哨兵

docker run -d \
--name sentinel-26379 \
-v /usr/local/redis/sentinel/conf/sentinel26379.conf:/etc/redis/sentinel.conf \
-v /usr/local/redis/sentinel/data/26379data:/data \
-v /usr/local/redis/sentinel/log:/var/log/redis \
-p 26379:26379 \
--restart=always \
redis:7.2 redis-sentinel /etc/redis/sentinel.conf
 
 
 docker run -d \
--name sentinel-26380 \
-v /usr/local/redis/sentinel/conf/sentinel26380.conf:/etc/redis/sentinel.conf \
-v /usr/local/redis/sentinel/data/26380data:/data \
-v /usr/local/redis/sentinel/log:/var/log/redis \
-p 26380:26380 \
--restart=always \
redis:7.2 redis-sentinel /etc/redis/sentinel.conf

docker run -d \
--name sentinel-26381 \
-v /usr/local/redis/sentinel/conf/sentinel26381.conf:/etc/redis/sentinel.conf \
-v /usr/local/redis/sentinel/data/26381data:/data \
-v /usr/local/redis/sentinel/log:/var/log/redis \
-p 26381:26381 \
--restart=always \
redis:7.2 redis-sentinel /etc/redis/sentinel.conf

3、命令解读

-d：将容器置于后台运行。

--name sentinel-26379：为容器指定一个名称，这里是 sentinel-26379。

-v /usr/local/redis/sentinel/conf/sentinel26379.conf:/etc/redis/sentinel.conf：将宿主机上的 Redis Sentinel 配置文件 sentinel26379.conf 挂载到容器内的 /etc/redis/sentinel.conf 路径上，以供容器读取配置信息。

-v /usr/local/redis/sentinel/data/26379data:/data：将宿主机上的 Redis Sentinel 数据目录 26379data 挂载到容器内的 /data 路径上，以便容器可以读写数据。

-v /usr/local/redis/sentinel/log:/var/log/redis：将宿主机上的 Redis Sentinel 日志目录 log 挂载到容器内的 /var/log/redis 路径上，以便容器可以将日志写入此目录。

-p 26379:26379：将宿主机的 26379 端口映射到容器的 26379 端口，以便可以从外部访问 Redis Sentinel。

--restart=always：在容器意外停止时自动重启容器。

redis:7.2：使用 Redis 7.2 镜像作为容器的基础镜像。

redis-sentinel /etc/redis/sentinel.conf：指定容器启动时运行的命令，这里是启动 Redis Sentinel 进程并使用 /etc/redis/sentinel.conf 配置文件。

 分别创建配置文件目录开启容器

 

 先启动redis容器，再启动哨兵

4、 查看哨兵是否正常启动

docker exec -it sentinel-26379 bash

redis-cli -p 26379

info Sentinel

进入6379主库，正常运行，并有3680和6381两个从库

5、测试主机宕机

docker stop redis6379

查看6380还是从机

查看6381变成了主机

从新启动redis6379，他将变成6381的从机

四、哨兵运行流程

1、哨兵正常运行

2、SDown主观下线

SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度。

3、ODown客观下线

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉

4、选举出领导者哨兵（兵王）

当主节点被判断客观下线以后，各个哨兵节点会进行协商先选举出一个领导者哨兵节点（兵王)并

由该领导者节点也即被选举出的兵王进行failover(故障迁移)

兵王算法：监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法。Raft算法的基本思路是先到先得:即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。

5、由兵王开始推动故障切换流程并选出一个新master

五、哨兵选举算法

选举新的master：

1、redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)。

2、复制偏移位置offset最大的从节点。

3、最小Run ID的从节点字典顺序，ASCII码。

从机拜新主机：

1、执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点。

2、Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master点。

3、Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave

旧主机拜新主机：

1、将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点。

2、Sentinel leader会让原来的master降级为slave并恢复正常工作。

六、哨兵使用建议

1、哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。

2、哨兵节点的数量应该是奇数。

3、各个哨兵节点的配置应一致。

4、如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射。

5、哨兵集群＋主从复制，并不能保证数据零丢失。