數(shù)據(jù)庫(kù)秒級(jí)平滑擴(kuò)容架構(gòu)方案

一、緣起

---

（1）并發(fā)量大，流量大的互聯(lián)網(wǎng)架構(gòu)，一般來(lái)說(shuō)，數(shù)據(jù)庫(kù)上層都有一個(gè)服務(wù)層，服務(wù)層記錄了“業(yè)務(wù)庫(kù)名”與“數(shù)據(jù)庫(kù)實(shí)例”的映射關(guān)系，通過(guò)數(shù)據(jù)庫(kù)連接池向數(shù)據(jù)庫(kù)路由sql語(yǔ)句以執(zhí)行：

如上圖：服務(wù)層配置用戶庫(kù)user對(duì)應(yīng)的數(shù)據(jù)庫(kù)實(shí)例物理位置為ip（其實(shí)是一個(gè)內(nèi)網(wǎng)域名）。

（2）隨著數(shù)據(jù)量的增大，數(shù)據(jù)要進(jìn)行水平切分，分庫(kù)后將數(shù)據(jù)分布到不同的數(shù)據(jù)庫(kù)實(shí)例（甚至物理機(jī)器）上，以達(dá)到降低數(shù)據(jù)量，增強(qiáng)性能的擴(kuò)容目的：

如上圖：用戶庫(kù)user分布在兩個(gè)實(shí)例上，ip0和ip1，服務(wù)層通過(guò)用戶標(biāo)識(shí)uid取模的方式進(jìn)行尋庫(kù)路由，模2余0的訪問ip0上的user庫(kù)，模2余1的訪問ip1上的user庫(kù)。

關(guān)于數(shù)據(jù)庫(kù)水平切分，垂直切分的更多細(xì)節(jié)，詳見《一分鐘掌握數(shù)據(jù)庫(kù)垂直拆分》。

（3）互聯(lián)網(wǎng)架構(gòu)需要保證數(shù)據(jù)庫(kù)高可用，常見的一種方式，使用雙主同步+keepalived+虛ip的方式保證數(shù)據(jù)庫(kù)的可用性：

如上圖：兩個(gè)相互同步的主庫(kù)使用相同的虛ip。

如上圖：當(dāng)主庫(kù)掛掉的時(shí)候，虛ip自動(dòng)漂移到另一個(gè)主庫(kù)，整個(gè)過(guò)程對(duì)調(diào)用方透明，通過(guò)這種方式保證數(shù)據(jù)庫(kù)的高可用。

關(guān)于高可用的更多細(xì)節(jié)，詳見《究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高可用”》。

（4）綜合上文的（2）和（3），線上實(shí)際的架構(gòu)，既有水平切分，又有高可用保證，所以實(shí)際的數(shù)據(jù)庫(kù)架構(gòu)是這樣的： 

提問：如果數(shù)據(jù)量持續(xù)增大，分2個(gè)庫(kù)性能扛不住了，該怎么辦呢？

回答：繼續(xù)水平拆分，拆成更多的庫(kù)，降低單庫(kù)數(shù)據(jù)量，增加庫(kù)主庫(kù)實(shí)例（機(jī)器）數(shù)量，提高性能。

最終問題拋出：分成x個(gè)庫(kù)后，隨著數(shù)據(jù)量的增加，要增加到y(tǒng)個(gè)庫(kù)，數(shù)據(jù)庫(kù)擴(kuò)容的過(guò)程中，能否平滑，持續(xù)對(duì)外提供服務(wù)，保證服務(wù)的可用性，是本文要討論的問題。

二、停服務(wù)方案

---

在討論平滑方案之前，先簡(jiǎn)要說(shuō)明下“x庫(kù)拆y庫(kù)”停服務(wù)的方案：

（1）站點(diǎn)掛一個(gè)公告“為了為廣大用戶提供更好的服務(wù)，本站點(diǎn)/游戲?qū)⒃诮裢?0:00-2:00之間升級(jí)，屆時(shí)將不能登錄，用戶周知”

（2）停服務(wù)

（3）新建y個(gè)庫(kù)，做好高可用

（4）數(shù)據(jù)遷移，重新分布，寫一個(gè)數(shù)據(jù)遷移程序，從x個(gè)庫(kù)里導(dǎo)入到y(tǒng)個(gè)庫(kù)里，路由規(guī)則由%x升級(jí)為%y

（5）修改服務(wù)配置，原來(lái)x行配置升級(jí)為y行

（6）重啟服務(wù)，連接新庫(kù)重新對(duì)外提供服務(wù)

整個(gè)過(guò)程中，最耗時(shí)的是第四步數(shù)據(jù)遷移。

回滾方案：

如果數(shù)據(jù)遷移失敗，或者遷移后測(cè)試失敗，則將配置改回x庫(kù)，恢復(fù)服務(wù)，改天再掛公告。

