在業務初期，為了控制投入成本，許多公司通常只使用一個機房提供服務。但隨著業務的發展和流量的增長，對服務響應速度和可用性的要求逐漸提高，這時就需要考慮在不同地區部署服務，以提供更好的用戶體驗。這也是互聯網公司在流量增長階段的必經之路。

我之前所在的公司連續三年流量不斷增長。有一次，機房的對外網絡突然斷開，導致線上服務全面離線，網絡供應商也無法聯系上。由于沒有備用機房，我們花了三天時間緊急協調，重新拉線路才恢復服務。這次事故造成的影響非常大，公司損失達千萬元。吸取了這次教訓后，我們將服務遷移到了更大型的機房，并決定在同一城市建設雙機房，以提高服務的可用性。這樣，當一個機房出現故障時，用戶可以通過 HttpDNS 接口快速切換到另一個正常的機房。

為了確保在一個機房故障時，另一個機房能夠直接接管流量，我們對兩個機房的設備進行了 1:1 的采購。但如果讓其中一個機房長時間處于冷備狀態會造成資源浪費，因此我們希望兩個機房能同時對外提供服務，也就是實現同城雙活。不過，雙活方案的一個關鍵問題是如何實現雙機房之間的數據庫同步。

核心數據中心設計

由于數據庫使用的是主從架構，因此全網只能有一個主庫來進行數據更新。我們只能在一個機房部署主庫，然后由這個機房將數據同步到其他備份機房。雖然兩個機房之間有專線連接，但網絡的完全穩定性無法保證。如果網絡出現故障，我們需要確保機房之間在網絡恢復后能夠快速恢復數據同步。

有人可能會認為直接采用分布式數據庫可以解決這個問題。然而，改變現有的服務體系并全面遷移到分布式數據庫不僅需要相當長的時間，成本也非常高昂，對大多數公司來說并不實際。因此，我們需要考慮如何改造現有系統，實現同城雙活機房的數據庫同步。這也正是我們的目標

核心數據庫中心方案是常見的實現方式，這種方案只適合相距不超過 50 公里的機房。

圖片

在這個方案中，主庫集中部署在一個核心機房，其余機房中的數據庫則作為從庫。當有數據修改請求時，核心機房的主庫會首先完成修改，然后通過主從同步將更新的數據傳輸到其他備份機房的從庫。

由于用戶通常是從緩存中獲取信息，為了降低主從同步的延遲，備份機房會將更新后的數據直接寫入本地緩存。同時，客戶端會在本地記錄下數據修改的最后時間戳（若沒有，則記錄當前時間）。當客戶端向服務端發起請求時，服務端會自動對比緩存中該數據的更新時間與客戶端本地的修改時間。如果緩存中的更新時間早于客戶端記錄的時間，服務端會觸發同步操作，嘗試在從庫中查找最新數據；若從庫中沒有最新數據，則從主庫中獲取最新數據并更新到該機房的緩存中。

通過這種方式，可以有效避免機房之間的數據更新延遲問題，從而確保用戶能更及時地獲取到最新的數據。

圖片

此外，客戶端還會通過請求調度接口，使用戶在短時間內只訪問同一個機房，避免用戶在多個機房之間來回切換時，因數據在不同機房同時修改而產生更新合并沖突。總體來看，這種方案設計相對簡單，但也存在一些明顯的缺點。

例如，如果核心機房發生故障，其他機房將無法執行數據更新。故障期間，需要人工切換各個代理（proxy）的主從庫配置才能恢復服務，故障恢復后也需要手動介入以恢復主從同步。此外，由于主從同步存在一定的延遲，剛更新的數據在備用機房中會有短暫的不可見時間，這種延遲會導致業務邏輯中需要人工處理這種情況，整體操作較為繁瑣，增加了實現的復雜性。

這里我給你一個常見的網絡延遲參考：

同機房服務器：0.1 ms同城服務器（100 公里以內） ：1ms（10 倍 同機房）北京到上海：38ms（380 倍 同機房）北京到廣州：53ms（530 倍 同機房）

