【Redis系列】哨兵模式

🚀 欢迎来到我的CSDN博客：Optimistic _ chen

✨ 一名热爱技术与分享的全栈开发者，在这里记录成长，专注分享编程技术与实战经验，助力你的技术成长之路，与你共同进步！

专栏	内容特色	适合人群
🔥C语言从入门到精通	系统讲解基础语法、指针、内存管理、项目实战	零基础新手、考研党、复习
🔥Java基础语法	系统解释了基础语法、类与对象、继承	Java初学者
🔥Java核心技术	面向对象、集合框架、多线程、网络编程、新特性解析	有一定语法基础的开发者
🔥Java EE 进阶实战	Servlet、JSP、SpringBoot、MyBatis、项目案例拆解	想快速入门Java Web开发的同学
🔥Java数据结构与算法	图解数据结构、LeetCode刷题解析、大厂面试算法题	面试备战、算法爱好者、计算机专业学生
🔥Redis系列	从数据类型到核心特性解析	项目必备

🚀我的承诺：

✅ 文章配套代码：每篇技术文章都提供完整的可运行代码示例

✅ 持续更新：专栏内容定期更新，紧跟技术趋势

✅ 答疑交流：欢迎在文章评论区留言讨论，我会及时回复（支持互粉）

🚀 关注我，解锁更多技术干货！
⏳ 每天进步一点点，未来惊艳所有人！✍️ 持续更新中，记得⭐收藏关注⭐不迷路 ✨

📌 标签:#技术博客 #编程学习 #Java #C语言 #算法 #程序员

前言

前面博客讲到的主从复制，让Redis数据库分化数据访问压力，性能得到优化；不足的是 从节点如果太多复制数据就会出现延时，最严重的是，主节点挂了，从节点不会自动升级为主节点，只能通过人工干预恢复。

哨兵（Sentinel）

因为Redis主从复制模式下，一旦主节点出现故障不能提供服务，需要人工切换，这对于以毫秒为单位的计算机来说，可能会对企业造成巨大损失。所以，Redis从2.8开始就提供了Redis Sentinel 节点来解决这个问题，实现Redis的高可用方案，在实际生产环境中提高系统的高可用性是非常有帮助的。

人工恢复主节点故障

运维人员通过监控程序发现Redis主节点宕机
在所有从节点中选择一个从节点slave1执行slaveof no one ，使其作为新主节点
程序员让剩余从节点执行 slaveof {newMasterIP} {newMasterPort}从新节点开始同步数据
更新应用方链接的主节点信息到{newMasterIP} {newMasterPort}
如果原来的主节点恢复功能，执行slaveof {newMasterIP} {newMasterPort}让其成为一个从节点

整个过程不仅需要人工干预，而且恢复效率也不理想，所以大佬认为该架构需要进化。

哨兵节点主动恢复主节点故障

当主节点出现问题时，Redis sentinel 能自动完成故障发现和转移故障 ，并通知应用方，提高系统高可用。

哨兵模式是一个分布式架构，内部包含若干个Sentinel 节点和Redis数据节点，每个哨兵节点对数据节点和其他哨兵节点进行监控。

当它发现节点不可达时，会对节点做下线处理。如果是主节点下线，首先它会和其他哨兵节点进行确认，该主节点是否下线；确认下线后，它们在其他从节点中会选举出来一个新的主节点，完成故障转移工作。同时整个过程实时通知给Redis应用方，并且完全自动化，不需要人工介入。

整体流程：

主节点故障，从节点同步连接中断，主从复制停止
哨兵节点通过监控发现主节点出现故障，哨兵节点与其他哨兵节点确认该主节点出现故障：防止出现网络问题，导致哨兵节点误判
哨兵节点使用Raft算法选举出一个新主节点，代替故障旧主节点工作，完成故障转移
其他从节点同步新主节点信息，通知应用方转移到新节点

哨兵节点的作用：

监控：定期检测Redis数据节点，其余哨兵节点是否可达
故障转移：实现从节点升级为主节点，并维护主从关系
通知：哨兵节点会将故障转移的结果通知给应用方

在Docker中部署哨兵模式

模拟哨兵模式，至少需要6个节点，部署在6个不同的服务器上，但是我们目前只是为了演示哨兵模式，所以我们部署在一个服务器上即可观察，同时我们得注意节点之间端口号、配置文件之间产生冲突。当然这个问题基于Docker来部署可以完美解决。

首先，停止之前的redis-server

powershell 复制代码

service redis-server stop
# 检查
ps aux|grep redis

# 停止redis-sentinel节点（如果有）
service redis-sentinel stop

# 使用docker拉取redis镜像
docker pull redis:5.0.9

拉取的镜像里面包含一个精简的Linux操作系统，并且安装了redis，只要基于这个镜像搭建一个容器就可以跑起来了。

拉取成功。

编排redis主从节点

