哨兵节点无法发现主从实例的根本原因是跨网段时默认广播内网地址（如127.0.0.1或容器ip），导致反向连接失败；必须配置bind 0.0.0.0、announce-ip、protected-mode no及哨兵端sentinel announce-ip/announce-port，并确保防火墙放行26379端口且双向连通。
哨兵节点无法发现主从实例（常见错误：NOGOODSLAVE 或 master-link-down）
跨网段时，哨兵默认用 bind 地址或 redis.conf 中配置的 announce-ip 向其他节点宣告自身地址。若未显式设置，它可能广播内网地址（如 127.0.0.1 或容器网桥地址），导致其他网段的哨兵或 Redis 实例无法反向连接。
必须在每个 Redis 实例的 redis.conf 中配置：
-
bind 0.0.0.0（允许跨网段监听） -
announce-ip（Redis 6.2+ 才支持；老版本需靠sentinel announce-ip补救） -
protected-mode no（否则跨网段连接会被拒绝）
同时，每个哨兵的 sentinel.conf 必须配 sentinel announce-ip 和 sentinel announce-port，否则其他哨兵会尝试用本地回环地址去连它。
哨兵之间通信超时（错误日志含 Connection refused 或反复 +sdown sentinel）
哨兵集群依赖 TCP 端口（默认 26379）互相通信，且使用 PING + SENTINEL CKQUORUM 协议交换状态。跨网段常因以下原因中断：
- 防火墙未放行
26379（不止是 Redis 的6379） - 安全组/ACL 规则只允许出站、未开入站（哨兵 A 连 B 成功，B 却连不上 A）
- 网络设备（如路由器、云厂商负载均衡器）对长连接空闲超时设置过短（哨兵心跳间隔默认 30 秒，建议将空闲超时调至 ≥60 秒）
验证方法：telnet 26379 要双向通；用 redis-cli -p 26379 ping 登录任一哨兵后执行 sentinel masters，确认所有哨兵出现在 num-other-sentinels 字段里。
客户端连接哨兵后获取到错误主节点地址（现象：写请求被重定向到不可达 IP）
哨兵通过 sentinel get-master-addr-by-name 告诉客户端当前主节点地址。如果主节点本身没正确配置 announce-ip，哨兵返回的就是它自己“看到”的主节点地址——可能是内网地址、Docker 容器 IP 或 127.0.0.1。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键点：
- 客户端不直连 Redis，而是连哨兵并调用
sentinel get-master-addr-by-name，所以哨兵返回什么，客户端就信什么 - 主节点的
announce-ip必须和客户端所在网段能直接路由通（不能是 NAT 后的私有地址） - 若用 Kubernetes 或 Docker，避免用
hostNetwork: true混淆网络平面；推荐用 headless Service + 显式announce-ip
测试命令：redis-cli -p 26379 sentinel get-master-addr-by-name mymaster，返回值必须是客户端能 telnet 通的 IP+端口。
脑裂（Split-brain）风险陡增
跨网段意味着网络分区概率上升。当主节点所在网段与其他网段断连，但主节点本身仍存活时，可能出现：部分哨兵认为主节点 odown 并完成故障转移，而另一部分哨兵仍与主节点通信正常 —— 最终产生两个主节点，数据写入分裂。
缓解措施有限但关键：
- 哨兵数量必须为奇数且 ≥3，
quorum值设为 ⌈N/2⌉+1（例如 3 个哨兵设quorum 3，强制全部同意才 failover） - 调大
down-after-milliseconds（比如从 30000 改为 60000），避免短暂抖动触发误切 - 严禁把哨兵和主节点部署在同一物理机或同一可用区；跨网段应等价于跨机房/跨 AZ
真正难处理的是「主节点活着但网络隔离」这种场景——哨兵模式本身不解决分布式一致性，它只做多数派决策。生产中更依赖网络基础设施的稳定性，而非哨兵参数调优。
