redis主从复制+哨兵集群实现高可用：主节点写、从节点读，哨兵自动故障转移；需配置一致、网络通畅、客户端动态发现主节点，并通过压测验证闭环可靠性。
Redis 主从复制 + 哨兵（Sentinel）集群是保障高可用的经典方案：主节点处理写请求，从节点同步数据并分担读流量；哨兵负责自动发现故障、选举新主、通知客户端切换。关键不在于组件数量，而在于配置一致性、网络连通性与故障响应逻辑是否闭环。
一、主从复制：基础数据同步机制
主从复制是哨兵工作的前提。需确保从节点能稳定连接主节点并拉取 RDB 快照或增量 AOF 日志。
- 在从节点 redis.conf 中配置 slaveof
- 主节点无需额外配置，但建议开启 requirepass 并在从节点配置 masterauth（若主启用了密码）
- 避免跨网段直连：主从间需开放 TCP 6379（或自定义端口），且防火墙允许双向通信
- 验证是否成功：在从节点执行 INFO replication，查看 role 是否为 slave，master_link_status 是否为 up
二、哨兵集群：三节点起步，独立部署
哨兵不共享 Redis 数据，它只监控、决策、通知。至少部署 3 个哨兵实例（奇数个），避免脑裂导致误判。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每个哨兵使用独立配置文件（如 sentinel.conf），核心配置包括：
port 26379
sentinel monitor mymaster2
sentinel auth-pass mymaster（若主节点有密码）
sentinel down-after-milliseconds mymaster 5000（5 秒未响应判定为主观下线） - 哨兵进程启动命令：redis-sentinel /path/to/sentinel.conf，不要用 redis-server
- 哨兵之间会自动发现并组成集群，可通过 SENTINEL sentinels mymaster 查看其他哨兵状态
三、客户端适配：不能直连 IP，必须用哨兵发现主节点
客户端不能硬编码主节点地址。需通过哨兵获取当前主节点动态地址，否则故障转移后仍连旧地址导致写失败。
- Jedis 示例：new JedisSentinelPool("mymaster", sentinelSet)，传入哨兵地址列表，内部自动订阅 + 切换
- StackExchange.Redis（.NET）：ConfigurationOptions.Sentinels + ServiceName = "mymaster"
- Python redis-py：StrictRedis.from_url("sentinel://...") 或使用 Sentinel 类初始化后调用 get_master_connection()
- 所有客户端需支持重试和连接重建——哨兵切换主从通常 10–30 秒，期间写操作可能短暂失败
四、常见问题排查要点
多数故障源于配置错位或网络隔离，而非哨兵逻辑本身。
- 哨兵无法切换主节点？ 检查 quorum 是否大于等于正常哨兵数的一半；确认从节点 slave-read-only yes（默认）且未被手动写入导致复制偏移异常
- 客户端仍连旧主？ 客户端未启用哨兵模式，或缓存了旧 master 地址（检查是否关闭了 DNS 缓存或连接池预热）
- 主从延迟高？ 查看 INFO replication 中 master_repl_offset 与 slave_repl_offset 差值；可能是网络带宽不足、从节点磁盘 I/O 慢，或主节点写入压力过大
- 哨兵日志报 “+sdown” 但没 “+odown”？ 说明仅单个哨兵认为主下线，未达到 quorum，需检查其他哨兵是否存活、能否互通
这套架构不复杂，但每层依赖都必须显式验证。上线前务必模拟主节点 kill -9，观察哨兵日志、从节点角色变更、客户端是否自动重连新主——真实故障不会给你二次机会。
