爲什麼要有雙機房？
可能有幾個考慮：
-
容災：強如阿里雲、微信、唯品會等，依然避免不了機房故障問題。一次這個級別的故障，就會有一個技術頭頭下野。
-
更快的響應：網絡時延和物理距離成正比，用戶距離服務越近，時延越友好 。不同的地域，多機房多活模式，就近提供服務。
一、雙機房需要做什麼？
1、一套完備的服務
完備的服務包括哪些？
應用服務實例，緩存服務實例、數據庫服務實例、mq 服務實例等。
服務實例數量可以根據實際需要確定，不必要求安全對等，但是比例不能亂。
2、數據同步
數據的同步是至關重要的。數據是業務邏輯的承載和服務狀態的基礎。
數據同步強調準確性和實時性。 兩個機房的數據根據不同的活性模式，數據域可能略有差異，但是相同的數據域必須要保障一致性。
3、服務就近調用
這裏說的服務調用是指內部服務之間的訪問需求，就近是指訪問限定在機房域內，儘量避免跨機房調用。
服務調用主要分如下幾個點：
a）Http 方式
http 方式簡潔，易用，是服務間交互的常用方式，通常使用內部域名（避免直接ip訪問）訪問。
雙機房建設，則需要做好相應的適配。
b）rpc 方式
rpc 方式則更側重擴展性，可靠性，高效性等。通常有相應的服務框架及管理框架支持。
rpc 服務提供者和使用者通過服務註冊中心進行服務註冊發現交互。
雙機房註冊及發現，需要有相應的【就近策略】支持。
c）mq 方式
mq 異步交互模式。
業務消息限制發送到同一機房，並由同一機房服務進行消費。
二、雙機房的兩種模式
1、災備
災備模式，即機房服務作爲備用，不參與對外服務。一旦主機房發生故障，快速切換響應。
這種建設模式因爲變更來源全部爲主機房單向數據同步，所以比較容易實現。
災備模式需要做什麼？
災備模式數據同步實時性要求沒有那麼高。更強調數據的最終一致性。
備機房服務節點可以直接作爲備節點模式進行數據的同步。
2、雙活
雙活模式，即兩個機房同時對外提供服務，同時對底層數據產生變更操作。
這種涉及的邏輯比較複雜，要求也相對較高，強要求數據同步實時性。
雙活模式需要做什麼？
a）用戶切割
所謂用戶切割即，劃分兩個機房服務不同的用戶羣體。儘量使得同一個用戶的數據變更都發生在同一個機房。
切割通常可以從網關層面進行流量調度。
調度策略可以基於用戶屬性層面考量，比如：地域、ID特性等。
b）數據雙向同步
數據雙向同步，聽着就麻煩，所以必須有 a）中的用戶切割作爲基礎。
對於可能產生的同一數據的雙相同步場景（數據衝突等），處理尤要慎重（基於時間戳、外部驗證等前置驗證方式）。