客户端如何发现主库
在哨兵方案里，客户端不应写死主库地址，而是配置一组哨兵地址，由哨兵帮忙定位当前主库。标准做法是：连接哨兵列表，用 SENTINEL GET-MASTER-ADDR-BY-NAME 拿到主库的 ip 与端口，再连主库；同时订阅哨兵的事件频道监听 +switch-master，或在连接出错后重新查询，以便在主库变更后刷新连接池。主流客户端库大多内置哨兵模式，手写实现容易漏掉事件订阅与连接重建这两个环节。
基本信息
| 输入 | 哨兵地址列表 + master 名称 + 认证信息 |
|---|---|
| 查询命令 | SENTINEL GET-MASTER-ADDR-BY-NAME |
| 感知方式 | 订阅 +switch-master，或周期性重新查询 |
| 前置要求 | 所用客户端库支持哨兵模式 |
| 冗余 | 至少配置两台以上哨兵地址 |
典型使用场景
- 使用哨兵做高可用的业务系统接入 Redis，避免单点地址
- 切换期间快速恢复：连接失败后重新查询主库并重建连接池
- 就绪探针与健康检查：把「能查到主库且能连通」作为检查项
- 多语言技术栈统一接入方式，避免各语言各写一套发现逻辑
- 切换演练时验证客户端从感知到恢复的实际耗时
接入与验证
接入与验证
# 客户端配置（伪代码）：
# sentinel_nodes: [10.0.0.31:26379, 10.0.0.32:26379, 10.0.0.33:26379]
# master_name: mymaster
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster # 确认能查到主库
redis-cli -p 26379 SUBSCRIBE +switch-master # 验证事件是否可达
redis-cli -p 26379 SENTINEL SENTINELS mymaster # 确认哨兵之间已互相发现接入检查项
| 检查项 | 期望状态 | 常见问题 |
|---|---|---|
| 哨兵地址数量 | 至少两台 | 只配一台，哨兵故障后无法发现主库 |
| 主库查询结果 | 能返回 ip 与端口 | 名称拼错时返回空值而不是报错 |
| 事件订阅 | 能收到 +switch-master | 只靠周期轮询，切换感知慢 |
| 连接池 | 旧连接能被淘汰 | 半死连接长期占用，请求间歇失败 |
客户端缓存主库地址是必要的，但缓存必须有失效手段：收到切换事件、连接报只读错误（READONLY）或被重定向时，都应触发一次重新查询，重新建立到新主库的连接。