单元化方案与跨机房同步方案的对比

应对异地多活的数据一致性问题，业界大致有两条路线，微博和阿里分别代表了这两条路线，各自的适用边界完全不同。阿里选择的是单元化方案：把用户分区，让每个用户相关的所有数据都落在同一个”单元”里——这套方案的优势是能较好地控制成本，因为一旦确定了主维度（阿里选的是买家维度），大部分数据访问都能在单元内部就地完成。但它的缺点也很明显：除了这个主维度之外，其他所有数据仍然要做跨机房同步，整体复杂度并没有真正降低；而且数据按维度拆成至少两份之后，数据查询、扩展、问题排查等各个环节的成本都会明显增加。这条方案更适合业务相对简单、主维度足够清晰的场景（书中判断更适用于国外业务相对简单的应用），不太适合国内这种功能繁杂、业务间依赖众多的应用形态。微博选的是[[延时消息队列解决缓存穿透脏数据]]所代表的跨机房消息同步路线：每个机房维护完整的独立缓存和服务能力，机房之间通过消息队列同步数据，不对用户或数据做单元切分。这条路线的取舍逻辑是：不追求”减少跨机房同步的数据量”（单元化的核心目标），而是接受”几乎所有数据都要做跨机房同步”这个现实，转而把精力投入到把这套同步机制本身做得足够可靠、足够便宜（比如用消息而非双写、用延时补偿而非强一致）。这两条路线的对比说明：面对同一个”异地多活”问题，业务的用户关系结构（是否方便按维度做干净的分区）直接决定了哪条路线更划算——像SNS这类关系高度耦合（好友关系、转发关系跨用户交织）的产品，很难找到一个能干净切分数据的主维度，单元化天然不划算；而买家/卖家关系相对独立的电商场景，则更容易受益于单元化带来的成本优势。