面经策

公司目前有一些海外业务，从国内将数据发送到海外延迟比较大，如何处理这个问题？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

国内到海外的数据传输高延迟（跨洋 RTT 200~300ms），这个问题我会先反问业务形态——"海外业务"是"国内系统服务海外用户"，还是"真正的本地化出海运营"？两种的战略解法完全不同，只谈网络优化是低层次的。

第一层判断：业务架构决策（最重要的答案）

  • 数据要合规留在海外（GDPR/各国数据法）：海外独立部署 Region——用户数据本地存本地算，跨境只传汇总统计（脱敏聚合数据）。这不是延迟问题，是法律问题，迟做被动
  • 海外只是流量入口，主系统在国内：全球加速（Anycast、专线/加速通道如云厂商全球加速服务）把 RTT 从 300ms 压到 80~100ms——治标，适合过渡期
  • 真正的本地化运营（本地支付、本地供应链）：核心链路整体出海部署，国内保留管理面，这是终点方案

第二层：技术优化（在架构定调后）

  • 就近接入：CDN 静态资源海外节点、API 网关海外部署
  • 读写分离遵循用户就近：海外用户读写海外库，跨境走异步复制——异步意味着接受秒级延迟的数据不一致，全局强一致跨国就是性能死局
  • 请求合并与协议优化：减少跨境 RPC 次数（一次聚合调用代替五次串行）、HTTP/2 多路复用、Protobuf 压缩、长连接复用
  • 异步化跨境链路：跨境同步走 MQ/批量文件，不阻塞用户请求

业务视角收尾：海外延迟问题的投入产出排序是：先算用户分布和增长预期——海外只占 5% 流量，全球加速解决 80% 体验问题，成本是 Region 化部署的零头；海外是战略市场，就果断 Region 化，早期多花的架构钱比后期迁移便宜一个数量级。另外别忽略合规咨询成本，数据跨境的法律风险比延迟更贵。

🏗 系统架构师 ​

跨洋延迟是物理问题（光速限制，中美 RTT 150~250ms，无法消除），架构策略是让数据离用户近、让必要跨洋传输变少变异步。我按方案递进：

1. 就近部署 + 单元化（根本解法） 海外用户访问海外机房：全球按地域划分单元（美西、欧洲、东南亚），用户请求 DNS/GSLB 智能解析到就近接入。每个单元是完整的"接入+应用+数据"闭环，写本地读本地，跨洋只剩异步复制流量。这是国内大厂出海的标准架构（阿里的单元化、TikTok 的多 region）。

2. 数据同步策略（单元化的核心难点）

  • 就近写 + 异步双向复制：DTS/otter 做 MySQL 跨洋复制，冲突用时间戳或业务分区规则消解
  • 数据分区归属：用户数据按归属地切分（美国用户的数据主副本在美区），跨区访问走 RPC 或全局服务——避免双写多活，除非业务能接受冲突
  • 全球只读数据（商品、类目、配置）：主写一处，异步广播到各区域，各地读本地副本，最终一致即可

3. 交互链路优化（没法单元化时）

  • 异步化：跨洋调用从同步链路里挪出去，MQ + 回调；用户侧体验从"每次等 200ms"变成后台完成
  • 请求合并与预取：一次跨洋拉全量所需数据，避免多次 RTT；配合本地缓存，命中率越高跨洋次数越少
  • 协议优化：长连接复用（省握手）、HTTP/3/QUIC（弱网抗丢包）、压缩报文
  • 边缘计算：静态与半动态内容下沉 CDN/边缘节点，动态 API 走全球加速网络（如云厂商的 GAAnycast 链路优化路由，RTT 可降 30%+）

4. 一致性取舍：跨洋场景我默认放弃强一致：全局数据（汇率、合规）单点写，区域数据本地写，账务类跨区操作走异步消息 + 对账，把 200ms 的同步代价变成后台任务。

一句话：物理延迟消不掉，就用单元化把读写放近，把跨洋流量变成异步复制。

💻 全栈开发专家 ​

跨境延迟大，我的处理思路是先测量、再分层优化：物理加速 + 架构就近 + 传输异步化。

第一步：定位延迟构成

先用 mtr / tcping 跑国内到海外的链路，分清三类问题：纯 RTT（物理距离，上海到美西单程 70ms+ 起步，改不掉）、丢包重传（跨境公网常见）、服务自身处理慢。对症下药才有意义。

物理层：加速链路

  • 上 CN2/GIA 优质线路，或用云厂商跨域加速产品（阿里云全球加速 GA、AWS Global Accelerator），本质是走专线骨干网，丢包从 5% 降到 0.1%，效果立竿见影。
  • 协议优化：内核开 BBR 对抗高延迟丢包；HTTP 换 gRPC（HTTP/2 多路复用，连接复用减少握手往返）。

架构层：让数据少跨洋

  • 接入下沉：海外用户访问的 API 部署在海外 Region，"读本地、写异步"，只有强一致数据才跨洋。
  • 异步批量：同步单条调用改成 MQ 异步 + 攒批压缩传输，把 1000 次 200ms 往返变成 1 次批量传输，总延迟反降。
  • 数据复制：配置类、元数据类数据用 CDC（Debezium → Kafka）同步到海外库，海外读本地副本。

落地建议

2026 年的实际项目里，成本允许就"海外独立部署 + 数据异步同步"，成本紧张就"专线加速 + gRPC + 请求合并"过渡。最忌讳不测量就盲目上代理，若瓶颈其实在 TLS 握手次数，该做的是连接复用而不是换线路。