直接连Sentinel（26379端口）执行SENTINEL master <master-name>可查主节点实时状态，关键字段包括status、is-master-down-by-addr、num-slaves等，主节点名须严格匹配sentinel monitor配置的名称。
怎么用 SENTINEL 命令查主节点实时状态
直接连上任意一个 Sentinel 实例（默认端口 26379），用 redis-cli -p 26379 进入交互模式，执行 SENTINEL master <master-name> 就能拿到当前主节点的完整运行快照。这个输出里关键字段包括：status（ok 或 fail）、is-master-down-by-addr（是否被多数哨兵判定下线）、num-slaves、num-other-sentinels 和 down-after-milliseconds 实际触发时间。
常见错误是误把主节点名写成 IP 或端口——必须严格匹配 sentinel monitor 配置项中定义的名称，比如配置里写的是 sentinel monitor myredis 127.0.0.1 6379 2，那这里就得传 myredis，不是 127.0.0.1:6379。
SENTINEL slaves 返回的从节点列表为什么有时为空
空结果通常不是配置漏了，而是 Sentinel 还没完成对从节点的自动发现。Sentinel 启动后，会先向主节点发 INFO replication 拿到从节点地址，再逐个建立连接并确认状态。这个过程可能有几秒延迟，尤其在主节点刚恢复或网络抖动后。
这时可以：
- 检查主节点
redis-cli INFO replication输出里slave0～slaveN是否真实存在 - 确认从节点的
slaveof配置指向的是主节点的正确 IP 和端口（不能是127.0.0.1，否则 Sentinel 无法跨机访问） - 用
SENTINEL sentinels <master-name>看其他 Sentinel 是否已同步，避免单点视角偏差
用 SENTINEL masters 批量检查多个主集群时要注意什么
这个命令返回所有被监控的主节点摘要，但不包含详细健康信息。它适合做巡检脚本的入口，但不能替代单个 SENTINEL master 查询。实际使用中容易忽略两点：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 返回结果里的
flags字段值为master仅表示配置存在，不代表当前在线；要判断存活得看is-master-down-by-addr和last-ok-ping-reply - 如果配置了多个主集群（比如
mymaster和cache），但其中某个主节点已彻底下线且未清理配置，SENTINEL masters仍会列出它，只是status是fail，需要配合下游告警逻辑过滤
为什么 SENTINEL get-master-addr-by-name 有时返回旧地址
这个命令是客户端最常调用的 API，用于获取当前可用主节点地址。但它返回的是 Sentinel 内存里“最近一次成功故障转移后确认的地址”，不保证实时刷新。典型场景：主节点刚宕机，Sentinel 还在投票阶段，此时调用该命令可能仍返回原主节点 IP，直到多数哨兵达成一致并完成切换。
生产环境必须配合超时和重试：
- 客户端不应缓存该结果超过 5 秒
- 连接失败时，应重新调用
SENTINEL get-master-addr-by-name而非直接 fallback 到硬编码地址 - 若连续两次调用返回相同地址但连接不通，建议主动触发
SENTINEL failover <master-name>（仅限紧急人工干预）
真正难处理的不是命令本身，而是多数哨兵尚未达成共识前的“灰色窗口期”——这段时间没有权威地址可依赖，只能靠客户端本地重试策略兜底。
