Redis哨兵模式概述

Redis哨兵（Sentinel）是Redis官方提供的高可用性解决方案。其核心功能是监控主从架构中所有节点的运行状态，当主库（Master）发生宕机、网络中断等故障时，能够自动选举一个从库（Slave）提升为新的主库，并通知其他从库和客户端更新连接信息，从而保障业务连续性。

为什么需要哨兵模式

在标准的Redis主从复制架构中，主库负责写入和读取，从库负责读取和备份。但主库一旦宕机，从库无法自动接管写入服务，需要运维人员手动干预。这种依赖人工的方式存在响应慢、误操作风险高等问题。哨兵模式通过自动化监控和故障转移，显著提升了Redis服务的可用性，适用于对数据连续性要求较高的生产环境。

哨兵模式的核心功能

• 监控：哨兵持续检查主库和从库是否正常运行，通过发送PING命令判断节点存活状态。
• 自动故障转移：当主库被判定为客观下线后，哨兵集群会通过选举算法选出一个领头哨兵，从现有从库中选择一个作为新主库，并修改其余从库的复制目标。
• 配置通知：故障转移完成后，哨兵将新主库的地址信息推送给客户端，客户端需实现订阅或主动获取逻辑以更新连接。
• 配置提供：客户端可以连接哨兵查询当前主库的地址，无需硬编码。

哨兵模式部署架构建议

为了避免哨兵自身成为单点故障，生产环境至少部署三个哨兵实例，且建议将哨兵部署在独立的服务器或不同机柜上。哨兵之间通过相互通信达成共识，防止误判。一个典型的架构包含：一台主库、两台从库、三台哨兵节点。

搭建步骤（以Linux服务器为例）

1. 准备Redis主从环境

首先安装Redis并配置主从复制。假设主库IP为192.168.1.10，从库IP为192.168.1.11和192.168.1.12。主库redis.conf中设置bind 0.0.0.0和protected-mode no（内网环境），从库redis.conf中设置replicaof 192.168.1.10 6379。

2. 配置哨兵节点

每个哨兵节点需要独立的sentinel.conf文件，关键配置如下：

port 26379
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000
sentinel parallel-syncs mymaster 1

其中mymaster是主库名称，2表示至少需要2个哨兵同意才能判定主库主观下线并触发故障转移。down-after-milliseconds指定主库无响应超过5秒则判定主观下线。parallel-syncs控制故障转移后同时向新主库发起复制操作的从库数量，建议设为1以减少同步压力。

3. 启动哨兵进程

在三个节点上分别执行命令启动哨兵：

redis-sentinel /etc/redis/sentinel.conf

启动后，哨兵会监控主库和从库状态，并自动发现其他哨兵。

4. 验证自动切换

手动停止主库Redis进程，模拟宕机。观察哨兵日志，等待投票和选举完成（通常约10-30秒）。此时其中一个从库会被提升为新主库，其余从库自动切换复制目标。客户端需重新连接新主库地址，推荐通过哨兵获取当前主库信息。

故障切换机制说明

哨兵通过主观下线（SDOWN）和客观下线（ODOWN）两个阶段判断主库故障。当单个哨兵发现主库超过阈值时间无响应时，标记为主观下线；随后通过is-master-down-by-addr命令询问其他哨兵，若获得超过quorum数量的确认，则标记为客观下线并启动故障转移流程。选举新主库时，优先选择复制偏移量最靠前、运行ID稳定且优先级高的从库。

注意事项

• 哨兵模式只能保证Redis服务的最终一致性，存在故障窗口内的数据丢失风险，可结合Redis持久化（AOF+RDB）降低风险。
• 客户端必须支持哨兵机制（例如Jedis、Lettuce的Sentinel模式），否则需要在业务层实现地址动态刷新。
• quorum值建议配置为哨兵总数的一半加一，避免脑裂。
• 哨兵自身也需要监控和备份，建议使用Keepalived或云监控工具保障哨兵进程存活。

总结

Redis哨兵模式通过自动化监控和故障转移，解决了主从复制架构中主库宕机时需要人工干预的问题。合理的部署架构和参数调优能够大幅提升Redis服务的可用性，但在使用时要结合持久化策略、客户端适配和监控系统，才能构建真正稳定的高可用缓存层。