多机房部署意味着在不同的 IDC（Internet Data Center）机房中设置多个服务实例，这些服务共享同一份业务数据，并且都可以处理用户的请求流量。这种架构旨在提高系统的高可用性和灾备能力，以应对单一机房或地区发生的网络故障、自然灾害等意外情况。

一个思路是直接跨机房读取 A 机房的从库：

图片

另一个思路是在机房 B 部署一个从库，跨机房同步主库的数据，然后机房 B 的应用就可以读取这个从库的数据了：

图片

涉及跨机房的数据传输时，对机房之间的延迟有较高的要求，这取决于机房之间的距离。一些基本的延迟数字如下：

城市内跨机房： 通常在几毫秒（ms）到数十毫秒（ms）之间，取决于城市规模和网络基础设施。

地区间跨机房： 跨越不同城市或地区的机房间的延迟通常在几十毫秒（ms）到数百毫秒（ms）之间，具体取决于地理距离和网络连接质量。

国际跨机房： 跨越国家或大洲的机房间的延迟通常在数百毫秒（ms）到数秒之间，受到地球的物理距离和国际网络连接的影响。

逐步迭代多机房部署方案

1. 同城双活

数据库部署： 主数据库部署在一个机房中（如A机房），而A、B两个机房都设置一个从数据库，通过主从复制同步数据。这样可以实现双机房的数据一致性，并且降低跨机房调用的需求。

缓存部署： 在两个机房都部署缓存，查询请求优先读取本地缓存，如果缓存不存在则穿透到本地从数据库中加载数据。这样可以减少对主数据库的直接查询，提高数据访问速度。

RPC服务注册与调用： 不同机房的RPC服务向不同的注册中心注册服务组，并且RPC客户端（如Web服务）只订阅同机房的RPC服务组。这样可以最大程度地保证RPC调用发生在本机房内，避免跨机房调用。

其他依赖服务： 确保其他依赖服务（如审核、搜索等）也采用双机房部署，并尽量保证只调用本机房的服务，降低调用延迟。

容灾处理： 如果某个机房发生故障，可以通过主从切换的方式将另一个机房的从数据库提升为主数据库，以达到容灾的目的。同时，RPC服务和其他依赖服务也可以在另一个机房中继续提供服务，保证系统的可用性。

2. 异地多活

异地机房部署位置： 异地机房应选择与主机房距离较远的位置，例如上海、广州等城市，以降低自然灾害对系统可用性的影响。

数据同步方案： 采用两种同步相结合的方式，即基于存储系统的主从复制和基于消息队列的方式。主库部署在主机房，从库部署在异地机房，并通过主从复制实现数据同步。同时，对于缓存数据、HBase等，采用基于消息队列的方式进行同步。

数据读取优化： 为了减少跨机房数据传输的延迟，对用户进行分片，使一个用户的读写操作尽量在同一个机房中进行。同时，在服务调用和数据读取时，优先选择本机房的服务和数据，确保服务调用尽量在本机房内完成。

服务调用优先级： 对于一些需要跨机房读取数据的场景，如用户查看订单信息，优先保证服务调用和数据读取在本机房中进行，即使读取的是跨机房从库的数据，也可以接受一定的延迟。

图片

总结：

允许有跨机房数据写入的发生，但强调数据的读取和服务的调用应尽量在同一个机房中进行，以确保最低的延迟。这种方案适用于同城多机房的延迟在1ms~3ms范围内的情况，且相对简单易行。

避免跨机房同步的数据写入和读取，采取异步的方式将数据从一个机房同步到另一个机房。这种方案适用于异地机房的延迟在50ms以下的情况，要求跨机房数据同步的延迟较低。

多机房部署是一个在业务发展到一定规模、对机房容灾有需求时才考虑的方案，需要谨慎权衡利弊。在可以避免的情况下尽量不要进行多机房部署，因为这会增加系统的复杂性和维护成本。

异地多活架构在实现时过于复杂，很少有公司能够搭建一套真正的异步多活架构。因此，在没有足够的技术实力和资源支持的情况下，不建议轻易尝试异地多活架构。