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

?Labs 導讀

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

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

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

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

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

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

圖一 同城備份

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

圖二 同城同步

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

Part 03  異地多活的新問題

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

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

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

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

圖三 異地雙活

Part 04  異地同步數據

到這里，我們已經發現了，多個機房間的數據一定是需要同步的，這是異地多機房的必由之路。

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

圖四 網狀同步

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

圖五 網狀星狀同步

Part 05  分布式數據庫，是銀彈嗎？

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

通過分布式數據庫，既可以實現數據的橫向拓展，也可以減少業務上數據同步的復雜性，幾乎可以說是一舉多得。

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

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

圖六 分布書數據庫多機房

Part 06  總結

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