需要注意的是，上述設計只是一次 RTT 請求，而機房間的同步涉及多次順序疊加的請求操作。如果要大規模更新數據，主從庫的同步延遲將更為顯著。因此，這種雙活機房方案的數據量不能過大，且業務更新數據的頻率也不能太高。另外，如果服務對強一致性有要求，即所有操作都必須在主庫“遠程執行”，這也會加大主從同步的延遲。

除了以上問題，雙機房之間的專線偶爾也會出現故障。我曾遇到過一次專線斷開持續了兩小時，期間只能臨時通過公網來保持同步，但公網同步不穩定，延遲在 10ms～500ms 之間波動，導致主從延遲超過 1 分鐘。幸運的是，由于用戶中心服務主要依賴長期緩存的數據，業務主要流程沒有受到太大影響，只是用戶修改信息的速度變得很慢。

雙機房同步還可能偶發主從同步中斷的情況，因此建議設置告警處理機制。一旦出現此情況，應立即向故障警報群發送通知，由 DBA 人員進行人工修復。此外，我還遇到過在主從不同步期間，用戶注冊時自增 ID 出現重復，導致主鍵沖突。為此，我建議將自增 ID 替換為基于 SnowFlake 算法生成的 ID，以減少主鍵沖突的風險。

總的來說，盡管這種核心數據庫的中心化方案實現了同城雙活，但人力投入成本非常高。DBA 需要手動維護同步，一旦主從同步中斷，恢復起來相當耗時耗力，且研發人員也需要時刻關注主從不同步的情況。因此，我推薦使用另一種方案：數據庫同步工具 Otter。

跨機房同步神器：Otter

Otter 是阿里開發的數據庫同步工具，它可以快速實現跨機房、跨城市、跨國家的數據同步。如下圖所示，其核心實現是通過 Canal 監控主庫 MySQL 的 Row binlog，將數據更新并行同步給其他機房的 MySQL。

圖片

因為我們要實現同城雙機房雙活，所以這里我們用 Otter 來實現同城雙主（注意：雙主不通用，不推薦一致要求高的業務使用），這樣雙活機房可以雙向同步：

圖片

如上圖所示，每個機房內都有自己的主庫和從庫，緩存可以跨機房主從同步，也可以是本地的主從同步，這取決于具體的業務需求。Otter 使用 Canal 將機房內主庫的數據變更同步到 Otter Node 中，然后通過 Otter 的 SETL（Select, Extract, Transform, Load）機制整理后，再將數據同步到對方機房的 Node 節點，從而實現雙機房之間的數據同步。

在這里需要提到 Otter 處理數據沖突的方式，以解決雙機房同時修改同一條數據的問題。Otter 中的數據沖突分為兩類：行沖突和字段沖突。行沖突可以通過對比數據的修改時間來解決，或者在發生沖突時進行回源查詢來覆蓋目標庫。而對于字段沖突，可以根據修改時間覆蓋，也可以合并多個修改操作。例如，如果 a 機房和 b 機房分別對某字段進行了 -1 的操作，合并后該字段的最終修改值為 -2，以此實現數據的最終一致性。

但需要注意的是，這種合并策略并不適用于庫存類的數據管理，因為可能會導致超賣現象。如果有類似的需求，建議使用長期緩存來處理，以避免并發修改導致的數據不一致問題。

總結

機房之間的數據同步一直是行業中的難題，由于其高昂的實現成本，如果無法實現雙活，那么必然會有一個機房以 1:1 的機器數量在空跑。并且在發生故障時，也無法保證冷備機房能夠立即對外提供服務。然而，雙活模式的維護成本也不低，機房之間的數據同步經常會因網絡延遲或數據沖突而中斷，最終導致兩個機房數據不一致。

好在 Otter 在數據同步方面采取了多種措施，能夠在大多數情況下保證數據的完整性，并降低同城雙活的實現難度。即便如此，在業務運轉中，我們仍需人工梳理業務流程，以盡量避免多個機房同時修改同一條數據。為此，我們可以通過 HttpDNS 調度，讓用戶在一段時間內只在一個機房內活躍，減少數據沖突的可能性。對于頻繁修改、資源爭搶較高的服務，通常在機房本地執行完整事務操作，避免跨機房同時修改帶來的同步錯誤。