首先安装docker-compose容器编排

powershell 复制代码

apt install docker-conpose

此处涉及的多个节点，都是单独作为一个单独的容器了。6个容器一一配置很浪费时间和精力，所以我们使用docker-compose来进行容器编排。

通过一个配置文件，把具体要创建的容器，每个容器运行的参数等等，在配置文件中描述清楚，后续我们可以通过该文件批量的操作这些容器了。

编写docker-compose.yml配置文件：创建/root/redis/docker-compose.yml，同时cd到yml所在目录中

powershell 复制代码

# 创建根目录
mkdir redis
# 创建数据节点目录
mkdir redis-data

# 进入数据节点目录
cd redis.data/
# 配置数据节点 docker-compser.yml 配置文件
vim docker-compser.yml

powershell 复制代码

# 启动所有容器
docker compose up -d

# 查看
docker pa -a

编排redis哨兵节点

确保redis主从节点启动之后才启动redis-sentinel. 如果先启动redis-sentinel的话,可能触发额外的选举过程,混淆视听。
首先编写docker-compose.yml文件：创建/root/redis-sentinel/docker-compose.yml，同时cd到yml所在目录

powershell 复制代码

# 创建哨兵节点目录
mkdir redis-sentinel 
# 进入哨兵节点目录
cd redis.data/
# 配置数据节点 docker-compser.yml 配置文件
vim docker-compser.yml

创建哨兵节点的配置文件，三份文件内容完全相同，都放到/root/redis-sentinal/目录中

powershell 复制代码

mkdir sentinel1.conf
# 配置
vim sentinel1.conf

cp sentinel1.conf sentinel2.conf 
cp sentinel1.conf sentinel3.conf

redis-sentinel 在运⾏中可能会对配置进⾏rewrite,修改⽂件内容.如果⽤⼀份⽂件,就可能出现修改

混乱的情况。所以保证每个哨兵节点都有配置文件。

启动哨兵节点

powershell 复制代码

docker compose up -d

现在我们已经对redis数据节点和哨兵节点完成配置，但是这两组服务是在不同的网络中，我们需要把此处的两组服务放到同一个网络中。

powershell 复制代码

docker network ls

此时需要对哨兵节点(docker-compose.yml)进行配置，让它在启动的时候直接加入到数据节点的网络中，而不是再创建新的网络。

powershell 复制代码

vim docker-compose.yml

接下来重新启动哨兵节点即可完成配置

powershell 复制代码

# 停止
docker compose down
# 启动
docker compose up -d

哨兵主节点选举

哨兵存在的意义是在redis主从结构出现问题的时候（主节点宕机）,哨兵节点自动帮助我们重新选举一个主节点代替之前挂了的节点，保证redis的高可用。

模拟主节点宕机：

powershell 复制代码

docker stop redis-master
docker pa -a

我们打开日志去观察：

哨兵发现主节点sdown，进一步选举投票4/2，达到法定得票，于是主节点被判定为odown

sdown(主观下线)：哨兵发现主节点没心跳了，主观认为下线
odown(客观下线)：多个哨兵都认为master下线了，那么确认下线

于是哨兵节点选举出一个新master：

重新启动redis-master后，发现它已经是一个从节点了。

选举原理

面对主节点下线，哨兵需要在从节点中选举一个新master，哨兵们选(Raf算法)一个代表（leader），由leader负责slave->master的升级过程。

每个哨兵节点都给其他所有哨兵节点,发起⼀个"拉票请求"
收到拉票请求的节点,会回复⼀个"投票响应".响应的结果有两种可能,投or不投
⼀轮投票完成之后,发现得票超过半数的节点,⾃动成为leader
leader 节点负责挑选⼀个slave成为新的master.当其他的sentenal发现新的master出现了,就说明选举结束了

整个过程简单来说就算"先下手为强"，谁先发出请求，谁就更可能成为leader

leader挑选合适的slave成为新的master

比较优先级：配置文件中的slave-priority/replica-priority数值小的升级
比较replication offset谁复制的多，谁升级
比较run id，谁id小谁升级

leader选中某个slave后，指定它执行slave no one 成为master，同时指定其他剩余的slave依附于新master.

总结：

哨兵节点不能只有⼀个.否则哨兵节点挂了也会影响系统可⽤性
哨兵节点不负责存储数据.仍然是redis主从节点负责存储
哨兵+主从复制解决的问题是"提⾼可⽤性",不能解决"数据极端情况下写丢失"的问题

完结撒花！🎉

如果这篇博客对你有帮助，不妨点个赞支持一下吧！👍
你的鼓励是我创作的最大动力～

✨ 想获取更多干货？ 欢迎关注我的专栏 → optimistic_chen

📌 收藏本文，下次需要时不迷路！

我们下期再见！💫 持续更新中......

悄悄说：点击主页有更多精彩内容哦～ 😊