深入剖析 Redis 客户端：Sentinel 模式下的“寻址”与“感知”艺术

深入剖析 Redis 客户端：Sentinel 模式下的“寻址”与“感知”艺术

在 Redis 的高可用架构中，我们常常会思考一个问题：客户端（如使用 RedisTemplate 的 Java 应用）配置了哨兵模式后，它是如何知道主节点（Master）在哪里的？它也是像哨兵之间那样，全程依赖“发布订阅”机制吗？

这是一个非常硬核且容易产生误区的话题。许多开发者误以为客户端和哨兵通过同一个频道进行交互，但事实并非如此。

本文将带你拆解客户端底层的交互协议，厘清“初始寻找”与“感知变化”的本质区别。

误区澄清：并非全程依赖“发布订阅”

首先直接给出结论：客户端连接哨兵时，并不完全是依靠发布订阅机制来获取主节点位置的，订阅的频道也绝不是 __sentinel__:hello。

客户端的交互逻辑分为两个截然不同的阶段：启动时的“问” 和 运行时的“听”。

阶段一：初始寻找 —— 主动询问 (Active Query)

当你的 Java 应用启动，RedisTemplate 初始化时，它需要立刻知道谁是 Master，以便建立连接进行读写操作。

此时，如果客户端去订阅一个频道并傻傻等待广播，效率极低且不可控（如果没人发消息，应用难道一直阻塞等待吗？）。

因此，在启动阶段，客户端采用的是**主动“问”**的策略：

1. 建立连接：客户端遍历配置文件中的 sentinel.nodes 列表，尝试连接任意一个可用的哨兵节点。

2. 发送指令：连接成功后，客户端会直接发送标准的 Sentinel API 命令：

   Bash

   SENTINEL get-master-addr-by-name <master-name>
   

3. 获取结果：哨兵收到命令后，会立即返回当前 Master 的 IP 和端口（例如 192.168.1.10:6379）。

4. 直连 Master：客户端拿到地址，直接与 Master 建立连接，完成初始化。

结论：在起步阶段，靠的是同步的 API 查询，而非异步的发布订阅。

阶段二：感知变化 —— 被动订阅 (Passive Subscribe)

连接建立并运行之后，如果 Redis 集群发生了故障转移（Failover），Master 换人了，客户端该如何知晓？

这时候，发布订阅（Pub/Sub）机制才正式登场。

但是，客户端订阅的频道不是 __sentinel__:hello。__sentinel__:hello 是哨兵之间用来“闲聊”的（交换彼此的 IP、RunID、配置版本等），客户端对这些内部琐事并不感兴趣。

客户端关注的是**“结果”**，因此它订阅的是哨兵专门用于对外公告故障转移的频道，其中最核心的是：

+switch-master

交互流程如下：

1. 后台监听：客户端底层（如 Jedis/Lettuce）在连接哨兵时，会启动后台线程，订阅哨兵的一系列事件频道（包括 +sdown, +odown, +switch-master 等）。
2. 事件触发：一旦哨兵集群完成了故障转移，选出了新 Master，所有哨兵都会在 +switch-master 频道发布一条消息。
   • 消息格式通常为：old-master-ip old-port new-master-ip new-port
3. 自动切换：客户端收到这条消息后，会解析出新 Master 的地址。随即断开与旧 Master 的连接，并初始化与新 Master 的连接。

核心对比：两个频道的区别

为了彻底理清这个概念，我们将这两个容易混淆的频道做一个对比：

总结

RedisTemplate（以及大多数标准 Redis 客户端）在处理哨兵模式时，采用了一套**“动静结合”**的优雅策略：

1. 刚启动时（急）：使用 主动询问 (get-master-addr-by-name)，追求快速、确定的结果。
2. 运行中（稳）：使用 被动订阅 (+switch-master)，追求实时感知集群变化，实现自动故障转移。