作者 | 郭冠華，單位：中國移動(dòng)智慧家庭運(yùn)營中心

?Labs 導(dǎo)讀

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

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

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

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

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

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

圖一 同城備份

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

圖二 同城同步

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

Part 03  異地多活的新問題

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

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

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

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

圖三 異地雙活

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

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

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

圖四 網(wǎng)狀同步

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

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

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

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

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

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

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

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

Part 06  總結(jié)

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