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

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

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

核心數(shù)據(jù)中心設(shè)計

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

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

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

圖片

在這個方案中，主庫集中部署在一個核心機房，其余機房中的數(shù)據(jù)庫則作為從庫。當有數(shù)據(jù)修改請求時，核心機房的主庫會首先完成修改，然后通過主從同步將更新的數(shù)據(jù)傳輸?shù)狡渌麄浞輽C房的從庫。

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

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

圖片

此外，客戶端還會通過請求調(diào)度接口，使用戶在短時間內(nèi)只訪問同一個機房，避免用戶在多個機房之間來回切換時，因數(shù)據(jù)在不同機房同時修改而產(chǎn)生更新合并沖突?？傮w來看，這種方案設(shè)計相對簡單，但也存在一些明顯的缺點。

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

這里我給你一個常見的網(wǎng)絡延遲參考：

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

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

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

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

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

跨機房同步神器：Otter

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

圖片

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

圖片

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

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

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

總結(jié)

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

好在 Otter 在數(shù)據(jù)同步方面采取了多種措施，能夠在大多數(shù)情況下保證數(shù)據(jù)的完整性，并降低同城雙活的實現(xiàn)難度。即便如此，在業(yè)務運轉(zhuǎn)中，我們?nèi)孕枞斯な崂順I(yè)務流程，以盡量避免多個機房同時修改同一條數(shù)據(jù)。為此，我們可以通過 HttpDNS 調(diào)度，讓用戶在一段時間內(nèi)只在一個機房內(nèi)活躍，減少數(shù)據(jù)沖突的可能性。對于頻繁修改、資源爭搶較高的服務，通常在機房本地執(zhí)行完整事務操作，避免跨機房同時修改帶來的同步錯誤。