多機房部署意味著在不同的 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以下的情況，要求跨機房數據同步的延遲較低。

多機房部署是一個在業務發展到一定規模、對機房容災有需求時才考慮的方案，需要謹慎權衡利弊。在可以避免的情況下盡量不要進行多機房部署，因為這會增加系統的復雜性和維護成本。

異地多活架構在實現時過于復雜，很少有公司能夠搭建一套真正的異步多活架構。因此，在沒有足夠的技術實力和資源支持的情況下，不建議輕易嘗試異地多活架構。