知识卡片
异地多活优先保障核心业务而非全部业务
内容
异地多活最容易陷入的误区是想让所有业务都支持多活，但注册、改资料这类涉及全局唯一性约束（如手机号只能注册一次）的业务，多中心并发写入会产生无法调和的冲突。正确做法是优先保障影响面最大的核心业务——比如登录，每个中心存有全量账号密码，某中心宕机可换中心登录；注册、改资料等低频操作短暂不可用，影响远小于千万用户同时登录失败。发散：这是把有限资源投向影响面最大处，而非各业务一视同仁。
参考来源
- 位置：《从0开始学架构》第34章《29｜异地多活设计4大技巧》"技巧1：保证核心业务的异地多活"一节（源文件：_epub-src/OEBPS/Text/part0033_split_002.html）
- 结论依据：原文明确"一个手机号只能注册一个账号，A中心的数据没有同步过来，B中心无法判断这个手机号是否重复"，并总结"优先实现核心业务的异地多活架构！……对于一个日活1000万的业务来说，每天注册用户可能是几万……但登录用户是1000万，很明显我们应该保证登录的异地多活……因为每个中心都有所有用户的账号和密码信息，用户在哪个中心都可以登录"。
- 原始内容：一个手机号只能注册一个账号……B中心无法判断这个手机号是否重复……答案其实很简单：优先实现核心业务的异地多活架构！……登录实现"异地多活"恰恰是最简单的，因为每个中心都有所有用户的账号和密码信息，用户在哪个中心都可以登录。