跨城异地：网络延迟质变，逼出"按数据类型分类应对"的设计逻辑

[[同城异区：应对机房级故障的最优架构，及其边界]]应付不了区域级灾难，跨城异地正是为了补上这个缺口而生——把业务部署在距离比较远的不同城市（比如北京和广州，而不是距离很近的广州和深圳），必须”距离远”才能同时应对美加大停电（同城太近扛不住）和新奥尔良水灾（同城异区本身扛不住）这类极端事件。但”距离远”不只是数字上的变化，而是量变引起质变，直接推高了整体架构复杂度——首先是网络传输速度的下降，这不是工程能优化掉的，而是被物理定律锁死的（真空光速约每秒30万千米，光纤中约每秒20万千米，再加上沿途网络设备处理，实际速度还要打折扣）；其次是中间传输链路上大量不可控因素（挖掘机挖断光纤、海底电缆被拖船扯断、骨干网故障，很多线路是第三方在维护，出了问题往往无从预知也无能为力）——比如广州到北京正常RTT大约50毫秒，网络波动时可能飙到500毫秒甚至1秒，遇上丢包问题延迟可能是几秒到几十秒。这些问题同城异区理论上也会遇到，但因为距离短、经过的线路和设备少，发生概率低得多，而且搭多条通道的成本也低；跨城异地则相反，距离远导致这类问题概率更高，搭建或使用多通道的成本也高得多。跨城异地的网络延迟问题给架构设计带来一个看似矛盾的挑战：要做到真正的”多活”，业务系统必须在数据短时间不一致的情况下依然能正常提供服务，但数据不一致业务照理说就不该”正常”——解法的关键在于按数据本身的特性来分类设计。对强一致性要求的数据（如银行存款余额、支付宝余额），实际上根本无法做到跨城异地多活：假设用户A在广州机房把余额从10000转出5000变成5000，此时挖掘机挖断了广州到北京的光缆，广州的变动无法同步给北京，用户A跑到北京一看余额还是10000，于是又转出10000变成0；等他回广州一看余额显示还有5000，又转走5000变成0——结果原本只有10000元的用户A，硬是转出去了20000元，这种漏洞一旦被恶意利用后果不堪设想，正因如此，支付宝这类金融系统的余额数据一般只能用同城异区、不会做跨城异地多活。而对一致性要求不高、或数据变化少、或丢失影响不大的业务（用户登录session、新闻类网站的当日新闻、微博类网站的用户发布内容），跨城异地多活就能很好地派上用场——用户登录数据不一致大不了重新登录，新闻和微博的少量数据丢失对整体业务影响有限。

结构图：

flowchart TB
  A["跨城异地：为应对区域级灾难，距离必须拉远"]
  A --> B["代价：网络延迟质变<br/>物理限速+第三方线路不可控<br/>正常RTT约50ms，波动时可达秒级"]
  B --> C["矛盾：要真多活，就要在数据短暂不一致时<br/>依然正常提供服务"]
  C --> D["解法：按数据特性分类设计"]
  D --> E["强一致性数据(余额/存款)<br/>无法做跨城异地多活<br/>(案例：网络中断期间两地各转一次→多转出一倍)<br/>只能用同城异区"]
  D --> F["低一致性要求/可丢失数据<br/>(session/新闻/微博内容)<br/>适合跨城异地多活"]