同程旅行 MySQL 双中心构建实战：从需求拆解到容灾演练的全流程解析

一、双中心建设的核心目标与需求拆解
同程旅行在 2021 年启动 MySQL 双中心项目，核心目标是实现机房级容灾，确保 A 中心故障时 B 中心能独立支撑核心业务，保障服务稳定性。项目启动前需明确三个关键问题：

WHAT（做什么）：确定纳入双中心的业务范围。初期聚焦核心业务（如核心应用 A/B/C），涉及 20000 + 应用、10000+MySQL 数据库及 40000+Redis/MongoDB 实例。通过 SRE 与 DBA 联合梳理应用列表与数据库依赖关系，利用配置中心抓取会话地址，最终形成双中心业务清单。
WHY（为何做）：区别于传统异地灾备的 “冷备份” 模式，双中心要求 B 中心具备实时读写能力，满足业务连续性需求。原有的异步复制架构因延迟高、切换风险大被淘汰，需构建低延迟、高可用的集群架构。
WHEN（何时完成）：分阶段推进建设，2021 年 3 月启动摸底与首批设备采购，5 月完成 B 中心节点搭建，8 月实现核心业务写库切换，12 月通过断网演练验收。
二、技术架构设计与实施策略
（一）架构选型与优化
初期方案（传统主从架构）：采用 MariaDB+MySQL 组合，A 中心主库通过 MHA 管理 Slave 节点，B 中心作为灾备集群。但该架构存在 “机房切换模块与数据库强耦合” 问题，切换时需手动调整应用配置，导致业务中断风险高。
优化方案（解耦架构）：引入公有云资源构建中心 C，通过智能解析模块（TVS+Proxy）实现应用与数据库 IP 解耦。APP 调用统一 VIP+VPORT，底层通过 Proxy 动态路由至 A/B 中心数据库，切换时仅需修改解析规则，无需重启应用。该架构支持读写分离，读请求可负载至 B 中心 Slave 节点，提升资源利用率。
（二）实施策略与风险控制
分批次切换：避免一次性迁移带来的业务冲击，选择业务低峰期（如夜间）执行操作。先为每个集群在 B 中心添加节点，通过自动化工具（如节点配置系统）批量完成环境初始化，再逐步将写流量切换至 B 中心主库。
自动化与监控：开发数据库节点自动化管理平台，支持集群创建、节点添加 / 删除等操作，单次节点部署耗时从人工 3 小时缩短至自动化 10 分钟。结合 Grafana 实时监控复制延迟、连接数等指标，设置阈值告警，提前发现主从同步异常。
三、断网演练：从异常复盘到验收标准
（一）演练流程与关键指标
断网演练是双中心验收的核心环节，目标为：A 中心断网后，B 中心在 10 秒内自动接管业务，且数据零丢失、业务恢复率 100%。具体步骤如下：

网络隔离：通过 SDN 控制器切断 A 中心数据库集群网络连接，模拟机房级故障。
状态验证：利用会话采集器（Processlist 监控）检查是否有 A 中心 IP 访问残留，通过 MySQL 复制状态接口验证 B 中心主库角色是否激活。
业务验证：调用核心业务接口（如订单查询、用户登录），确保请求路由至 B 中心且响应正常。
（二）异常复盘与优化
首次演练暴露两大问题：

网络隔离不彻底：部分集群因防火墙规则未同步，仍存在 A 中心节点通信，通过自动化脚本批量校验并更新防火墙策略解决。
应用依赖未完全迁移：个别应用硬编码 A 中心数据库 IP，导致切换后连接失败。通过配置中心强制扫描并替换所有硬编码地址，实现依赖关系全解耦。

最终演练结果显示，98% 的集群在 10 秒内完成切换，核心业务恢复时间控制在 1 分钟内，满足验收标准。

四、未来规划：技术债务与长期演进
（一）技术债务解决
当前架构仍存在部分历史遗留问题：

异步复制延迟：部分非核心业务仍使用异步复制，计划引入半同步复制或 Group Replication 提升一致性。
容器化改造：现有数据库节点基于物理机部署，后续将迁移至 K8s 容器平台，实现资源弹性调度与快速扩缩容。
（二）容灾能力升级
两地三中心拓展：在现有 A/B 双中心基础上，于公有云部署第三中心（C 中心），形成 “本地 + 云端” 的混合容灾架构，应对区域性自然灾害等极端场景。
智能化切换：结合机器学习预测数据库故障，在主库出现异常前自动触发切换，变 “被动容灾” 为 “主动预防”。
总结
同程旅行 MySQL 双中心建设是一场 “目标驱动、分阶落地” 的技术实践。通过明确业务边界、解耦架构设计与自动化工具支撑，成功实现核心业务容灾能力从 “分钟级恢复” 到 “秒级切换” 的跨越。未来将持续优化底层架构，推动容灾体系向智能化、云原生方向演进，为业务高速发展提供更坚实的数据保障。