当前位置：首页 > news >正文

Redis 高可用开发指南

news 2025/8/25 7:42:49

Redis 高可用是保障 Redis 服务持续稳定运行的核心能力，主要解决单点故障、数据丢失、服务中断等问题。以下从核心方案、配置实践、开发注意事项等方面，提供一份 Redis 高可用开发指南。

一、Redis 高可用核心方案

Redis 高可用依赖 主从复制、哨兵（Sentinel）、集群（Cluster） 三大核心方案，分别解决数据备份、自动故障转移、数据分片与大规模部署问题。

1. 主从复制（基础）

作用：实现数据备份与读写分离，为主节点分担读压力，同时作为故障转移的基础。
原理：

主节点（Master）接收读写请求，从节点（Replica）仅接收读请求，并通过复制机制同步主节点数据。
复制过程：初始化时从节点发起全量复制（加载主节点 RDB 文件 + 同步缓冲区数据），之后通过增量复制（同步主节点的写命令）保持数据一致。

配置实践：

从节点配置（redis.conf）：

# 指定主节点地址和端口
replicaof <master-ip> <master-port>
# 若主节点有密码，需配置认证
masterauth <master-password>
# 从节点是否只读（建议开启）
replica-read-only yes

主节点无需特殊配置（默认允许复制）。

开发注意事项：

读写分离：通过客户端将读请求路由到从节点，写请求路由到主节点（需注意从节点数据可能存在毫秒级滞后）。
避免全量复制频繁触发：主节点 repl-backlog-size 配置适当大小（默认1MB，建议根据写量调整为100MB+），减少网络中断后重连时的全量复制概率。
从节点数量：不宜过多（建议≤3个），否则主节点复制压力过大。

2. 哨兵（Sentinel）：自动故障转移

作用：监控主从节点状态，当主节点故障时自动将从节点晋升为新主节点，实现无人工干预的故障转移。
原理：

哨兵节点（独立进程）通过 PING 命令监控主从节点健康状态，当主节点“主观下线”（单哨兵判断）且多数哨兵确认“客观下线”后，触发故障转移。
故障转移流程：选举新主节点（优先选择复制进度快、健康的从节点）→ 其他从节点切换复制新主节点 → 更新客户端路由信息。

配置实践：

哨兵节点配置（sentinel.conf）：

# 监控主节点（名称、地址、端口、确认下线的最小哨兵数）
sentinel monitor mymaster <master-ip> <master-port> 2
# 主节点“主观下线”判断阈值（毫秒，建议3000）
sentinel down-after-milliseconds mymaster 3000
# 故障转移超时时间（毫秒，建议180000）
sentinel failover-timeout mymaster 180000
# 若主节点有密码，需配置认证
sentinel auth-pass mymaster <master-password>

部署建议：至少3个哨兵节点（奇数，避免脑裂），分布在不同机器。

开发注意事项：

客户端连接：通过哨兵集群获取当前主节点地址，而非硬编码主节点 IP（示例：Java Jedis 连接哨兵）：

Set<String> sentinelSet = new HashSet<>();
sentinelSet.add("sentinel1-ip:26379");
sentinelSet.add("sentinel2-ip:26379");
sentinelSet.add("sentinel3-ip:26379");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinelSet, "password");
try (Jedis jedis = pool.getResource()) {jedis.set("key", "value"); // 自动路由到当前主节点
}

故障转移窗口期：约几秒到十几秒，客户端需处理短暂的连接异常（建议重试机制）。

3. Redis 集群（Cluster）：大规模高可用

作用：解决单节点内存上限问题，通过数据分片（hash slot）分散到多个主节点，同时每个主节点有从节点实现故障转移。
原理：

集群包含多个主节点（至少3个），每个主节点负责 16384 个 hash slot 中的一部分（如主节点1负责0-5460，主节点2负责5461-10922等）。
键通过 CRC16(key) % 16384 计算 slot，路由到对应主节点；多键操作需保证在同一 slot（通过 hash tag 实现：{user:1}:name 和 {user:1}:age 会映射到同一 slot）。
每个主节点有1个或多个从节点，主节点故障时，从节点自动晋升为主节点。

