redis哨兵模式高可用部署核心是自动故障转移：3个及以上奇数哨兵分机部署、quorum设为多数（如3哨兵时为2）、主从延迟

Redis哨兵模式高可用部署，核心是让系统在主节点宕机时自动选出新主、重配从库、通知客户端，全程无需人工干预。关键不在“装几个进程”，而在监控逻辑是否可靠、投票机制是否防脑裂、故障响应是否可预期。

哨兵节点部署必须满足三个硬性条件

哨兵不是越多越好，而是要形成容错共识：

• 数量为奇数（生产环境最低3个），且分别部署在不同物理机或可用区，避免单点物理故障导致多数哨兵同时失联
• quorum值设为哨兵总数÷2＋1（如3个哨兵，quorum=2），确保客观下线需多数确认，防止网络分区误判
• 每个哨兵独立运行，禁止多个哨兵实例共用同一操作系统进程或容器，否则一个崩溃全军覆没

主从节点配置要兼顾数据安全与切换时效

主从结构本身不提供高可用，但它是哨兵执行切换的前提基础：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 主节点建议启用AOF+everysec策略，兼顾性能与秒级数据丢失容忍度；从节点开启read-only，防止误写
• 所有从节点的repl-backlog-size建议设为256MB以上，保证网络抖动时复制不中断、切换时能选到数据最全的从库
• 主从间内网延迟应稳定低于2ms，跨机架部署时启用TCP keepalive（net.ipv4.tcp_keepalive_time=60）减少假死连接

哨兵配置参数必须按场景调优，不能照搬默认值

默认配置适合测试，生产环境必须调整关键阈值：

• down-after-milliseconds：建议设为30000（30秒），太短易因瞬时抖动触发误切，太长影响恢复速度
• failover-timeout：设为180000（3分钟），覆盖从库同步、提升、重配全过程，避免超时后重复发起切换
• parallel-syncs：设为1，防止多个从库同时向新主全量同步，压垮带宽和CPU
• 所有哨兵的sentinel monitor指令中，主节点IP必须写实际监听地址（如192.168.56.102），不能写127.0.0.1

客户端必须通过哨兵获取主节点地址，而非直连固定IP

这是实现“自动感知切换”的最后一环，也是最容易被忽略的一环：

• Java应用推荐使用JedisSentinelPool或Lettuce的SentinelClient，初始化时传入哨兵列表（如26379端口），由SDK自动订阅+sentinel:hello频道
• PHP、Python等语言客户端也需启用sentinel mode，禁用静态host配置；若业务代码仍硬编码6379地址，哨兵切换再快也无意义
• 上线前务必验证：手动kill主节点进程，观察客户端日志是否在30秒内完成重连，并读写正常