跨地域全球数据库部署中解决亚洲用户访问高延迟的架构方案咨询

首先要明确：你提到的Facebook、Zoom、StackOverflow、Jira这些应用，没有一个采用“跨区应用服务器直连远地主库”“跨区全量实时同步数据库副本”这类硬扛方案，他们的低延迟体验本质是流量分层解耦+就近承接+按需回源的架构设计，没有任何玄学成分。

头部应用的跨区架构核心逻辑 #

• 把所有请求按访问特征拆分，80%以上的通用请求直接在离用户最近的边缘节点承接，根本不回源到核心集群
• 不追求跨区节点和核心主库的能力完全对等，跨区节点只承接能在本地处理的流量，剩下的少量请求通过高带宽专线批量回源
• 对强一致性要求的请求做专属路由，不盲目追求所有流量的绝对就近

针对现有基础设施的具体落地步骤 #

你当前的硬件资源富余度很高（应用服务器、DB服务器的日间CPU峰值仅15-20%），之前碰到的延迟高、复制延迟不可控的问题，本质是架构设计思路走偏了，完全不需要额外采购大量资源，按照下面的步骤调整就能达到接近大厂的访问体验：

1. 先做流量分层，不要让亚洲应用节点承接全量读写流量 #

• 亚洲区应用节点只就近承接两类本地可处理的请求：
  • 静态资源渲染、通用页面内容加载这类完全不需要查DB的请求
  • 对实时一致性要求不高的公开查询（比如文章列表、公开用户资料、历史内容页），这类请求直接打在你已经在亚洲区建好的数据库副本上，不需要跨区回源
• 把所有写请求（提交评论、修改信息、下单这类操作）从亚洲应用节点的本地处理链路剥离，不要单个请求单独走跨区链路回源美区主库：
  • 亚洲应用节点先把写请求存在本地SSD的持久化队列里，攒够固定批量大小或者10ms的等待窗口，再通过跨区专线批量回源到美区主库
  • 把非核心的埋点、日志类写请求直接落在亚洲区本地存储，根本不需要实时同步回主库，靠后台异步任务批量同步即可

  绝大多数业务的写请求占比不到总流量的10%，哪怕跨区链路的单次往返延迟是200ms，通过批量回源的方式，用户实际感知的延迟和本地写入的差距不会超过50ms。

2. 换掉之前手动搭的逻辑同步链路，用Aurora原生的跨区物理复制 #

你之前碰到的亚洲区数据库复制延迟高的问题，本质是用了逻辑binlog同步的方案，这类方案天生存在跨区链路下延迟高的问题：

• 直接把亚洲区的数据库实例配置为美区Aurora主库的原生跨区物理读副本，这个复制逻辑是基于存储层的日志物理传输，性能比逻辑同步高一个量级
• 给亚洲副本和主库之间的跨区链路开通足够的专线带宽，很多人第一次试跨区Aurora副本的时候发现延迟好几秒，本质是默认的低带宽配置下物理日志传输卡顿，把带宽提到和本地副本之间的链路带宽一致，通常1Gbps的带宽就可以把复制延迟稳定控制在200ms以内，完全可以满足绝大多数读请求的一致性要求

3. 用本地缓存承接高频查询，把大部分请求挡在数据库前面 #

你现有的应用服务器内存、CPU都有大量富余，完全可以在亚洲区的应用节点上加一层本地内存缓存：

• 把高频访问的查询结果（比如首页内容、热门页面、固定展示的用户信息）存在本地内存里，设置10-60s的过期时间，这类请求根本不需要打到数据库副本上，用户访问延迟可以压到50ms以内
• StackOverflow的生产环境里，70%以上的数据库请求都是靠服务器本地内存缓存承接的，从来不会打到数据库层，就算主库在几千公里外，用户也感知不到跨区的延迟。

4. 对强一致性请求做动态路由，不要盲目追求绝对就近 #

碰到需要强一致性的请求（比如用户刚提交完订单，马上要查看支付结果），不要把用户的请求直接随机路由到就近节点：

• 只要用户触发了写操作，就把他后续一段时间的请求临时路由到能承接他写操作的节点，等他的写操作已经同步到就近的亚洲副本后，再把他的流量切回本地就近节点
• 这个路由逻辑就是Facebook全球流量调度的核心：不把所有请求硬拉到最近的节点，而是根据用户的实时操作状态动态调整路径，既保证就近访问的低延迟，又避免出现用户刚提交的内容在本地副本上看不到的体验问题。

内容的提问来源于stack exchange，提问作者Vikas Mishra