Redis 高可用架构设计：从主从到 Cluster 的演进之路

引言

Redis 作为最流行的内存数据库，几乎是每个后端项目的标配。但单节点 Redis 存在明显的单点故障风险。当你的系统从「能用」走向「好用」，高可用架构就成了必修课。

本文梳理 Redis 高可用的三种主流方案，帮你根据实际场景做出选择。

方案一：主从复制（Replication）

原理

最基础的方案。一个 Master 负责写入，多个 Slave 负责读取。数据通过异步复制从 Master 同步到 Slave。

Client --write--> Master --async replicate--> Slave1
                                          --> Slave2
Client --read--> Slave1 / Slave2

配置

# slave 节点配置
replicaof 192.168.1.100 6379
replica-read-only yes

优缺点

• 优点：配置简单，读性能线性扩展
• 缺点：Master 挂了需要手动切换，存在数据丢失风险

方案二：哨兵模式（Sentinel）

原理

在主从基础上增加 Sentinel 进程，实现自动故障检测和主从切换。至少需要 3 个 Sentinel 节点形成多数派。

工作流程

1. Sentinel 持续监控 Master 和 Slave 的健康状态
2. 当 Master 不可达时，Sentinel 之间投票确认（避免误判）
3. 选举一个 Slave 提升为新 Master
4. 通知其他 Slave 切换复制目标
5. 通知客户端新的 Master 地址

配置示例

# sentinel.conf
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

客户端连接

from redis.sentinel import Sentinel

sentinel = Sentinel([
    (sentinel1, 26379),
    (sentinel2, 26379),
    (sentinel3, 26379),
], socket_timeout=0.5)

master = sentinel.master_for(mymaster)
slave = sentinel.slave_for(mymaster)

master.set(key, value)  # 写 Master
slave.get(key)             # 读 Slave

优缺点

• 优点：自动故障转移，运维成本低
• 缺点：写入仍是单点，不支持数据分片

方案三：Redis Cluster

原理

Redis 官方的分布式方案。数据通过 16384 个哈希槽（hash slot）分布到多个节点，每个节点负责一部分槽位。

Slot 0-5460     -> Node A (+ Slave A1)
Slot 5461-10922 -> Node B (+ Slave B1)
Slot 10923-16383-> Node C (+ Slave C1)

关键特性

• 自动数据分片
• 内置故障检测和自动切换
• 支持水平扩展（加节点自动 rebalance）
• 去中心化架构（Gossip 协议）

搭建最小集群

# 创建 6 个节点（3 主 3 从）
redis-cli --cluster create \
  192.168.1.101:6379 \
  192.168.1.102:6379 \
  192.168.1.103:6379 \
  192.168.1.104:6379 \
  192.168.1.105:6379 \
  192.168.1.106:6379 \
  --cluster-replicas 1

注意事项

• 不支持跨 slot 的多 key 操作（除非用 hash tag）
• 客户端需要支持 MOVED/ASK 重定向
• 最少 6 个节点（3 主 3 从）

如何选择？

场景	推荐方案
小项目，读多写少	主从复制
中型项目，需要自动容错	Sentinel
大规模，数据量超单机内存	Cluster
对一致性要求极高	考虑其他数据库

生产环境建议

1. 无论哪种方案，都要做好持久化（RDB + AOF 混合模式）
2. 监控 replication lag，异步复制意味着可能丢数据
3. 设置合理的 maxmemory 和淘汰策略
4. 定期演练故障切换流程
5. 客户端配置连接池和重试机制

总结

Redis 高可用不是一步到位的事情，而是随业务增长逐步演进的过程。理解每种方案的原理和取舍，才能在关键时刻做出正确决策。