在Redis高可用架构中，使用哨兵API连接的优势在于自动故障转移和主从切换。以下是实战代码示例：使用Python redis-py库连接哨兵：

from redis.sentinel import Sentinel
sentinel = Sentinel([('sentinel1', 26379), ('sentinel2', 26379)], socket_timeout=0.1)
master = sentinel.master_for('mymaster', socket_timeout=0.1)
master.set('key', 'value')
print(master.get('key'))

哨兵模式搭建实战

首先准备三台机器安装Redis和哨兵配置文件。sentinel.conf内容如下：port 26379、sentinel monitor mymaster 127.0.0.1 6379 2、sentinel down-after-milliseconds mymaster 5000。在三台机器上启动哨兵：redis-sentinel sentinel.conf。测试故障转移：kill掉主节点Redis进程，观察哨兵日志，主从自动切换，整个过程只需几秒钟，确保服务不中断。

客户端连接哨兵的优势

传统方式直接连主节点，主挂了就连不上。用哨兵API，客户端问哨兵"谁是当前主？"，哨兵实时监控并返回最新主节点地址。优势：1.自动发现主节点；2.故障时无需重连，API内部处理；3.支持多哨兵集群，任何一个哨兵挂掉都不影响。实战中，我们用Java JedisSentinelPool，配置哨兵列表后，getResource()直接返回可用连接，超级方便。

高可用架构经验分享

实战部署时，哨兵至少3个奇数，避免脑裂。Redis主从配置：slaveof主IP主端口。哨兵quorum设为2（3个哨兵中2个同意切换）。网络延迟高时，调大down-after-milliseconds到10000ms。监控告警：用Prometheus抓哨兵指标，is_master_down等。一次生产事故，主节点磁盘满导致挂掉，哨兵5秒内切换，从节点接管，业务零感知，这就是高可用的魅力。

Redis哨兵在微服务中的应用

在Kubernetes中，用StatefulSet部署Redis主从，哨兵用Deployment。客户端用Sidecar注入哨兵连接。优势：Pod重启时，哨兵自动更新节点信息。实战代码用Go redissentinel包：s := sentinel.New([]string{"sentinel:26379"}, nil); masterName := "mymaster"; client := s.MasterClient(masterName)。这种方式让微服务无感知高可用，扩展性强。

常见坑和优化经验

坑1：哨兵端口别和Redis端口冲突，默认26379。坑2：防火墙别拦哨兵端口。优化：用keepalive开启长连接，减少重连开销。生产环境，哨兵日志开到info级别，定期备份哨兵配置。一次经验：从节点同步落后太多，设repl-diskless-sync yes加速。总体，哨兵API让高可用从理论变现实，值得每个Redis用户掌握。

FAQ

Q: 哨兵模式下如何确认主节点切换成功？
A: 用sentinel get-master-addr-by-name mymaster命令，哨兵返回当前主IP端口。

Q: 客户端连接哨兵超时怎么调？
A: 在API初始化时设置socket_timeout=0.5，避免网络抖动误判。

Q: 哨兵集群多少个合适？
A: 至少3个，quorum设为2，确保多数派决策。

Q: 主节点故障恢复后怎么处理？
A: 手动将原主设为从节点，slaveof新主IP新主端口，然后哨兵会自动管理。