{T}

异地容灾与多活架构 学习笔记

一、容灾模式概览

1.1 容灾模式分类

code
容灾模式分类:

按地理位置分类
├── 同城双活(同一城市不同数据中心)
├── 异地双活(不同城市之间)
└── 异地多活(多地同时服务)

按技术实现分类
├── 网络多活(不同运营商之间)
├── 存储多活(逻辑层面对用户透明)
├── 数据库双活(数据库层面冗余)
└── 应用双活(应用层面冗余)

1.2 容灾模式详解

1.2.1 同城双活

定义:同一城市内不同数据中心之间的双活架构

code
同城双活架构示例:

上海地区:
┌──────────────┐      ┌──────────────┐
│ 浦东数据中心  │ ←──→ │ 浦西数据中心  │
│  (Active)    │      │  (Active)    │
├──────────────┤      ├──────────────┤
│ 应用集群      │      │ 应用集群      │
│ 数据库主      │      │ 数据库主      │
│ 存储阵列      │      │ 存储阵列      │
└──────────────┘      └──────────────┘
       ↑                     ↑
       └─────────┬───────────┘
                 │
         低延迟专线连接
          (< 5ms)

特点:
- 地理距离近(通常 < 50km)
- 网络延迟低(< 5ms)
- 数据同步快
- 成本相对较低

优势与挑战

优势挑战
网络延迟低仍可能受城市级灾害影响
数据同步快建设成本较高
运维相对简单需要专线连接
切换速度快-

适用场景

javascript
const同城双活Scenarios = {
  // 场景1: 金融核心系统
  finance: {
    requirement: 'RTO < 5分钟, RPO < 1分钟',
    implementation: '两地三中心(同城双活 + 异地灾备)'
  },
  
  // 场景2: 电商交易系统
  ecommerce: {
    requirement: '高可用、低延迟',
    implementation: '同城双活 + 异地冷备'
  },
  
  // 场景3: 政务系统
  government: {
    requirement: '数据安全、业务连续',
    implementation: '同城双活 + 异地灾备'
  }
}

1.2.2 异地双活

定义:不同城市之间的双活架构,通常距离不超过 100 公里

code
异地双活架构示例:

北京数据中心                天津数据中心
┌──────────────┐           ┌──────────────┐
│  北京中心     │ ←───────→ │  天津中心     │
│  (Active)    │           │  (Active)    │
├──────────────┤           ├──────────────┤
│ 应用集群      │           │ 应用集群      │
│ 数据库主      │           │ 数据库主      │
│ 存储阵列      │           │ 存储阵列      │
└──────────────┘           └──────────────┘
       ↑                          ↑
       └──────────┬───────────────┘
                  │
          专线连接
         (距离 < 100km)
         (延迟 < 10ms)

限制因素:
- 地理距离:不超过 100km
- 网络延迟:数据库同步延迟 < 10ms
- 专线成本:距离越远成本越高

距离限制原因

javascript
// 异地双活距离限制分析
const distanceLimitation = {
  // 1. 网络延迟
  networkLatency: {
    formula: '延迟 = 距离 / 光速 × 2(往返)',
    example: {
      distance: 100,  // km
      speed: 200000,  // km/s(光在光纤中的速度)
      latency: (100 / 200000) * 2 * 1000,  // ms
      result: '1ms 单程, 2ms 往返'
    },
    
    problem: '数据库同步需要多次往返通信,累积延迟影响性能'
  },
  
  // 2. 数据一致性
  dataConsistency: {
    challenge: '距离越远,同步延迟越大',
    impact: [
      '主从延迟增加',
      '数据冲突概率提高',
      '事务响应时间变长'
    ]
  },
  
  // 3. 成本因素
  cost: {
    items: [
      '专线租赁费用(按距离收费)',
      '网络设备成本',
      '运维人力成本'
    ],
    example: '100km 专线成本可能是 10km 的 5-10 倍'
  }
}

典型城市组合

code
中国典型异地双活城市组合:

京津冀地区
├── 北京 - 天津(约 120km)
├── 北京 - 石家庄(约 280km)
└── 北京 - 廊坊(约 60km)

长三角地区
├── 上海 - 杭州(约 180km)
├── 上海 - 苏州(约 80km)
└── 上海 - 无锡(约 130km)

珠三角地区
├── 广州 - 深圳(约 140km)
├── 广州 - 佛山(约 30km)
└── 深圳 - 东莞(约 60km)

注:  适合异地双活
    距离较远,需要评估延迟影响

1.2.3 网络多活

定义:不同运营商之间的多活架构

code
网络多活架构:

用户请求
    ↓
┌─────────────────┐
│  智能 DNS 解析   │
└────────┬────────┘
         │
    ┌────┼────┬────────┐
    │    │    │        │
    ↓    ↓    ↓        ↓
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│电信 │ │联通 │ │移动 │ │BGP  │
│机房 │ │机房 │ │机房 │ │机房 │
└──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘
   │       │       │       │
   └───────┼───────┼───────┘
           │       │
      统一数据层
   (跨运营商同步)

特点:
- 覆盖不同运营商用户
- 提升访问速度
- 降低跨网延迟
- 提高可用性