企业官网建设流程全解析

前面我们了解了Redis主从复制，主从架构解决了两个核心问题：数据热备份、读写分离，有效提升了查询并发能力和数据安全性。但是纯主从架构没有自动故障转移能力。一旦主节点宕机，从节点正常运行，但不会自动升级为主节点，整个集群写服务就会瘫痪，必须人工登录服务器手动更换，运维成本高、故障时间不可控。

为了解决这种问题，Redis 推出了哨兵机制。哨兵模式基于主从复制，额外增加了：节点监控、自动故障发现、自动主从切换、客户端通知的功能。

二、哨兵模式核心概念与架构

2.1 什么是哨兵？

Sentinel（哨兵）是 Redis 的独立监控进程，不存储业务数据，只负责监控主从节点状态、处理故障转移。

哨兵本身也是集群部署，保证自身高可用，避免单点故障。

2.2 标准生产架构（1主2从3哨兵）

标准部署：1 个 Master（写节点）2 个 Slave（读节点、备份节点）3 个 Sentinel（监控、投票、故障转移）

为什么哨兵必须部署奇数个？

因为故障转移需要半数以上投票，奇数可以避免平票、保证选举结果唯一。

2.3 哨兵四大核心功能

1. 监控

哨兵持续心跳检测 Master、Slave 节点，实时监听节点在线状态、运行状态。

2. 消息通知

节点异常、故障切换完成后，哨兵主动通知客户端新的主节点地址，业务无需改配置。

3. 自动故障转移

主节点宕机后，哨兵自动完成：重新选出主节点、从库升级成主节点、修改其他从库指向、原主库重启后变为从库。

4. 配置提供者

客户端连接哨兵集群，获取当前集群真实主节点地址（哨兵集群内部维护着集群的最新状态，返回当前存活的真正主节点的IP和端口号），不需要硬编码 （代码中不用写死主节点地址，只是主从复制则只能写死）Redis 地址。

三、哨兵核心工作原理（重点）

3.1 两种下线状态

1. 主观下线

单个哨兵节点 ping 不通主节点，超过超时时间，单方面判定节点下线。

流程：每个哨兵节点会隔1s向Redis主从节点发送PING心跳检测，如果超过配置的超时时间，哨兵节点一直收不到PONG回复，当前该哨兵节点就会认为该节点宕机。

仅仅是单个哨兵认为挂了，不触发故障转移。

2. 客观下线

当超过半数哨兵判定主节点主观下线，才会标记为客观下线。

只有客观下线，才会触发自动故障转移。

3.2 故障转移完整流程

1. 心跳检测失败：Master 宕机，哨兵检测心跳超时

2. 多哨兵投票确认：半数以上哨兵确认宕机，标记客观下线

3. 哨兵领导者选举：首先在3个哨兵中选出一个负责人，专门执行切换工作

4. 最优从节点选举（选新主）：按照规则挑选最健康的从节点升级为主节点

5. 升级新主：从节点执行slaveof no one，变成可写主节点

6. 其他从节点重新挂载：剩余从库自动跟随新主节点

7. 原主节点降级：旧的主节点重启后，自动变成从节点

8. 推送新配置给客户端：业务自动切换新主节点，业务无感（客户端连接哨兵集群，哨兵集群维护着集群的最新状态，返回当前存活的主节点的IP和端口号，所以业务无感）

3.3 新主节点选举规则（面试高频）

哨兵不会随机选从库，有严格优先级：

1，优先选择优先级高（replica-priority 数值越小，优先级越高，可配置，如果设置为0，永远不可能被升级成主节点）

,2，优先级一致，选择数据同步偏移量最大，最大可能的保证数据的完整性。

3，依然一致，选择运行ID最小的节点（redis每次启动实例都会生成一个40位随机的runId，对字符串你做字典序比较，runId更小生出，属于兜底逻辑，一般用不到）

四、手把手搭建 Redis 哨兵模式

我们这里使用docker来进行部署。docker利用linux内核技术，隔离出独立的运行环境（容器），每个容器内部只能跑一个redis进程，每个容器有自己独立的IP，端口号，网卡，独立文件系统，独立进程，可以互相访问。

这里使用两个yml文件，一个yml文件创建3个数据节点，用来存数据，另外一个yml文件创建三个哨兵节点。

首先创建各自的目录

再在各自的目录下面创建docker-compose.yml文件，后续直接d

ocker-compose up -d命令启动三个容器。

数据节点配置信息如下，启动后会自动挂载，不用再单独写配置文件

启动三个数据节点，一个命令直接启动三个数据节点

接下来配置哨兵节点的docker-compose.yml文件

这里面就具体配置的作用如下：

主要负责四件事：拉取redis镜像，启动哨兵程序，把本地三个独立的哨兵配置文件挂载进容器（配置文件具体写在外部），映射宿主机的不同端口，避免三个哨兵端口冲突。加入同一个docker网络，让哨兵能解析redis-master容器名（docker-compose文件启动时会自动生成一个网络，文件名格式为 文件夹名_default，不同的yml文件生成完全隔离的不同网桥，一个网桥对应一套DNS解析服务，容器名类比成内网域名，networks配置就是为了加入到数据主节点所在的网络，方便进行网络通信）

接下来给每个哨兵节点配置配置文件，以及配置项含义

五、哨兵模式优缺点

6.1 优点

1，实现自动故障转移：解决主从架构无法故障转移的问题

2，高可用：哨兵集群无单点故障（单个哨兵节点宕机不影响工作）

3，支持读写分离：读压力分摊到从库

4，运维简单、资源占用低：哨兵进程极轻量

5，客户端自动感知切换：无需改配置、无需重启服务

6.2 缺点（生产核心短板）

1，不支持数据分片：所有节点存储全量数据，无法扩容内存容量

2，容量受单节点内存限制：数据量大后无法横向扩展

3，依然存在主从延迟：异步复制，部分场景可能会导致短暂数据不一致

六、生产高频踩坑与解决方案

坑点1：哨兵部署偶数节点

偶数节点容易出现平票，无法触发故障转移，生产必须3哨兵奇数部署。

坑点2：防火墙/端口未开放

哨兵之间需要互通、哨兵与所有主从互通，端口不通会导致误判宕机。

坑点3：主从延迟导致选主数据丢失

网络抖动时部分从库数据旧，优先保证偏移量最新的节点升级，减少丢失风险。

坑点4：客户端直连Redis节点

故障切换后IP变化，客户端必须连接哨兵动态获取主节点地址。

七、生产最佳实践

1，生产固定架构：1主2从3哨兵

2，哨兵节点独立部署，不与业务Redis抢资源

3，合理配置心跳超时时间，避免网络抖动误切换

4，读写分离：写主库、读从库，减轻主库压力

5，开启RDB+AOF双持久化，最大程度保证数据安全

6，监控哨兵切换日志、主从偏移量、节点上下线记录

八、总结

哨兵模式是主从架构的增强版高可用方案，它解决了主从架构不能自动故障转移的致命问题。

但哨兵不支持数据分片扩容，无法应对海量数据的场景。如果业务数据量大、QPS高，需要进一步扩展为 Redis Cluster 分片集群。