方案優(yōu)點(diǎn)：簡(jiǎn)單

方案缺點(diǎn)：

（1）停服務(wù)，不高可用

（2）技術(shù)同學(xué)壓力大，所有工作要在規(guī)定時(shí)間內(nèi)做完，根據(jù)經(jīng)驗(yàn)，壓力越大約容易出錯(cuò)（這一點(diǎn)很致命）

（3）如果有問題第一時(shí)間沒檢查出來(lái)，啟動(dòng)了服務(wù)，運(yùn)行一段時(shí)間后再發(fā)現(xiàn)有問題，難以回滾，需要回檔，可能會(huì)丟失一部分?jǐn)?shù)據(jù)

有沒有更平滑的方案呢？

三、秒級(jí)、平滑、帥氣方案

---

再次看一眼擴(kuò)容前的架構(gòu)，分兩個(gè)庫(kù)，假設(shè)每個(gè)庫(kù)1億數(shù)據(jù)量，如何平滑擴(kuò)容，增加實(shí)例數(shù)，降低單庫(kù)數(shù)據(jù)量呢？三個(gè)簡(jiǎn)單步驟搞定。

（1）修改配置

主要修改兩處：

a）數(shù)據(jù)庫(kù)實(shí)例所在的機(jī)器做雙虛ip，原來(lái)%2=0的庫(kù)是虛ip0，現(xiàn)在增加一個(gè)虛ip00，%2=1的另一個(gè)庫(kù)同理

b）修改服務(wù)的配置（不管是在配置文件里，還是在配置中心），將2個(gè)庫(kù)的數(shù)據(jù)庫(kù)配置，改為4個(gè)庫(kù)的數(shù)據(jù)庫(kù)配置，修改的時(shí)候要注意舊庫(kù)與辛苦的映射關(guān)系：

%2=0的庫(kù)，會(huì)變?yōu)?4=0與%4=2；

%2=1的部分，會(huì)變?yōu)?4=1與%4=3；

這樣修改是為了保證，拆分后依然能夠路由到正確的數(shù)據(jù)。

（2）reload配置，實(shí)例擴(kuò)容

服務(wù)層reload配置，reload可能是這么幾種方式：

a）比較原始的，重啟服務(wù)，讀新的配置文件

b）高級(jí)一點(diǎn)的，配置中心給服務(wù)發(fā)信號(hào)，重讀配置文件，重新初始化數(shù)據(jù)庫(kù)連接池

不管哪種方式，reload之后，數(shù)據(jù)庫(kù)的實(shí)例擴(kuò)容就完成了，原來(lái)是2個(gè)數(shù)據(jù)庫(kù)實(shí)例提供服務(wù)，現(xiàn)在變?yōu)?個(gè)數(shù)據(jù)庫(kù)實(shí)例提供服務(wù)，這個(gè)過(guò)程一般可以在秒級(jí)完成。

整個(gè)過(guò)程可以逐步重啟，對(duì)服務(wù)的正確性和可用性完全沒有影響：

a）即使%2尋庫(kù)和%4尋庫(kù)同時(shí)存在，也不影響數(shù)據(jù)的正確性，因?yàn)榇藭r(shí)仍然是雙主數(shù)據(jù)同步的

b）服務(wù)reload之前是不對(duì)外提供服務(wù)的，冗余的服務(wù)能夠保證高可用

完成了實(shí)例的擴(kuò)展，會(huì)發(fā)現(xiàn)每個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)量依然沒有下降，所以第三個(gè)步驟還要做一些收尾工作。

（3）收尾工作，數(shù)據(jù)收縮

有這些一些收尾工作：

a）把雙虛ip修改回單虛ip

b）解除舊的雙主同步，讓成對(duì)庫(kù)的數(shù)據(jù)不再同步增加

c）增加新的雙主同步，保證高可用

d）刪除掉冗余數(shù)據(jù)，例如：ip0里%4=2的數(shù)據(jù)全部干掉，只為%4=0的數(shù)據(jù)提供服務(wù)啦

這樣下來(lái)，每個(gè)庫(kù)的數(shù)據(jù)量就降為原來(lái)的一半，數(shù)據(jù)收縮完成。

四、總結(jié)

---

該帥氣方案能夠?qū)崿F(xiàn)n庫(kù)擴(kuò)2n庫(kù)的秒級(jí)、平滑擴(kuò)容，增加數(shù)據(jù)庫(kù)服務(wù)能力，降低單庫(kù)一半的數(shù)據(jù)量，其核心原理是：成倍擴(kuò)容，避免數(shù)據(jù)遷移。

遷移步驟：

（1）修改配置

（2）reload配置，實(shí)例擴(kuò)容完成

（3）刪除冗余數(shù)據(jù)等收尾工作，數(shù)據(jù)量收縮完成