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

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

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

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

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

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

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

圖片

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

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

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

圖片

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

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

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

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

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

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

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

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

跨機(jī)房同步神器：Otter

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

圖片

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

圖片

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

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

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

總結(jié)

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

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