异地容灾与多活架构

概述

异地容灾与多活架构解决的是区域性灾难（地震、洪水、大面积停电）和数据中心级故障下的业务连续性问题。本文系统梳理容灾模式分类（同城双活/异地双活/异地多活）、技术实现维度（网络/存储/数据库/应用）、分层架构设计、三种技术方案对比、标准化切换流程以及容灾演练方法论。

前置知识

• 高可用架构设计（SLA、CAP、主备/双活/多活概念）
• 参见：高可用架构设计

学习目标

• 区分同城双活、异地双活、异地多活的适用条件
• 理解网络多活、存储多活、数据库双活、应用双活的技术差异
• 掌握容灾分层架构（应用层四层 + 数据层三层）
• 对比存储层/数据库层/存储区域网络层三种容灾方案
• 熟悉容灾切换标准流程与演练方法

一、容灾模式分类

1.1 按地理位置

1.2 按技术实现

1.3 异地双活距离限制

距离限制的根本原因：

典型城市组合（适合异地双活）：北京-廊坊（60km）、上海-苏州（80km）、广州-佛山（30km）、深圳-东莞（60km）。

二、各维度技术实现

2.1 网络多活

通过智能 DNS 将不同运营商用户路由到对应机房：

核心逻辑：按用户运营商路由 → 健康检查 → 故障时回退到其他机房。

2.2 存储多活

通过存储虚拟化层对应用透明，统一管理多地异构存储：

class StorageVirtualization {
  async write(key, data) {
    const node = this.selectOptimalNode(); // 按负载+延迟选最优
    await this.writeToNode(node, key, data);
    this.syncToOtherNodes(node, key, data); // 异步同步
  }
 
  async read(key) {
    const node = this.selectNearestNode(); // 就近读取
    try {
      return await this.readFromNode(node, key);
    } catch {
      return this.readFromOtherNodes(key); // 故障回退
    }
  }
}

2.3 数据库双活

双主架构 + 双向 Binlog 同步，关键配置：

# 北京主库
server-id = 1
auto-increment-increment = 2
auto-increment-offset = 1    # 奇数 ID
 
# 上海主库
server-id = 2
auto-increment-increment = 2
auto-increment-offset = 2    # 偶数 ID

数据冲突解决策略：

2.4 应用双活

应用层多实例 + 负载均衡路由，数据库仍为共享主从：

• 优势：部署简单、成本较低
• 劣势：数据库可能成为瓶颈和单点

三、容灾分层架构

3.1 应用层面四层

3.2 数据层面三层

四、三种容灾方案对比

4.1 选型建议

4.2 数据库层容灾技术

五、容灾切换标准流程

5.1 各阶段要点

5.2 关键指标

六、容灾演练

6.1 演练类型

6.2 演练流程

6.3 演练目的

1. 验证预案有效性：测试切换流程、验证数据完整性、评估恢复时间
2. 发现潜在问题：配置错误、流程缺陷、人员能力不足
3. 提升团队协作：明确职责分工、加强沟通、提高应急能力
4. 持续优化：完善预案、优化流程、更新文档

常见问题

最佳实践

1. 明确 RTO/RPO 目标：根据业务等级制定差异化容灾策略
2. 分级容灾：核心系统双活/多活，非核心系统冷备即可
3. 自动化切换：减少人工介入，缩短 RTO
4. 定期演练：至少每半年一次模拟演练，每年一次实战演练
5. 数据冲突预案：提前确定冲突解决策略，避免切换时犹豫
6. 监控同步状态：实时监控复制延迟，超阈值立即告警

延伸阅读

• 《高可用架构》- 李智慧
• 《业务连续性管理》- ISO 22301
• 阿里云异地多活方案
• MySQL 高可用官方文档

上一篇： 高可用架构设计 下一篇： 高安全架构设计 — 物理安全、数据安全、通信安全、身份安全