多机房多活架构

• b连业务服务;
• 业务服务连基础服务;
• 服务连数据库，主库写，从库读，读写分离;

上述架构，每个机房是一套独立的系统，仅仅通过异步数据同步获取全量数据，当发生机房故障时，将流量切到另一个机房，就能冗余“机房级”故障，实现高可用。

上述多机房架构存在什么问题?

“异步数据同步”存在延时(例如：1min)，这个延时的存在，会使得两个机房的数据不一致，从而导致严重的业务问题。

举个例子，某一个时刻，用户X有余额100元，两个机房都存储有该余额的精准数据，接下来：

• 余额100，X在北京(就近访问机房A)消费了80元，余额仅剩20元，该数据在1分钟后会同步到机房B;
• 余额100，X的夫人在广州(就近访问机房B)用X的账号消费了70元，余额剩余30元，该数据在1分钟后也会同步到机房A;

从而导致：

• 超额消费(100余额，却买了150的东西);
• 余额异常(余额是20，还是30?);

上述架构适合于什么业务场景?

任何脱离业务的架构设计都是耍流氓。

当每个机房都有很多全局业务数据的访问场景时，上述多机房架构并不适用，会存在大量数据不一致。但当每个机房都访问局部业务数据时，上述多机房架构仍然是可行的。

典型的业务：滴滴，快狗打车。

这些业务具备数据聚集效应：

• 下单用户在同一个城市;
• 接单司机在同一个城市;
• 交易订单在同一个城市;

这类业务非常适合上述多机房多活架构，多个机房之间即使存在1分钟延时的“异步数据同步”，对业务也不会造成太大的影响。

多机房多活架构，做不到理想状态下的“同机房连接”，有没有折中方案?

如果完全避免跨机房调用的理想状态做不到，就尽量做到“最小化”跨机房调用

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!