作者 | 郭冠華，單位：中國移動智慧家庭運營中心

?Labs 導(dǎo)讀

服務(wù)的可用性就是網(wǎng)絡(luò)的平均無故障率。對于一個平臺來講，這是非常重要的指標之一。當(dāng)前主要使用的可用率為4個9，即99.99%。也意味著每年最多只能有52分鐘的故障時間。

Part 01  雙活、多活解決的問題

雖然通過負載均衡等方式，可以應(yīng)對單節(jié)點故障。但當(dāng)出現(xiàn)小概率不可抗力的時候（自然災(zāi)害、停電、挖斷光纜等情況），整個機房不可用的情況依然會出現(xiàn)。近年來，支付寶、微博、B站等均出現(xiàn)過機房級的故障，因此一個或者多個便于快速切換的機房就成了backup（備用）。同時，多活的一個次要條件就是可以部署在不同的位置，通過物理上的距離減少，來提升響應(yīng)速度。分機房部署也可以大大地減少單機房資源的需求。

Part 02  同城備份還是同城雙活？

同城進行部署服務(wù)的最大好處就是機房空間距離小，通過專線進行連接，機房間時延可以穩(wěn)定到3ms以內(nèi)，因此服務(wù)可以跨機房訪問數(shù)據(jù)。

于是，最簡單的雙活方式如下：我們可以稱之為同城備份，數(shù)據(jù)庫放在機房A，并定期將數(shù)據(jù)庫內(nèi)數(shù)據(jù)同步至機房B。好處是實現(xiàn)簡單、方便橫向的服務(wù)拓展。如果發(fā)生機房級別的災(zāi)害，可以盡快從機房B將數(shù)據(jù)恢復(fù)。但是問題也出在這里：機房B并沒有數(shù)據(jù)庫，無法完全接替機房A的作用。

圖一 同城備份

為了解決上述的問題，可以在機房B內(nèi)放置數(shù)據(jù)庫從庫，并將機房A的數(shù)據(jù)實時同步到機房B：即A機房中的數(shù)據(jù)庫為主庫，機房B中為從庫。若發(fā)生機房A故障，則可以將流量切到B機房，并停止實時同步，把機房B中的數(shù)據(jù)庫置為主庫。

圖二 同城同步

該機房的主要問題是需要人工干預(yù)較多。除了數(shù)據(jù)庫和DNS的切換之外，還需要修改大量數(shù)據(jù)庫的配置?？傮w上，該架構(gòu)可以以較快時間恢復(fù)服務(wù)，對于同城的多機房，已經(jīng)足夠。

Part 03  異地多活的新問題

異地多活不同于同城的情況，首先就是機房間哪怕使用專線，延時的問題也無法解決（想要異地訪問數(shù)據(jù)庫幾乎不可能）。

首先我們想到的是，有沒有一種方法可以盡量避免信息的同步？那就是下圖的方式：通過地理、用戶哈希、設(shè)備id哈希等方式，將請求在DNS層分流到多個機房。每個機房處理固定用戶請求，從而可以將兩個機房間數(shù)據(jù)同步減少到最少，也將每個機房的數(shù)據(jù)量減少到最少的量。但是數(shù)據(jù)同步只能靠業(yè)務(wù)進行同步，而不是數(shù)據(jù)庫工具進行同步。

分治的方式看起來很理想，但實際上也會有其他的問題。比如，使用地理方式進行劃分（即使用ip進行劃分）的方案，用戶位置發(fā)生變化導(dǎo)致請求到其他機房，如何進行數(shù)據(jù)同步？使用用戶id哈希進行分片的方案，需要進行橫向擴容時，舊數(shù)據(jù)如何處理？發(fā)生故障時，其他機房如何短時間內(nèi)同步其他分片數(shù)據(jù)等等。

總之，分片方式并非是完美的解決方法。

圖三 異地雙活

Part 04  異地同步數(shù)據(jù)

到這里，我們已經(jīng)發(fā)現(xiàn)了，多個機房間的數(shù)據(jù)一定是需要同步的，這是異地多機房的必由之路。

數(shù)據(jù)的同步方式可以通過業(yè)務(wù)方式，也可以通過數(shù)據(jù)庫中間件進行。下圖中的方式就是機房間進行同步，這種方式確實增大了業(yè)務(wù)的復(fù)雜性，并且會隨著機房的拓展，機房間同步的情況會更加復(fù)雜。

圖四 網(wǎng)狀同步

在上述的架構(gòu)中，如果設(shè)置一個中心的數(shù)據(jù)節(jié)點，所有機房通過中心數(shù)據(jù)節(jié)點來進行同步，數(shù)據(jù)流就會從“網(wǎng)狀”變成“星狀”。大大減少同步工作和復(fù)雜性。但是這一方案，實質(zhì)上是與我們追求的分布式部署理念的一種背離。

圖五 網(wǎng)狀星狀同步

Part 05  分布式數(shù)據(jù)庫，是銀彈嗎？

不僅是在多機房部署的情況下，隨著數(shù)據(jù)量的急劇增大，針對Mysql的分庫分表，開發(fā)人員對JDBC Proxy還有DB Proxy進行了深入的實戰(zhàn)。大家越來越發(fā)現(xiàn)，承認數(shù)據(jù)庫分片是很有必要的。在該基礎(chǔ)上，許多分布式數(shù)據(jù)庫如cockroach、TiDB隨之產(chǎn)生。分布式數(shù)據(jù)庫天生支持多集群、多機房的部署，這與異地多活的需求不謀而合。

通過分布式數(shù)據(jù)庫，既可以實現(xiàn)數(shù)據(jù)的橫向拓展，也可以減少業(yè)務(wù)上數(shù)據(jù)同步的復(fù)雜性，幾乎可以說是一舉多得。

此外，數(shù)據(jù)庫對于資源的需求也很高，一個三集群的TiDB，至少需要9臺物理機，10個萬兆網(wǎng)卡以及之間的3條專線。

另外的缺點是改架構(gòu)對于分布式數(shù)據(jù)庫集群間的延時，相對苛刻，這也阻礙了改架構(gòu)在較廣域的地區(qū)無限擴容。

圖六 分布書數(shù)據(jù)庫多機房

Part 06  總結(jié)

多機房部署相對于單個機房，其難度、開發(fā)、資源開銷都是級數(shù)上升。因此具體的架構(gòu)需要根據(jù)實際需求來選擇。本文旨在介紹多機房部署的幾種類型，開拓大家的思路。實際的多機房部署形式可能也與上述的都不一樣，但是思路大體是相同的。?