在分布式系统中，Redis 作为高性能的缓存与存储中间件，其集群的稳定性直接决定业务可用性。而 Redis Cluster 结合主从复制的部署架构，是解决「性能扩展」与「高可用容灾」的核心方案。本文将从架构设计、配置要点、场景适配等维度，拆解 Redis Cluster 从单机房一主一从到多机房一主两从的部署逻辑，助力大家搭建生产级 Redis 集群。
一、核心架构认知：Redis Cluster + 主从复制
很多同学在接触 Redis 集群时，容易混淆「分片」与「主从」的概念。实际上，生产级 Redis 集群的核心是「Redis Cluster 分片集群」与「主从复制」的结合，二者各司其职、缺一不可：
- Redis Cluster（分片集群） ：解决「单节点性能瓶颈」与「数据容量上限」问题。通过将 16384 个哈希槽均匀分配给多个主节点（分片），实现数据的分布式存储与请求路由，业务无需关心数据分片细节，由集群自动完成键的哈希映射与节点转发。
- 主从复制（Master-Slave Replication） ：解决「单节点故障」与「容灾备份」问题。每个主节点绑定若干从节点，从节点通过异步同步机制复制主节点数据，主节点宕机时，从节点可自动晋升为主节点，保证服务不中断。
简单来说，分片决定了集群的「性能上限与扩展性」，主从决定了集群的「可用性与容错能力」，二者结合构成生产环境的最优解。
二、单机房部署：一主一从（低成本高可用）
单机房部署是中小型业务、非核心业务的首选方案，以「8 分片（主节点）+ 8 从节点」（一主一从）为例，核心目标是用最小资源成本解决单点故障问题。
1. 架构设计
每个主节点（分片）对应 1 个从节点，主从节点部署在同一机房的不同物理机/机架（避免机架故障导致同时宕机）。整体架构如下：
总实例数 = 分片数（主节点数）× 2（一主一从），即 8×2=16 个 Redis 实例，每个主节点负责约 2048 个哈希槽（16384/8）。
2. 核心配置（redis.conf）
所有节点需开启 Cluster 模式，关键配置项如下（统一配置，节点端口、文件路径差异化）：
# 开启 Cluster 模式
cluster-enabled yes
# 集群节点配置文件（自动生成，无需手动修改）
cluster-config-file nodes-6379.conf
# 节点超时时间（超过15秒无响应则标记为宕机）
cluster-node-timeout 15000
# 允许部分分片故障时仍提供服务
cluster-require-full-coverage no
# 后台运行
daemonize yes
# 关闭保护模式（生产环境配合密码认证）
protected-mode no
# 集群节点认证密码（所有节点必须一致）
requirepass Redis@123456
# 从节点同步主节点的认证密码
masterauth Redis@123456
# 实例端口（每个实例端口唯一）
port 6379
3. 集群搭建命令
通过 Redis 自带的 redis-cli 工具快速创建集群，指定所有主从节点地址，并设置从节点数量：
redis-cli --cluster create \
192.168.1.10:6379 192.168.1.11:6379 \
192.168.1.12:6380 192.168.1.13:6380 \
...（共16个节点地址）\
--cluster-replicas 1 \
-a Redis@123456
说明：--cluster-replicas 1 表示每个主节点对应 1 个从节点，工具会自动分配主从关系与哈希槽。
4. 适用场景与优势
适合 QPS 中等、数据量适中，且对跨机房容灾无强制要求的业务。核心优势：
- 资源高效：从节点数量与主节点相等，无过多资源浪费；
- 秒级故障转移：主节点宕机后，本地从节点快速晋升，业务无感知；
- 部署简单：无需跨机房网络规划，运维成本低。
三、多机房部署：一主两从（双重容灾保障）
对于核心业务（如支付、内容风控、电商核心链路），需应对机房级故障，此时「一主两从」跨机房部署是标准方案，核心目标是实现「节点级故障 + 机房级故障」双重容错。
1. 架构设计
每个主节点配置 2 个从节点，采用「跨机房部署」策略（以两机房为例）：
主节点部署在主机房 A，1 个从节点部署在主机房 A（本地高可用），1 个从节点部署在备机房 B（跨机房容灾），整体架构为「1 主（A）+ 1 从（A）+ 1 从（B）」。
总实例数 = 分片数 × 3（一主两从），若分片数为 8，则总实例数为 24 个。
2. 关键优化配置
多机房部署需额外优化以下配置，适配跨机房网络特性：
- 调整同步超时：跨机房网络延迟较高，增加 repl-timeout（默认 60 秒）至 120 秒，避免同步超时断开；
- 开启部分同步：启用 repl-diskless-sync yes，减少跨机房同步的磁盘 IO 开销；
- 密码与网络隔离：严格配置密码认证，跨机房网络通过专线或 VPN 连接，禁止公网访问。
3. 集群搭建与主从分配
多机房搭建需手动指定主从关系（避免从节点集中在同一机房），步骤如下：
- 先在主机房 A 创建主节点集群，分配哈希槽；
- 将主机房 A 的从节点加入集群，绑定对应主节点；
- 将备机房 B 的从节点加入集群，绑定同一主节点，完成跨机房同步。
示例命令（给主节点 192.168.1.10:6379 添加备机房从节点）：
redis-cli --cluster add-node \
192.168.2.10:6379 192.168.1.10:6379 \
--cluster-slave \
--cluster-master-id 主节点ID \
-a Redis@123456
4. 容灾能力说明
- 节点级故障：主机房 A 主节点宕机，本地从节点晋升为主节点，业务流量无延迟切换；
- 机房级故障：主机房 A 整体宕机，备机房 B 的从节点晋升为主节点，业务流量切换至备机房，服务持续可用；
- 数据一致性：Redis 异步同步存在微小延迟，可通过业务层幂等性设计弥补少量数据丢失风险。
5. 适用场景与注意事项
适合核心业务、对可用性要求极高（99.99%+），无法接受机房级故障的场景。需注意：
- 带宽预留：跨机房同步需占用大量带宽，需根据写入 QPS 预留足够带宽；
- 资源成本：从节点数量是主节点的 2 倍，资源开销高于单机房部署；
- 运维复杂度：需维护跨机房网络、监控多机房节点状态。
四、两种架构核心差异对比
| 对比维度 | 单机房一主一从 | 多机房一主两从 |
|---|---|---|
| 从节点数量 | 1 个/主节点 | 2 个/主节点 |
| 总实例数 | 2 × 分片数 | 3 × 分片数 |
| 容灾能力 | 应对节点级故障 | 应对节点级、机房级故障 |
| 资源开销 | 低 | 中 |
| 网络延迟 | 本地网络，延迟极低 | 本地操作低，跨机房同步有延迟 |
| 适用业务 | 中小型、非核心业务 | 大型、核心业务 |
五、生产环境额外优化建议
1. 监控与告警
接入 Prometheus + Grafana 监控集群关键指标，如：哈希槽分布、主从同步延迟、节点存活状态、QPS 与内存使用率，设置告警阈值（如同步延迟超过 10 秒告警）。
2. 扩容与缩容
通过 redis-cli --cluster 命令实现无损扩容/缩容，新增主节点时自动迁移哈希槽，缩容时先迁移数据再移除节点，无需停止服务。
3. 死信队列与数据备份
结合业务场景设计死信队列，处理失败任务；开启 Redis 持久化（AOF + RDB 混合模式），定期备份数据，应对极端故障。
4. 客户端适配
使用支持 Redis Cluster 协议的客户端（如 Java 中的 Redisson、Spring Data Redis），客户端会自动缓存哈希槽映射表，提升路由效率。
六、总结
Redis Cluster 结合主从复制的部署架构，是生产级 Redis 集群的核心方案。单机房一主一从是「低成本高可用」的选择，适合非核心业务；多机房一主两从是「双重容灾」的标准，适合核心业务。二者的本质是「资源成本」与「可用性」的权衡，实际部署时需结合业务量级、容灾要求、运维能力综合决策。
后续可进一步探索 Redis Cluster 与第三方工具（如 Codis）的对比、跨区域部署优化等话题，持续打磨 Redis 集群的稳定性与性能。
