sentinel get-master-addr-by-name 命令必须发送至 sentinel 进程（默认端口 26379），而非 redis 实例（6379）；master_name 必须与 sentinel monitor 配置第二项完全一致，返回两元素数组（ip 和端口），是获取当前主节点唯一可靠方式。
SENTINEL get-master-addr-by-name 必须发给 Sentinel 端口
直接连 Redis 主/从节点（如 redis-cli -h 10.0.1.5 -p 6379）执行该命令，必然失败——ERR Unknown subcommand or wrong number of arguments for 'replication' 或无响应。这不是配置错，是命令根本不在 Redis Server 实现里。
必须连接 Sentinel 进程，端口默认是 26379，不是 6379。确认地址方式：
- 查哨兵配置文件
sentinel.conf中的port行（常见为port 26379） - 或用
ps aux | grep sentinel看进程绑定端口 - 腾讯云等托管服务中，控制台“网络信息”页明确列出 Sentinel 地址，格式如
10.0.1.10:26379
master_name 拼写必须和 sentinel monitor 完全一致
master_name 是逻辑别名，不是 IP、域名或服务名。它来自哨兵配置中的 sentinel monitor 行第二个参数：
例如配置行是 sentinel monitor redis-prod 10.0.1.20 6379 2，那么命令必须用 redis-prod，写成 10.0.1.20 或 redis 都会返回 (nil)。
排查建议：
- 登录任意 Sentinel 节点，执行
SENTINEL masters，查看输出中name字段值 - 避免硬编码：把
master_name作为配置项注入客户端，而非写死在代码里 - 多个主节点共存时（如分片集群），每个
master_name对应独立主从组，不可混用
返回结果是两元素数组，需按顺序解析 IP 和端口
SENTINEL get-master-addr-by-name mymaster 成功时返回：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
1) "10.0.1.20" 2) "6379"
第一项是 IP 字符串，第二项是端口字符串。不是 JSON，不是拼接后的 URL，也不是单个字符串。
常见错误处理点：
- 返回
(nil)：优先检查master_name是否拼错、Sentinel 是否刚启动或处于网络分区状态（未达成多数派共识） - 返回空数组或超时：确认 Sentinel 进程存活、防火墙放行
26379端口、客户端 socket timeout 设置合理（如 1–2 秒） - IP 是内网地址：若客户端跨网络访问，需确保该 IP 可达，或通过代理/NAT 转换
不要用 INFO replication 查主节点
在哨兵模式下，对任意 Redis 实例（包括当前主节点）执行 INFO replication，返回的 role:master 或 master_host 字段大概率过期——它只反映该实例自身的复制状态，不感知哨兵的故障转移决策。
真正可靠的来源只有一个：SENTINEL get-master-addr-by-name 向 Sentinel 查询。哪怕你手头有 3 个哨兵节点，也只需连其中一个，只要它在线且能达成共识，结果就是准确的。
复杂点在于：哨兵本身可能暂时失联或未完成选举，此时命令返回 (nil) 是正常现象；但一旦返回非空结果，就代表当前主节点已确定，可放心连接。