配置实践：

节点配置（redis.conf）：

# 开启集群模式
cluster-enabled yes
# 集群配置文件（自动生成，无需手动修改）
cluster-config-file nodes.conf
# 节点超时时间（毫秒，建议15000）
cluster-node-timeout 15000
# 若开启密码，所有节点密码需一致
requirepass <password>
masterauth <password>

创建集群（使用 redis-cli）：

# 假设6个节点（3主3从），地址为ip1:6379 ~ ip6:6379
redis-cli --cluster create ip1:6379 ip2:6379 ip3:6379 ip4:6379 ip5:6379 ip6:6379 --cluster-replicas 1

开发注意事项：

客户端连接：使用集群模式客户端（如 JedisCluster），自动处理 slot 路由和 MOVED/ASK 重定向：

Set<HostAndPort> nodes = new HashSet<>();
nodes.add(new HostAndPort("ip1", 6379));
nodes.add(new HostAndPort("ip2", 6379));
JedisCluster cluster = new JedisCluster(nodes, 5000, 5000, 3, "password", new GenericObjectPoolConfig<>());
cluster.set("key", "value"); // 自动路由到对应主节点

避免跨 slot 操作：如 MGET key1 key2 若 key1 和 key2 不在同一 slot，会返回错误，需通过 hash tag 强制归为同一 slot。
集群扩容/缩容：通过 redis-cli --cluster add-node 或 --cluster del-node 操作，客户端无需重启（自动发现新节点）。

二、高可用辅助保障

除核心方案外，需配合以下配置确保数据安全和服务稳定：

1. 持久化配置（防止数据丢失）

AOF（Append Only File）：记录所有写命令，默认每秒刷盘（appendfsync everysec），数据安全性高（丢失≤1秒数据），适合核心业务。
```
appendonly yes
appendfsync everysec
```
RDB（快照）：定时生成内存快照，适合备份（如每日凌晨执行），但可能丢失快照后的数据。
```
save 3600 1    # 3600秒内有1次写操作则触发快照
save 300 100   # 300秒内有100次写操作则触发快照
```
建议：AOF + RDB 结合（AOF 保证实时性，RDB 用于快速恢复）。

2. 内存管理（避免 OOM 崩溃）

限制最大内存：maxmemory <size>（如 maxmemory 4gb）。

配置内存淘汰策略（根据业务选择）：

# 优先淘汰最近最少使用的键（通用推荐）
maxmemory-policy allkeys-lru
# 仅淘汰设置了过期时间的键（适合有临时键的场景）
# maxmemory-policy volatile-lru

3. 监控与告警

通过 INFO 命令获取集群状态（如 INFO replication 查看主从状态，INFO cluster 查看集群信息）。
关键监控指标：
- 主从复制延迟（master_repl_offset 与 slave_repl_offset 的差值）。
- 内存使用率（used_memory / maxmemory）。
- 哨兵状态（sentinel master mymaster 查看主节点状态）。
告警工具：结合 Prometheus + Grafana 监控，配置内存过高、节点下线等告警。

三、开发最佳实践

避免大键操作：大键（如百万级元素的列表）会导致主从复制卡顿、AOF 重写阻塞，建议拆分（如将 user:list 拆分为 user:list:1、user:list:2）。
批量操作优化：使用 Pipeline 减少网络往返（如一次性发送100条命令），但避免批量过大导致阻塞。
连接池管理：客户端使用连接池（如 JedisPool），避免频繁创建/关闭连接，合理设置池大小（根据并发量调整）。
重试机制：针对故障转移窗口期的连接异常，客户端需实现指数退避重试（如重试3次，间隔100ms、200ms、400ms）。
容灾演练：定期模拟主节点故障（如 DEBUG SEGFAULT 强制崩溃），验证哨兵/集群的故障转移是否正常。