Redis哨兵模式
Redis 哨兵模式(Sentinel)详解
Redis 哨兵模式是一种 高可用性(HA)解决方案,用于监控 Redis 主从集群的状态,并在主节点(Master)故障时自动完成 故障转移(Failover),选举新的主节点,保障服务持续可用。
1. 哨兵模式的核心功能
功能 | 说明 |
---|---|
监控(Monitoring) | 持续检查主节点和从节点(Slave)是否正常运行。 |
通知(Notification) | 通过 API 或消息系统向管理员发送节点故障告警。 |
自动故障转移 | 主节点故障时,自动选举新的主节点并调整从节点指向新主节点。 |
配置提供(Configuration Provider) | 客户端通过哨兵获取当前主节点地址,实现动态服务发现。 |
2. 哨兵模式架构
基础架构图
+------------+ +------------+ +------------+
| Sentinel | | Sentinel | | Sentinel |
| Node 1 | | Node 2 | | Node 3 |
+-----+------+ +-----+------+ +-----+------+
| | |
| | |
v v v
+------------+ +------------+ +------------+
| Master |<----->| Slave 1 |<----->| Slave 2 |
| (Redis) | | (Redis) | | (Redis) |
+------------+ +------------+ +------------+
- 哨兵节点(Sentinel):通常部署奇数个(如 3 个),通过投票机制达成一致决策。
- 主节点(Master):处理写请求的核心节点。
- 从节点(Slave):复制主节点数据,故障转移后可能晋升为新主节点。
3. 哨兵模式的工作原理
故障转移流程
-
主观下线(Subjectively Down, SDOWN)
单个哨兵节点检测到主节点无响应(如超时),标记主节点为“主观下线”。 -
客观下线(Objectively Down, ODOWN)
当多数哨兵节点(quorum
参数控制)确认主节点不可达,标记为“客观下线”。 -
选举 Leader 哨兵
哨兵节点通过 Raft 算法选举一个 Leader 哨兵来主导故障转移。 -
选举新主节点
Leader 哨兵根据规则(如优先级、复制偏移量)从从节点中选择新主节点。 -
切换与同步
- 将新主节点升级为 Master。
- 其他从节点切换至复制新主节点。
- 旧主节点恢复后,作为从节点加入集群。
4. 哨兵模式配置
步骤 1:配置 Redis 主从集群
- 主节点配置(redis-master.conf):
port 6379 daemonize yes
- 从节点配置(redis-slave.conf):
port 6380 daemonize yes replicaof 127.0.0.1 6379 # 指向主节点
步骤 2:配置哨兵节点
- 哨兵配置文件(sentinel.conf):
port 26379 daemonize yes sentinel monitor mymaster 127.0.0.1 6379 2 # 监控名为 mymaster 的主节点,2 表示至少 2 个哨兵同意才判定客观下线 sentinel down-after-milliseconds mymaster 5000 # 5 秒无响应判定主观下线 sentinel failover-timeout mymaster 60000 # 故障转移超时时间(毫秒)
步骤 3:启动哨兵
# 启动 Redis 主从节点
redis-server redis-master.conf
redis-server redis-slave.conf
# 启动哨兵节点
redis-sentinel sentinel.conf
5. 客户端连接哨兵模式
客户端需支持哨兵协议,通过哨兵获取主节点地址。
Java 示例(Jedis):
JedisPoolConfig poolConfig = new JedisPoolConfig();
Set<String> sentinels = new HashSet<>();
sentinels.add("127.0.0.1:26379");
sentinels.add("127.0.0.1:26380");
sentinels.add("127.0.0.1:26381");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, poolConfig);
try (Jedis jedis = pool.getResource()) {
jedis.set("key", "value");
}
6. 哨兵模式注意事项
要点 | 说明 |
---|---|
哨兵节点数量 | 建议至少 3 个哨兵节点,避免“脑裂”问题。 |
网络分区处理 | 网络分区可能导致多个主节点(需人工干预)。 |
客户端兼容性 | 确保客户端库支持哨兵模式(如 Jedis、Lettuce)。 |
监控与告警 | 监控哨兵节点状态及故障转移次数,及时处理异常。 |
7. 常见问题与解决方案
-
哨兵节点自身故障
部署多个哨兵节点,确保多数存活即可正常工作。 -
故障转移期间数据丢失
使用min-replicas-to-write
配置主节点写入需确认的从节点数,提升数据安全性。 -
客户端连接失败
检查客户端是否支持哨兵协议,确认哨兵配置中的主节点名称与客户端一致。