最可靠的方式是使用 sentinel get-master-addr-by-name 命令向 sentinel 节点（端口通常为 26379）查询当前主节点地址，该命令必须传入与 sentinel monitor 配置完全一致的 master_name，返回形如 "10.0.1.20" 和 "6379" 的两元素数组，需正确解析 ip 和端口。
必须连 Sentinel 节点，而不是 Redis Server，才能拿到实时、准确的主节点地址。 直接连某个 Redis 实例查 INFO replication 在哨兵模式下大概率返回过期或错误结果——这不是配置问题，是架构逻辑决定的。
sentinel get-master-addr-by-name 命令必须发给 Sentinel 端口（通常是 26379）
这个命令不是 Redis Server 的命令，而是 Sentinel 节点专属 API。如果误连到 Redis 主/从节点（如 redis-cli -h 10.0.1.5 -p 6379），会收到 ERR Unknown subcommand or wrong number of arguments for 'replication' 或直接无响应。
- 确认 Sentinel 地址：常见是
10.0.1.10:26379、10.0.1.11:26379，端口非 6379 - 用
redis-cli -h <sentinel-ip> -p 26379</sentinel-ip>连接后，再执行SENTINEL get-master-addr-by-name mymaster - 若返回
(nil)，优先检查：mymaster是否拼错（必须和sentinel monitor配置项完全一致）、Sentinel 是否已达成多数派共识（刚启动或网络分区时可能暂无结果）
master_name 是逻辑名，不是 IP 或服务名
它来自 Sentinel 配置中的 sentinel monitor <master_name><ip><port><quorum></quorum></port></ip></master_name> 第二个参数。比如配置行是 sentinel monitor redis-prod 10.0.1.20 6379 2，那就要用 redis-prod，而非 10.0.1.20 或 redis。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 可通过
SENTINEL masters命令列出所有被监控的主节点及其name字段，避免硬编码错误 - 多个主节点共存时（如分片集群），每个
master_name对应独立的一组主从，不可混用 - 客户端初始化时应把
master_name作为配置项传入，而非写死在代码里
返回结果是数组，需按顺序取 IP 和端口
SENTINEL get-master-addr-by-name mymaster 成功时返回两行响应：
1) "10.0.1.20" 2) "6379"
第一项是 IP，第二项是端口——不是字符串拼接，也不是 JSON。很多客户端库（如 Jedis 的 JedisSentinelPool）内部已封装解析，但自研连接逻辑时容易漏掉类型转换或索引越界。
- 不要假设返回一定是字符串数组；某些语言驱动可能包装成 map 或 object，需查文档确认结构
- 端口字段是字符串，使用前需转为整数（如 Python 的
int(port_str)） - 若返回空数组或单元素，说明 Sentinel 尚未完成状态同步，应重试而非报错退出
真正难的不是调用这个命令，而是确保你的客户端在故障转移窗口期内不缓存旧地址、不跳过验证步骤——哪怕只差 200ms，也可能连上一个刚降级为 slave 的节点。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
