4. 多活容灾总体设计

多活容灾不是“把系统部署到两个机房”这么简单,它是一套围绕业务连续性目标(RTO/RPO)展开的整体工程。总体设计的核心任务,是在选址、网络、流量调度、数据同步与技术选型之间找到平衡点:既要满足监管对灾难恢复的要求,又要控制成本与运维复杂度。本章从五个维度拆解多活总体设计方法。

一、多活数据中心选址

选址决定了容灾的物理上限。核心银行系统通常要求同城双活加异地灾备,或两地三中心。选址需重点评估以下因素:

  • 地理距离:同城双活一般控制在30~100公里,保证光纤时延低于2ms;异地灾备建议800公里以上,规避区域性灾害。
  • 地质与气候:避开地震带、洪涝区、台风高频路径,两地不宜处于同一地震带或同一电网枢纽。
  • 电力与网络资源:双路市电、独立UPS、多家运营商骨干接入,避免单点依赖。
  • 监管合规:金融行业需满足两地三中心或同城双活+异地灾备的监管指引。
选址阶段就要明确每个站点的角色:生产主中心、同城双活中心、异地灾备中心,角色不同,资源投入与切换策略完全不同。

二、网络架构设计

多活网络的核心是低时延、高可靠、可隔离。典型架构采用DCI(数据中心互联)专线,配合VXLAN或OTV实现二层延伸,同时通过BGP实现三层路由冗余。关键设计点包括:

  • 同城双活采用裸光纤或DWDM,时延控制在1~2ms,满足数据库同步复制要求。
  • 异地灾备采用运营商专线,时延通常10~30ms,适合异步复制。
  • 网络分区设计:生产区、DMZ区、管理区、存储区严格隔离,跨中心流量走独立DCI链路。
  • 路由策略:主备路由+BFD快速检测,故障切换时间控制在秒级。
# 典型DCI链路健康检查配置示例
interface GigabitEthernet0/1
 description DCI-to-DC2
 ip address 10.100.1.1 255.255.255.252
 bfd interval 50 min_rx 50 multiplier 3
!
router bgp 65001
 neighbor 10.100.1.2 remote-as 65002
 neighbor 10.100.1.2 fall-over bfd

三、流量调度策略

流量调度决定用户请求落到哪个中心。常见方式有DNS调度、GSLB、Anycast和客户端SDK调度。核心银行场景推荐GSLB+应用层健康探测组合:

调度方式切换粒度典型时延适用场景
DNS轮询分钟级高非核心查询类
GSLB秒级中同城双活入口
Anycast秒级低异地多活
应用层SDK毫秒级极低核心交易链路

调度策略需与数据同步策略匹配:同步复制场景下,流量可双活分担;异步复制场景下,写流量应集中主中心,读流量可分流。

四、数据同步策略

数据同步是多活容灾中最难的部分。核心原则是:先定RPO,再选同步方式。

  • 同步复制:RPO=0,但受网络时延限制,仅适合同城双活,且需考虑仲裁机制防止脑裂。
  • 异步复制:RPO>0,适合同城与异地,需监控复制延迟并设置告警阈值。
  • 半同步复制:折中方案,至少一个备库确认,兼顾性能与可靠性。
  • 逻辑复制与CDC:适用于异构数据库或多活单元化场景,通过binlog/redo解析实现数据分发。
脑裂是多活最大的风险。必须引入第三方仲裁节点或Quorum机制,确保任一时刻只有一个中心可写。切换前务必确认原主中心已停止写入。

五、整体技术选型

技术选型需覆盖计算、存储、数据库、中间件与调度层。以下为典型选型清单:

  • 计算层:Kubernetes多集群+联邦调度,或虚拟机+双活集群。
  • 数据库:Oracle ADG、MySQL MGR、OceanBase、TDSQL等支持多副本的分布式数据库。
  • 存储层:SAN双活网关或分布式存储跨中心复制。
  • 中间件:消息队列跨中心镜像、Redis多活集群。
  • 调度层:GSLB+健康探测+自动化切换编排平台。
多活容灾总体设计五维关系图 多活总体设计 RTO / RPO 目标驱动 选址 距离·地质·电力·合规 网络架构 DCI·VXLAN·BGP·BFD 流量调度 GSLB·Anycast·SDK 数据同步 同步·异步·半同步·CDC 技术选型 计算·存储·数据库·中间件 约束 支撑 驱动 依赖 落地

六、常见误区与复盘

在实际项目中,多活设计最容易踩的坑集中在以下几点:

  1. 只做机房冗余,不做数据一致性设计:切换后发现数据丢失或冲突,RPO不达标。
  2. 忽略脑裂防护:双写导致数据错乱,修复成本极高。
  3. 流量调度与数据同步不匹配:异步复制却让写流量双活,造成主键冲突。
  4. 切换演练不足:真实故障时切换脚本失效,RTO远超预期。
  5. 过度追求RPO=0:异地同步复制导致交易时延飙升,反而影响生产性能。
复盘建议:每季度至少进行一次真实切换演练,覆盖网络中断、数据库主库宕机、GSLB故障三种场景,并记录实际RTO/RPO与目标的差距,持续优化切换编排脚本。

总体设计完成后,应输出一份《多活容灾总体设计说明书》,明确各中心角色、网络拓扑、调度策略、数据同步方式、切换流程与演练计划,作为后续详细设计与实施的基础依据。