前言
在 Redis 高可用架构中，哨兵（Sentinel）和Redis Cluster是两大主流方案，二者都能实现主节点故障自动转移，保障服务可用性。但很多开发者会疑惑：同样是主节点切换，为什么Redis Cluster 无需主动推送变更通知，客户端就能自动适配，而哨兵模式必须依靠主动通知客户端？
本文结合底层架构、交互流程、设计思想，完整拆解两种模式下客户端感知节点变更的核心原理、流程差异及设计考量，同时对比二者优缺点，帮你彻底理清背后逻辑。
一、前置认知：两种架构本质区别
在分析客户端感知逻辑前，首先要分清两种架构的底层形态，这也是所有差异的根源：
- 哨兵模式：基于一主多从的传统主从架构，属于非分片架构。整个 Redis 实例只有一个主节点负责读写，多个从节点做数据备份与读分流，哨兵仅作为独立监控组件，负责故障检测、主从切换。
- Redis Cluster：基于多主多从的分片集群架构。集群被划分为 16384 个哈希槽，不同主节点负责不同槽位的数据，每个主节点搭配从节点实现高可用，是去中心化的分布式架构。
架构不同，直接决定了客户端的连接逻辑、故障切换后的适配方式天差地别。
二、Redis Cluster：被动重定向，无需主动推送通知
2.1 集群内部：先完成拓扑同步
当集群中某个主节点宕机后，集群会通过投票选举出新的主节点，整个流程仅在集群节点内部完成，和客户端无任何交互：
- 新主节点完成身份升级，接管原主节点负责的哈希槽；
- 新主节点通过Gossip 协议向整个集群广播拓扑变更消息，告知所有节点：对应哈希槽已归属新主节点；
- 集群内所有节点收到广播后，更新本地维护的哈希槽-节点映射表，集群拓扑正式生效。
至此，集群内部已全部同步最新路由信息，等待客户端请求接入。
2.2 客户端：依靠 MOVED 重定向被动感知
Redis Cluster 客户端本地会缓存一份哈希槽与节点地址的映射关系，但客户端不会主动监听集群状态，而是依托请求触发被动更新，完整流程如下：
- 客户端根据本地缓存的槽位映射，将读写请求发送至旧主节点（此时旧主已降级为从节点，不再管理对应槽位）；
- 旧节点校验请求对应的哈希槽，结合集群最新拓扑，向客户端返回
MOVED slot 槽号 新主IP:端口重定向指令； - 客户端识别到
MOVED响应后，自动更新本地路由缓存； - 后续同槽位请求直接转发至新主节点，整个过程由客户端（Redisson、JedisCluster 等主流客户端）自动处理，业务代码完全无感知。
2.3 设计初衷：为何不主动向客户端推送变更？
Redis Cluster 采用被动感知设计，是去中心化架构的最优选择，核心原因两点：
- 规避客户端状态不一致问题
集群无法维护海量客户端连接与状态。如果主动推送拓扑变更，一旦网络波动导致推送失败，部分客户端会一直持有旧路由，引发数据访问异常。 - 被动重定向可靠性更高
无论客户端缓存是否过期，每次请求都会经过节点校验，通过一次重定向即可修正错误路由，不会出现永久失效的情况，容错性更强。
2.4 兜底补充
部分成熟客户端会增加定时全量拉取集群拓扑、连续多次重定向后主动刷新路由的兜底逻辑，进一步降低缓存失效影响，但核心机制依旧是被动重定向。
三、Redis 哨兵模式：必须主动推送，发布订阅是核心
3.1 哨兵架构的天然痛点
哨兵基于单主多从架构，客户端的连接逻辑非常简单：直连主节点。
- 客户端仅配置主节点 IP+端口，全程只和主节点交互，不会维护复杂的拓扑、槽位映射；
- 客户端完全不知道从节点地址，架构本身没有内置路由重定向能力。
一旦主节点宕机，哨兵完成主从切换后，旧主节点地址彻底失效。客户端会持续向旧地址发送请求，最终全部超时、报错，业务直接中断。客户端没有任何自主能力发现新主节点地址，这也是哨兵必须主动通知客户端的根本原因。
3.2 核心方案：哨兵发布订阅推送变更
哨兵借助 Redis 原生的发布/订阅（Pub/Sub）机制，将主从切换事件主动推送给客户端，这是哨兵模式实现高可用的唯一可靠方案。
3.2.1 哨兵内置事件频道
哨兵定义了一系列事件频道，用于对外推送集群状态，其中最核心的频道：
+switch-master：主节点发生切换，哨兵会在此频道发布新主节点的 IP、端口；- 其余辅助频道：
+odown（主节点客观下线）、+slave-reconf-done（从节点重配置完成）等，用于同步切换进度。
3.2.2 完整通知流程
- 客户端启动时，先连接所有哨兵节点，并订阅
+switch-master等核心事件频道； - 哨兵检测到主节点宕机，完成选举、主从切换后，立即在对应频道发布新主节点地址；
- 客户端监听到消息后，主动断开与旧主节点的连接，重新建立与新主节点的连接；
- 后续业务请求正常访问新主节点，实现切换无感知。
3.3 不主动通知的严重后果
如果客户端不订阅哨兵事件，无法接收主动推送，会出现以下问题：
- 业务持续报错：客户端一直请求已失效的旧主节点，服务不可用；
- 丧失高可用价值：主从切换本是为了故障自愈，却因客户端无法适配，必须人工修改配置重启服务；
- 轮询方案存在延迟：少数客户端采用定时轮询哨兵查询主节点地址的方式，会存在切换延迟，无法做到实时恢复。
四、两大架构客户端感知机制全面对比
| 对比维度 | 哨兵模式 | Redis Cluster |
|---|---|---|
| 底层架构 | 单主多从、非分片架构 | 多主多从、哈希槽分片集群 |
| 客户端连接方式 | 直连单一主节点，仅保存主节点地址 | 可直连任意集群节点，本地缓存槽位-节点映射 |
| 节点变更感知方式 | 哨兵通过 Pub/Sub主动推送新主地址 | 依靠节点MOVED重定向被动更新路由 |
| 客户端内置能力 | 无路由重定向逻辑，无法自主发现新节点 | 内置集群协议，自动处理重定向、刷新缓存 |
| 架构设计思想 | 中心化监控，依赖外部组件通知 | 去中心化集群，依靠请求交互自动修正 |
五、总结
- Redis Cluster：集群内部通过 Gossip 同步拓扑，客户端依靠
MOVED重定向被动更新路由。去中心化架构决定了它无需主动推送，靠请求交互即可保证路由准确性，对业务完全透明。 - 哨兵模式：基于传统单主架构，客户端无路由感知和重定向能力，必须依赖哨兵的发布订阅机制主动推送新主节点地址，才能实现故障自动恢复。
简单概括：Cluster 是“问路式”被动适配，哨兵是“传话式”主动通知。理解二者的底层架构差异，就能彻底掌握两种高可用方案的客户端交互逻辑，在实际项目中根据业务场景合理选型。