什么是异地多活？

面试考察点

1. 概念理解：面试官想看你是否真正理解 “异地” 和 “多活” 这两个词，很多人会把它和 “主备”、“冷备” 混为一谈。真正的多活，多个机房都在对外提供服务，不是备胎。

2. 架构权衡意识：异地多活不是银弹，它牺牲了一致性来换可用性。面试官想听你聊聊 CAP、网络延迟、数据同步这些痛点。

3. 落地经验：纯背概念和真做过的人，一开口就分得出来。比如单元化路由、DTS 数据同步、全局 ID 这些细节，是真踩过坑才说得清的。

核心答案

异地多活：在不同地理位置的多个机房同时对外提供服务，任何一个机房挂了，其他机房能快速接管，业务基本不中断。

异地多活故障自动切换

注意三个关键词：

• 异地：物理距离上拉开（同城双活、两地三中心、跨省多活都算），目的是防火灾、地震、停电、整城断网这类机房级 / 城市级故障
• 多活：每个机房都在干活，不是冷备、热备那种 “备胎”，挂了再切。多活是同时写、同时读
• 业务可用：允许少量数据丢失，只要把故障影响控制在业务可接受范围内

跟几个容易混淆的概念对比一下：

方案	机房角色	切换速度	建设成本	适用场景
冷备	主写，备机不跑业务	几小时	低	小系统、非核心业务
热备	主写，备机同步数据	分钟级	中	一般业务
同城双活	双写双读	秒级	中高	核心业务、容灾机房级故障
异地多活	多写多读	秒级	高	超大流量、城市级容灾

深度解析

一、为什么要搞异地多活

先想一个问题：单机房挂了会怎样？

举个例子，2021 年某云厂商机房光缆被挖断，大量公司业务中断几个小时。如果你的业务只在单机房跑，机房一挂，DB、缓存、应用全挂，这是机房级单点。

那同城双机房够不够？不够。火灾、地震、整城断网这种黑天鹅事件，同城两个机房一起挂。所以才有 “异地”，把机房拉开到不同城市，物理上隔离故障域。

但又不能纯异步备份（冷备/热备），因为切换太慢，业务可能要停几分钟甚至几小时。所以才有 “多活”，平时大家都在干活，挂一个剩下的立刻顶上。

二、异地多活的核心架构

异地多活核心架构

上面是一个典型的异地多活架构，分几个关键层：

• 流量入口层：智能 DNS（或 HTTP DNS）根据用户 ID、地理位置、机房健康度，把请求路由到对应机房。这一层是异地多活的 “大脑”，决定了用户去哪儿
• 应用层：每个机房都有完整的应用集群，能独立对外提供服务
• 数据层：每个机房都有自己的 DB 和缓存，机房之间通过数据同步通道（DTS、Canal、Otter）异步同步数据
• 路由策略：核心是单元化，按业务维度（用户 ID、订单 ID）把数据切分到不同机房，避免跨机房双写冲突

三、最大的痛点：数据一致性

异地多活最难的其实不是搭几个机房，真正难的是数据同步。

为什么难？因为跨地域网络延迟很高：

• 北京到上海专线 RTT 大约 30ms 量级（机房内网一般 < 1ms）
• 北京到广州延迟更高，50ms 以上
• 跨国就更别提了，几百毫秒起步

如果用同步复制（强一致性），用户每次下单都要等另一个机房确认，延迟高到没法用。所以异地多活普遍采用异步复制，牺牲强一致性换性能。

但异步复制会带来新问题：

• 延迟窗口：数据写入 A 机房后，几百毫秒甚至几秒后才到 B 机房
• 数据冲突：同一行在两个机房同时被修改，谁说了算
• 故障切换丢数据：A 机房挂了，最新数据还没同步过去，切到 B 机房就丢

业界主流解决方案是单元化（Cell-based / Set 化），阿里、蚂蚁是最早大规模落地的。蚂蚁的 SOFAStack 把部署单元分成三类：

• RZone：部署可按用户维度拆分的核心业务（比如订单、支付）
• GZone：部署无法拆分的全局数据和业务（比如配置、全局字典）
• CZone：中心化部署的共享服务，给各 RZone 共用

核心思路是：按用户 ID 哈希，把用户划分到固定机房（比如 uid % 3 == 0 走北京，== 1 走上海，== 2 走深圳），每个用户的核心数据只在主单元写，其他单元异步同步只读副本。用户请求通过统一路由层，永远被路由到他的主单元。这样同一个用户的数据只在一个机房写，避免了双写冲突。

代价是：跨单元操作（比如 A 单元用户买 B 单元商家的商品）需要走跨单元调用，会有额外延迟。

阿里云把这套能力做成了商业产品，叫 MSHA（Multi-Site High Availability），一站式做多活管控、单元化、流量调度。

四、关键组件清单

组件	作用	典型实现
智能 DNS	流量入口路由	自研、HTTP DNS、阿里云 HTTPDNS
数据同步通道	DB 异步复制	DTS、Canal+Otter、Debezium
全局唯一 ID	防止跨机房 ID 冲突	雪花算法、Leaf、数据库号段
配置中心	动态切换流量、降级	Nacos、Apollo
服务网关	机房内流量管控	Spring Cloud Gateway、自研网关

五、成本和适用场景

异地多活是真烧钱：

• 至少 3 套机房（一线 + 二线）、3 套完整集群
• 专线 / SD-WAN 跨地域网络，月费动辄百万
• 数据同步链路、流量调度系统、监控告警都要自研或采购

所以真正需要异地多活的场景：

• 大厂核心业务：电商、支付、社交主链路
• 监管要求：金融行业两地三中心是硬要求
• 业务天然异地：跨国公司、连锁零售

中小团队老老实实做主备 + 备份就够了，别为了 “高大上” 上异地多活，运维成本扛不住。

面试高频追问

1. 异地多活和灾备的区别是什么？

• 灾备是备胎，平时不干活，故障了切；异地多活是同时都在干活，故障了影响最小。

2. 异地多活怎么解决数据一致性？

• 主流是单元化，按用户 / 业务维度划分主写单元，配合异步复制。CAP 上选择 AP，最终一致。

3. 同城双活和异地多活有什么区别？

• 同城距离几十公里，网络延迟低（毫秒级），可以做同步双写；异地跨城市，延迟高，只能异步。

4. CAP 理论在异地多活中怎么体现？

• 跨地域网络分区是常态，P 必选；A 和 C 之间，异地多活普遍选 A，牺牲强一致换可用性。

常见面试变体

• “说说你们公司的高可用架构”
• “两地三中心是什么？和异地多活什么区别？”
• “为什么不用同步双写？”
• “异地多活数据怎么同步？延迟怎么处理？”

记忆口诀

异地防灾难，多活防停摆，单元化是关键，最终一致是底线。

总结

异地多活是高可用架构的 “天花板”，核心是 多机房同时干活 + 故障快速接管。真正难的是数据同步和一致性，业界主流解法是单元化。面试聊到这，重点把 “为什么异地、为什么多活、为什么单元化、为什么 AP” 这条线讲清楚，面试官就知道你是真懂。