最可靠的方式是使用 SENTINEL get-master-addr-by-name 命令向 Sentinel 节点查询当前主节点地址，它不依赖连接节点角色，结果实时权威；而 INFO replication 在哨兵模式下易因连错节点、状态未同步或配置错误导致误判。
直接结论：用 SENTINEL get-master-addr-by-name 是最可靠的方式，它不依赖当前连接节点的角色，而是向 Sentinel 询问“此刻谁是主”，结果实时、权威、无需解析文本。
为什么不能只靠 INFO replication？
很多同学一上来就对某个 Redis 实例执行 redis-cli -h 10.0.1.5 -p 6379 INFO replication，看 master_host 字段——这在纯主从结构里可能凑合，但在哨兵（Sentinel）模式下极易出错：
- 你连的可能是刚故障转移完但还没同步完状态的 Slave，
master_host还指向旧 Master（已宕机） - 你连的是 Sentinel 节点本身（端口如 26379），
INFO replication根本不返回主从信息，会报错(error) ERR Unknown subcommand or wrong number of arguments for 'replication'. - Slave 节点重启后若尚未完成全量同步，
master_link_status可能为down，但master_host字段仍残留旧值，误导判断
怎么用 SENTINEL get-master-addr-by-name 正确查主
这个命令必须发给 Sentinel 节点（不是 Redis Server），且需知道你的主节点逻辑名（master_name），不是 IP 或端口。
- 先确认 Sentinel 地址和端口（通常是
26379，如redis-cli -h 10.0.1.10 -p 26379） - 执行：
SENTINEL get-master-addr-by-name mymaster（把mymaster换成你配置里sentinel monitor指定的名字） - 成功返回形如：
1) "10.0.1.20" 2) "6379"—— 这才是当前真实可用的 Master 地址+端口 - 如果返回
(nil)，说明 Sentinel 还没达成多数派共识（比如刚启动、网络分区、或mymaster名字拼错）
master_name 到底从哪来？别猜，去配置里翻
它不是自动生成的，是你在 Sentinel 配置文件中明确写死的。别指望从 Redis 实例里反推出来。
- 登录任意一台运行 Sentinel 的机器，打开配置文件（如
/etc/redis/sentinel.conf） - 搜索
sentinel monitor行，例如：sentinel monitor mymaster 10.0.1.100 6379 2→ 这里的mymaster就是你要用的master_name - 注意：多个 Sentinel 节点的配置必须一致；如果改了名字，所有 Sentinel 和客户端都得同步更新，否则查不到
- Python 客户端（如
redis-py）里初始化Sentinel对象时传的service_name参数，也得和这个完全一致
自动化脚本里容易漏掉的关键校验
写监控或切换脚本时，光拿到 IP 和端口不够，还得验证它真能连上、真是主：
- 拿到
SENTINEL get-master-addr-by-name结果后，立刻用redis-cli -h {ip} -p {port} ROLE检查返回是否为1) "master"（不是"slave"或报错） - 避免 DNS 缓存问题：返回的 IP 是纯地址，不要做反向解析或拼 host；如果环境强制用域名，确保所有客户端 DNS 解析一致
- 超时设置要合理：Sentinel 命令默认无超时，网络抖动时可能卡住，建议客户端加
timeout=3（单位秒）
真正麻烦的从来不是命令怎么敲，而是你不确定该信谁——哨兵集群里每个节点都有自己的视角，get-master-addr-by-name 是唯一由 Sentinel 主动协商后给出的“官方答案”，其他都是快照或缓存。
