技巧2：保证核心数据最终一致性，而非追求实时全量同步

[[技巧1：保证核心业务的异地多活，而非所有业务]]之后还有一个常见的思维误区：”我要让所有数据都实时同步”。异地多活本质上是靠异地数据冗余来保证极端异常下业务依然可用，数据同步自然是核心，但同步速度受制于光速和网络传播速度这类物理定律，业务上想要”越快越好”和物理上”注定做不到很快”，这是一个无法彻底消除的矛盾，因此追求所有数据实时同步本身就是个达不到的目标。面对这个无法根治的矛盾，只能想办法降低影响，有三种可参考的方法。一是尽量缩短异地多活机房之间的距离、搭建高速网络——思路和同城异区类似，但跨城场景下搭高速网络的成本远超同城异区，一般只有资金雄厚的大公司才承担得起。二是尽量减少要同步的数据，只同步真正核心业务相关的数据——比如用户子系统里登录产生的token/session信息，数据量很大但完全不需要同步，因为丢了大不了让用户重新登录一次拿回来，这点体验代价比起同步全部数据的成本要划算得多。三是只追求最终一致性、不追求实时一致性——这正是BASE理论的具体应用，业务不依赖数据同步的实时性，只要求数据最终能收敛一致即可，比如A机房新注册的用户，正常情况下允许5分钟内同步到所有机房，异常情况下甚至可以放宽到1小时甚至1天。最终一致性落地时还要按数据特征做差异化处理：账号信息如果同步窗口内用户恰好跑到了还没收到数据的机房，就需要按路由规则回A机房现场取一次数据以保证业务正确；用户信息哪怕5分钟内还没同步也不至于出错，只是用户可能暂时看到旧信息，属于可以接受的体验代价而不需要额外补救措施。

结构图：

flowchart TB
  A["矛盾：业务要求快速同步 vs 物理定律决定同步注定不快"]
  A --> B["方法①缩短机房距离+建高速网络<br/>成本远高于同城异区，只有大公司能承担"]
  A --> C["方法②只同步核心相关数据<br/>如session/token不同步，丢了重新登录即可"]
  A --> D["方法③保证最终一致性而非实时一致性<br/>=BASE理论的具体应用"]
  D --> D1["账号信息：同步窗口内访问到旧机房<br/>需按路由规则回源取数据保证正确"]
  D --> D2["用户信息：短暂不一致可接受<br/>只是用户看到旧信息，无需额外补救"]