能实现自动故障转移，但必须满足三个硬性条件：至少3个sentinel进程、主从节点网络互通、sentinel monitor配置正确；其中sentinel monitor的四个参数（别名、ip、端口、quorum）顺序不可错，quorum需设为多数派，主节点ip不能为127.0.0.1，客户端必须通过sentinel初始化连接，failover-timeout需根据数据量和网络调整。
能实现，但必须满足三个硬性条件：至少3个Sentinel进程、主从节点网络互通、sentinel monitor配置正确。少一个，自动故障转移就不可靠。
sentinel monitor 配置写错会导致整个集群无法触发故障转移
这是最常踩的坑——配置项顺序和参数含义容易混淆。sentinel monitor后面跟的四个参数必须严格按顺序：主节点别名、IP、端口、quorum值。quorum不是Sentinel数量，而是“多少个Sentinel同意才算客观下线”。
- 如果只部署3个Sentinel，
quorum设为2是安全下限；设为1等于放弃多数派机制，可能引发脑裂 - 主节点IP不能写
127.0.0.1或localhost，所有Sentinel和客户端都得能通过这个地址直连主节点 - 别名（如
mymaster）要全集群统一，客户端初始化时就靠它查主节点，不匹配会报NOGOODSLAVE
down-after-milliseconds 设太小会误判，设太大则恢复慢
这个阈值决定Sentinel多久没收到PING响应就标记主节点主观下线（SDOWN）。它直接影响故障发现速度和稳定性。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生产环境建议设为
30000（30秒），比Redis默认redis.conf里的timeout高2~3倍，避免网络抖动误触发 - 若主节点启用了
tcp-keepalive，且内核net.ipv4.tcp_keepalive_time设得很小（如60秒），可适当下调至20000，但需同步检查防火墙长连接超时设置 - 该值对从节点也生效，但通常不影响故障转移逻辑，只影响Sentinel是否将其纳入候选新主范围
客户端必须用 Sentinel 地址初始化，不能直连旧主地址
很多团队把Sentinel当“备用监控工具”，客户端仍硬编码redis://192.168.1.100:6379，结果主节点宕机后连接直接失败，根本等不到重定向。
- Jedis示例：
new JedisSentinelPool("mymaster", sentinels)，其中sentinels是Set<string></string>，含多个ip:port（如"192.168.1.101:26379"） - Lettuce更严格：必须用
RedisURI.create("redis-sentinel://192.168.1.101:26379,192.168.1.102:26379/...?sentinelMasterId=mymaster") - 连接断开时，客户端会自动调用
SENTINEL get-master-addr-by-name，但如果Sentinel本身不可达或返回空，就会抛RedisConnectionException而非静默重试
failover-timeout 决定故障转移能否真正完成
这个参数控制整个故障转移流程的总时限（毫秒），包括选举Leader、提升从节点、重新配置其他从节点。超时未完成，当前Sentinel会放弃并等待下次检测。
- 默认
180000（3分钟）偏保守；若从节点数据量大（AOF > 1GB）、网络带宽有限，建议设为600000（10分钟） - 它同时限制“新主上线后，其他从节点完成
SLAVEOF同步”的时间，超时会导致部分从节点卡在SYNC状态，后续写请求可能被拒绝 - 注意：
failover-timeout不是单次操作超时，而是从ODOWN判定开始到全部从节点指向新主的总窗口
真正难的是让所有组件在真实网络中达成一致：Sentinel之间要通过__sentinel__:hello频道互相发现，主节点要能稳定响应INFO replication，客户端得及时感知switch-master事件。任何一个环节有延迟或丢包，都可能让故障转移卡在中间状态。
