同城双活架构：定义、模型与实战

同城双活，说白了就是在一个城市里搞两个数据中心，都能对外提供服务。我见过不少团队一上来就奔着“两地三中心”去，结果连同城双活都没跑通。其实，同城双活是容灾架构里性价比最高的方案之一，也是我个人的首选。

什么是同城双活？

两个数据中心，物理距离在50公里以内，通过专线互联。平时两个中心都承载业务流量，任何一个挂了，另一个能全量接管。注意，是“全量”，不是降级。

为什么强调同城？因为距离近，时延低。我做过测试，50公里光纤的往返时延大概在1ms以内。这个数字很关键，它决定了你的数据同步方案能不能跑通。

架构模型：我常用的两种

同城双活的架构模型，我归纳下来就两种：对称型和不对称型。

对称型架构

两个数据中心完全对等。每个中心都有完整的应用层、服务层、数据层。流量随机分发，谁接到请求谁处理。这种模型的好处是资源利用率高，能达到50%以上。坏处是数据冲突处理复杂。

我记得有一次帮一家电商公司做架构，他们坚持用对称型。结果双十一当天，两个中心同时修改了同一件商品的库存，数据一同步就乱了。嗯，这里要注意，对称型架构必须做好冲突检测和回滚机制。

不对称型架构

一个中心处理写请求，另一个中心主要处理读请求。写中心把数据同步到读中心。这种模型简单，数据一致性容易保证。但读中心的资源利用率可能只有30%-40%。

我个人习惯用不对称型。为什么？因为大部分业务场景是读多写少。你想想看，一个电商平台，浏览商品的人永远比下单的人多。不对称型刚好匹配这个特点。

数据同步方案：同步复制 vs 异步复制

数据同步是同城双活的核心。选错了方案，整个架构就是空中楼阁。我见过太多人在这上面栽跟头。

方案	原理	RPO	RTO	对性能影响
同步复制	写操作必须等两个中心都确认才返回	0	秒级	较大，增加写时延
异步复制	写操作在主中心确认后立即返回，后台同步	秒级到分钟级	分钟级	较小，几乎无影响

同步复制

数据零丢失，但性能有代价。我曾经给一个金融客户做方案，他们要求RPO必须为0。没办法，只能上同步复制。结果上线后发现，写操作的时延从原来的2ms飙升到了8ms。

为什么会这样？因为每次写操作都要等两个中心都落盘。专线再好，也有物理极限。所以同步复制适合对数据一致性要求极高、写并发不高的场景。比如支付、订单核心链路。

异步复制

性能好，但有数据丢失风险。异步复制是大多数互联网公司的选择。为什么？因为大部分业务能接受几秒钟的数据丢失。比如用户发了一条动态，丢了就丢了，刷新一下可能就回来了。

我建议的做法是：核心链路用同步复制，非核心链路用异步复制。这样既保证了关键数据不丢，又不会拖垮整体性能。

DNS智能解析与流量调度

数据层搞定了，流量怎么分？这就轮到DNS智能解析上场了。

DNS智能解析，说白了就是根据用户的地理位置、运营商、负载情况，把请求解析到不同的数据中心。比如，北京的用户解析到北京中心，上海的用户解析到上海中心。

我常用的流量调度策略有三种：

• 基于地理位置：就近接入，降低时延。适合全国性业务。
• 基于权重：按比例分配流量。比如A中心70%，B中心30%。适合灰度发布或容量调整。
• 基于健康检查：自动摘除故障节点。这是保底策略，必须要有。

这里有个坑要注意。DNS有缓存，TTL设置不合理的话，故障切换会很慢。我曾经遇到过，一个数据中心挂了，但DNS的TTL设了10分钟。结果10分钟内，还有大量用户往故障中心发请求。嗯，后来我把TTL调到了60秒，配合客户端重试机制，才算解决。

核心逻辑图

下面这张图是我自己画的，把同城双活的核心逻辑串起来了。你看一遍应该就能理解整体架构。

这张图展示了同城双活的核心流程：用户请求先经过DNS智能解析，根据策略分发到两个数据中心。数据中心之间通过专线进行数据同步。同时，健康检查模块持续监控两个中心的状态，一旦发现异常，自动切换流量。

总结一下

同城双活架构，核心就三件事：

• 两个中心都能处理流量，不是一主一备
• 数据同步方案要根据业务选，别盲目追求RPO=0
• 流量调度要有多层保障，别只靠DNS

我做了这么多年架构，最大的感受是：没有完美的方案，只有合适的方案。同城双活不是银弹，但如果你能把数据同步和流量调度这两件事做好，它绝对是最实用的容灾手段之一。