深入剖析 Redis 客户端：Sentinel 模式下的"寻址"与"感知"艺术
在 Redis 的高可用架构中，我们常常会思考一个问题：客户端（如使用 RedisTemplate 的 Java 应用）配置了哨兵模式后，它是如何知道主节点（Master）在哪里的？它也是像哨兵之间那样，全程依赖"发布订阅"机制吗？
这是一个非常硬核且容易产生误区的话题。许多开发者误以为客户端和哨兵通过同一个频道进行交互，但事实并非如此。
本文将带你拆解客户端底层的交互协议，厘清"初始寻找"与"感知变化"的本质区别。
误区澄清：并非全程依赖"发布订阅"
首先直接给出结论：客户端连接哨兵时，并不完全 是依靠发布订阅机制来获取主节点位置的，订阅的频道也绝不是 __sentinel__:hello。
客户端的交互逻辑分为两个截然不同的阶段：启动时的"问" 和 运行时的"听"。
阶段一：初始寻找 ------ 主动询问 (Active Query)
当你的 Java 应用启动，RedisTemplate 初始化时，它需要立刻知道谁是 Master，以便建立连接进行读写操作。
此时，如果客户端去订阅一个频道并傻傻等待广播，效率极低且不可控（如果没人发消息，应用难道一直阻塞等待吗？）。
因此，在启动阶段，客户端采用的是**主动"问"**的策略：
-
建立连接 ：客户端遍历配置文件中的
sentinel.nodes列表，尝试连接任意一个可用的哨兵节点。 -
发送指令：连接成功后，客户端会直接发送标准的 Sentinel API 命令：
Bash
SENTINEL get-master-addr-by-name <master-name> -
获取结果 ：哨兵收到命令后，会立即返回当前 Master 的 IP 和端口（例如
192.168.1.10:6379）。 -
直连 Master：客户端拿到地址，直接与 Master 建立连接，完成初始化。
结论：在起步阶段，靠的是同步的 API 查询，而非异步的发布订阅。
阶段二：感知变化 ------ 被动订阅 (Passive Subscribe)
连接建立并运行之后，如果 Redis 集群发生了故障转移（Failover），Master 换人了，客户端该如何知晓？
这时候，发布订阅（Pub/Sub）机制才正式登场。
但是，客户端订阅的频道不是 __sentinel__:hello。__sentinel__:hello 是哨兵之间用来"闲聊"的（交换彼此的 IP、RunID、配置版本等），客户端对这些内部琐事并不感兴趣。
客户端关注的是**"结果"**，因此它订阅的是哨兵专门用于对外公告故障转移的频道，其中最核心的是：
+switch-master
交互流程如下：
- 后台监听 ：客户端底层（如 Jedis/Lettuce）在连接哨兵时，会启动后台线程，订阅哨兵的一系列事件频道（包括
+sdown,+odown,+switch-master等）。 - 事件触发 ：一旦哨兵集群完成了故障转移，选出了新 Master，所有哨兵都会在
+switch-master频道发布一条消息。- 消息格式通常为：
old-master-ip old-port new-master-ip new-port
- 消息格式通常为：
- 自动切换：客户端收到这条消息后，会解析出新 Master 的地址。随即断开与旧 Master 的连接，并初始化与新 Master 的连接。
核心对比：两个频道的区别
为了彻底理清这个概念，我们将这两个容易混淆的频道做一个对比：
| 特性 | sentinel:hello | +switch-master |
|---|---|---|
| 角色 | 内部社交 | 对外公告 |
| 谁在听 | 哨兵听哨兵的 | 客户端（RedisTemplate）听哨兵的 |
| 内容 | "我是哨兵A，我的IP是...，我看到的Master配置是..." | "Master换人了！旧的是A，新的是B" |
| 目的 | 自动发现其他哨兵，组建/维护哨兵集群网络 | 通知客户端切流，防止请求打到死掉的旧节点 |
总结
RedisTemplate（以及大多数标准 Redis 客户端）在处理哨兵模式时，采用了一套**"动静结合"**的优雅策略：
- 刚启动时（急） ：使用 主动询问 (
get-master-addr-by-name)，追求快速、确定的结果。 - 运行中（稳） ：使用 被动订阅 (
+switch-master)，追求实时感知集群变化，实现自动故障转移。