技巧1：保证核心业务的异地多活，而非所有业务

[[跨城异地：网络延迟质变，逼出”按数据类型分类应对”的设计逻辑]]是异地多活里复杂度最高的一种，很多架构师容易陷入一个思维误区：”我要让所有业务都实现异地多活”。以一个用户子系统为例（负责注册、登录、用户信息三个业务，采用按邮箱/手机号哈希路由到不同中心的用户分区架构），如果强求三个业务都做异地多活，会撞上几乎无解的问题：注册业务上，A中心注册的用户数据还没同步到B中心时A中心宕机，如果让用户改去B中心注册，B中心根本判断不出这个手机号是否已经在A中心注册过（一个手机号只能注册一个账号是核心业务规则，为了架构设计去改这条规则代价极高，几乎所有业务都要跟着重新设计，得不偿失），如果不让B中心注册，多活又成了空谈——这个矛盾本质上无解；用户信息业务上，A、B两个中心异常时都被修改，靠”最后修改时间生效”来合并看似简单，但异地多中心网络下根本无法保证所有机器时间绝对一致，哪怕误差超过1秒，先改的反而可能覆盖后改的，靠全局唯一递增ID解决又要求这套ID生成系统本身也做异地多活，成本极高。真正的答案是：优先实现核心业务的异地多活，而不是所有业务。以这个案例来说，”登录”才是真正的核心业务——一个日活1000万的产品，每天新增注册可能只有几万、修改用户信息的不到1万，但每天登录的是1000万，注册不了对新用户影响不明显（他还没真正用起业务），用户信息改不了影响也有限，但如果几百万用户登录不了，等于几百万用户直接用不了产品，客服热线会被打爆、社交媒体上到处传”业务宕机”，这才是真正的互联网大事件。而且登录恰恰是最容易做到异地多活的——因为每个中心都存有全量用户的账号密码信息，用户在哪个中心登录都可以，A中心宕机了，用户直接去B中心重新登录即可。