多活容灾架构：同城双活 vs 异地多活的建设顺序与成本曲线

多活容灾架构：同城双活 vs 异地多活的建设顺序与成本曲线

「我们要做多活」——这句话在很多公司里是一句口号，而不是一个方案。多活不是把系统部署两份那么简单，它是一条从数据层到应用层再到流量层的完整改造链路，每一层都有实打实的成本。做多活之前先想清楚三个问题：为容什么灾、停机多久能接受、预算多少。本文按建设顺序讲清各层级的成本与收益。

一、先分级：你的业务需要哪种多活

容灾建设最忌讳「一步到位」思维。按 RTO（恢复时间目标）和 RPO（数据丢失容忍度）分四档：

多数业务做到同城双活就够了——机房级故障（空调、供电、网络）占了生产事故的大头，城市级灾难是极小概率事件。异地多活主要服务两类需求：监管要求（金融行业的地灾备）和超大规模流量（单城机房装不下）。先想清楚自己在哪一格，不要为极小概率事件付出确定性的复杂度成本。

二、建设顺序：为什么数据层是第一块硬骨头

多活的核心矛盾只有一个：数据只有一个真相，但机房有两个。所以建设顺序必然从数据层开始。

第一步，同城双机房的选择：选同城的两个机房，物理距离 10~50 公里（延迟 1~3ms，MySQL 半同步复制在这个延迟下可以做到 RPO≈0）。跨城延迟通常 20~50ms，同步复制扛不住，只能异步，RPO 就是分钟级——这就是为什么异地多活难。

第二步，数据库层：主库放 A 机房，B 机房放半同步从库。这一步完成后，A 机房挂掉，B 机房提升从库为主，RTO 分钟级。这其实就是「热备」，成本只是多一套从库。

第三步，应用层双活：两个机房都部署完整应用，都连 A 机房主库。B 机房应用跨机房读主库有 2ms 额外延迟，绝大多数业务无感。这一步的关键改造是去掉应用对机房的假设——配置中心统一管理、发布系统双机房同步、本地缓存代替本地文件。

第四步，流量层双活：GSLB/DNS 把用户流量按比例分到两个机房。这一步引入了真正的问题：跨机房流量。用户在 A 机房写入，紧接着的读请求被分到 B 机房，B 从库还没同步到，就是「下单成功但订单列表为空」。解法是会话保持 + 数据路由：同一用户的请求尽量固定在同机房；对一致性敏感的读操作，强制读主库（或读所在机房的同步从库）。

三、异地多活：单元化是唯一的路

同城双活跑稳后，如果业务确实需要异地（监管或容量），单元化的核心思想是：让数据跟着单元走，而不是让数据在单元间狂奔。

按用户维度（通常是 UID 尾号）把流量切分成多个单元，每个单元有自己的数据库，负责自己的用户。用户 A 的所有读写都落在他所在单元的数据库里，跨单元的同步只发生在后台（且是异步、可容忍延迟的）。这需要数据模型天然支持按用户维度切分且用户之间没有强事务——这也是为什么电商（订单按买家切）容易单元化，而银行核心系统（任意账户间转账）极难。

单元化最大的隐性成本是全局数据：库存、账户余额、配置这类不能按用户切的数据。要么集中部署（单元跨城访问，延迟高但量小可接受），要么用全局强一致服务（如分布式锁 + 缓存失效广播），每个全局数据点都要单独设计——这是异地多活项目 80% 工作量的来源。

四、成本曲线：每一步的投入产出

从单机房到同城双活，硬件成本约增加 60%（从库 + 双机房应用冗余），研发改造成本约 2~3 人月，换来机房级故障的分钟级恢复——这是性价比最高的一步。

从同城双活到异地多活，硬件成本接近翻倍，研发成本以人年计（数据正确性验证、双写一致性、全局数据处理），而收益只是城市级灾难的容灾——大部分公司永远用不上。理性的做法是异地只做冷备/热备（异步复制 + 定期演练切换），把「城市真的没了」当作可接受的 RTO 小时级事件。

五、最容易被忽略的一步：演练

多活建设最大的风险不是架构，而是从没真正切换过。切换涉及几十个步骤：流量摘除、主库切换、缓存预热、DNS 生效……任何一步卡住都让「分钟级 RTO」变成故事。标准做法：每季度一次真切换演练，把一半流量切到 B 机房跑一小时再切回来；演练中发现的每个问题（缓存命中率低、定时任务双跑、监控断点）都是真实故障的预演。没演练过的多活，等于没有多活。