异地多活与容灾架构深度解析：同城双活、两地三中心与多活设计

RTO（恢复时间目标）：
  从故障发生到系统恢复可用的时间
  - 分钟级 → 业务影响小
  - 小时级 → 大量业务受损

RPO（恢复点目标）：
  允许丢失的最大数据量（时间维度）
  - 0 → 不丢数据（需要强同步复制）
  - 分钟级 → 可能丢最近几分钟数据

两者权衡：
  - RPO=0 需要同步复制 → 跨机房延迟高
  - RTO=0 需要多活 → 复杂度高、成本高
  → 按业务重要性分级设计，不必一刀切全要零

演进路径：

  阶段一：冷备份
    定期备份数据 → 故障时恢复
    RTO/RPO 以天计，仅用于「数据不丢」

  阶段二：主备热备
    备机同步复制，主挂备上
    RTO 分钟级，但备机不承接流量，浪费一半资源

  阶段三：同城双活 / 两地三中心
    双中心同时服务，故障秒级切换
    资源利用率翻倍，但一致性复杂度上升

  阶段四：异地多活（单元化）
    多个城市多机房同时读写，就近接入
    RTO 趋近零，但架构复杂度最高
    → 是大型互联网公司的高可用终极形态

同城双活（单城市两个机房）：
  - 两个机房距离近（几公里~几十公里），专线延迟低（~1ms）
  - 两机房同时承载读写流量
  - 数据库同步复制（同城延迟可接受）
  - 任一机房故障，流量全切到另一机房

优点：
  - RTO 秒级、RPO 可做到接近 0
  - 资源利用率高（两机房都在干活）
难点：
  - 两个机房数据实时一致（同步复制）
  - 仅能应对机房级故障，应对不了城市级灾难

两地三中心（两座城市，三个数据中心）：
  - 城市 A：主中心（同城双活，两个机房互备）
  - 城市 B：灾备中心（异步复制主中心数据）
  - 平时主中心承载流量，灾备中心只做备份

故障场景：
  - 主中心单机房故障 → 同城双活内切换
  - 整个城市 A 故障 → 切到城市 B 灾备中心
    （RPO 有损，可能丢异步复制窗口的数据）

优点：兼顾成本与容灾能力
缺点：城市级切换有数据损失（异步复制）

多活最核心的难题：
  用户数据分散在两个机房，如何保证一致性？

  - 用户 A 落在机房 X，用户 B 落在机房 Y
  - 若两人操作同一数据（好友关系、订单共享、转账）
    → 两个机房各自写，可能冲突

解决思路：
  1. 数据归属（就近写，避免跨机房读写）
     把数据按用户/租户「分片」归属到唯一机房
     → 绝大多数读写都在本机房，避免冲突
  2. 冲突消解（不可避免的跨机房写）
     版本号 / LWW / 时间戳，最终一致
     → 明确哪些数据可接受最终一致
  3. 强一致数据不分流
     全局唯一资源（如账户余额强一致）集中在一个主
     或走分布式事务协调（成本高）

路由设计：
  客户端接入 → 全局负载均衡（GSLB / DNS）
  → 按用户/设备标识路由到「其数据归属的机房」

  路由规则 = 用户ID 取模 / 一致性哈希 / 城市就近
  → 保证「同一用户的读写落在同一机房」
  → 避免「读在 X 写回 Y」的跨机房往返

关键：
  路由规则必须与「数据归属分片规则」一致
  → 路由规则变了（或错了），数据就读写错位

单元化（Cell-based Architecture）：
  把系统按「业务单元」划分，每个单元 = 一套完整应用 + 数据
  - 单元内自治：单元内完成请求闭环（应用、DB、缓存都在本单元）
  - 单元间隔离：一个单元故障不影响其他单元
  - 按用户分片进单元：用户路由到自己的单元

示例：
  - 电商按「用户ID 哈希」分成 N 个单元
  - 用户下单、支付、查订单都在自己单元内完成
  - 跨单元操作（转账、好友关系）走单元间调用或异步解耦

单元化的收益：
  - 天然支持多活：每个单元可部署在任意机房
  - 故障爆炸半径缩小：单元即故障边界
  - 流量可灵活调度：把单元整体迁移到某机房

不可避免的跨机房写冲突，如何消解：
  1. Last-Write-Wins（LWW）
     以时间戳/版本大的为准，简单但可能丢更新
  2. 版本号 + 冲突检测
     乐观锁，冲突时人工/规则合并
  3. 业务约束优先
     某些冲突在业务上可接受（如"最新评论覆盖"）
  4. 主从仲裁
     特定数据（账户余额）固定一个主，其他机房读主

设计原则：
  - 尽量减少跨机房写（靠分片归属）
  - 剩余跨机房写明确「可接受最终一致」的部分
  - 强一致数据（钱、库存强约束）不参与多写

故障切换（Failover）流程：
  1. 检测：探活/监控发现机房故障（网络、DB、应用层多维度）
  2. 决策：确认故障级别 → 决定是否切换、切哪些流量
  3. 路由切换：GSLB/DNS 把流量切到存活机房
  4. 数据接管：活机房接管故障机房的数据分片
  5. 业务恢复：观察指标（错误率/延迟/SLO）
  6. 告警与复盘：记录切换过程，事后复盘

回切（Failback）流程：
  1. 故障机房恢复 → 数据回灌/追赶，先不直接接入
  2. 验证数据一致与业务可用
  3. 灰度切回（小流量→逐步全量）
  4. 回切完成后保持观察

关键纪律：
  - 切换要「预案化」：先演练，再真切
  - 演练常态化：定期做故障注入演练（见混沌工程专题）
  - 避免误切：多重探活确认，防「假故障」触发切换
  - 切得出去也切得回来：回切与切换同等重要
  - 切换决策要「人机结合」：自动检测 + 人工确认重大切换

多活与 CAP：
  - 多活牺牲「分区时的强一致」，换取「持续可用」
  - 分区（机房断连）时，两个机房各自继续服务
    → 各自可写 → 冲突 → 最终一致（AP 取向）
  - 若要求分区时强一致，则必须让其中一个机房停写（CP）

现实选择：
  - 业务分两类处理：
    a. 高可用优先（阅读、下单、社交）→ 多活 + 最终一致
    b. 强一致优先（账户、库存、结算）→ 单主 + 异步降级
  → 不搞「一刀切全强一致」，也不搞「全多活都最终一致」

□ 先按业务定容灾等级，明确 RTO/RPO 目标
□ 同城双活解决机房故障，两地三中心解决城市故障
□ 数据按用户/租户分片归属，就近读写
□ 路由规则与数据分片规则保持一致
□ 跨机房写尽量少，剩余写明确最终一致取舍
□ 强一致数据不参与多写，保留单主
□ 单元化架构缩小故障爆炸半径
□ 切换预案化、演练常态化、回切与切换同等重视
□ 故障切换多维度探活，避免误切

异地多活 = 数据按归属分片 + 路由就近接入 + 单元化隔离，
用「一致性妥协」换「持续可用」，把 RTO 压到秒级。