上一篇關于DynamoDB的介紹中，有一個特別亮點，就是它無需停機就可以動態(tài)擴容。

這個對于我們常用的分庫分表方案來說，有很大的優(yōu)勢，分庫分表的擴容是一件頭疼的問題，如果采用對db層做一致性hash，或是中間價的支持，它的成本過于高昂了，如果不如此，只能停機維護來處理，對高可用性會產(chǎn)生影響。

那是否有方案，既可以快速擴展，又不降低可用性？這一篇，我們聊聊分庫分表的擴展方案，供大家一起探討。

一、水平分庫擴展問題

為了增加db的并發(fā)能力，常見的方案就是對數(shù)據(jù)進行sharding，也就是常說的分庫分表，這個需要在初期對數(shù)據(jù)規(guī)劃有一個預期，從而預先分配出足夠的庫來處理。

比如目前規(guī)劃了3個數(shù)據(jù)庫，基于uid進行取余分片，那么每個庫上的劃分規(guī)則如下:

如上我們可以看到，數(shù)據(jù)可以均衡的分配到3個數(shù)據(jù)庫里面。

但是，如果后續(xù)業(yè)務發(fā)展的速度很快，用戶量數(shù)據(jù)大量上升，當前容量不足以支撐，應該怎么辦？

需要對數(shù)據(jù)庫進行水平擴容，再增加新庫來分解。新庫加入之后，原先sharding到3個庫的數(shù)據(jù)，就可以sharding到四個庫里面了

不過此時由于分片規(guī)則進行了變化(uid%3 變?yōu)閡id%4)，大部分的數(shù)據(jù)，無法***在原有的數(shù)據(jù)庫上了，需要重新分配，大量數(shù)據(jù)需要遷移。

比如之前uid1通過uid1%3 分配在A庫上，新加入庫D之后，算法改為uid1%4 了，此時有可能就分配在B庫上面了。

如果你有看到之前《一致性哈希的原理與實踐》，就會發(fā)現(xiàn)新增一個節(jié)點，大概會有90%的數(shù)據(jù)需要遷移，這個對DB同學的壓力還是蠻大的，那么如何應對？

一般有以下幾種方式。

二、停服遷移

停服遷移是最常見的一種方案了，一般如下流程:

1. 預估停服時間，發(fā)布停服公告
2. 停服，通過事先做好的數(shù)據(jù)遷移工具，按照新的分片規(guī)則，進行遷移
3. 修改分片規(guī)則
4. 啟動服務

我們看到這種方式比較安全，停服之后沒有數(shù)據(jù)寫入，能夠保證遷移工作的正常進行，沒有一致性的問題。唯一的問題，就是停服了和時間壓力了。

1. 停服，傷害用戶體驗，同時也降低了服務器的可用性
2. 必須在制定時間內(nèi)完成遷移，如果失敗，需要擇日再次進行。同時增加了開發(fā)人員的壓力，容易發(fā)生大的事故
3. 數(shù)據(jù)量的巨大的時候，遷移需要大量時間

那有沒有其他方式來改進一下，我們看下以下兩種方案。

三、升級從庫

線上數(shù)據(jù)庫，我們?yōu)榱吮３制涓呖捎?，一般都會每臺主庫配一臺從庫，讀寫在主庫，然后主從同步到從庫。如下，A，B是主庫，A0和B0是從庫。

此時，當需要擴容的時候，我們把A0和B0升級為新的主庫節(jié)點，如此由2個分庫變?yōu)?個分庫。同時在上層的分片配置，做好映射，規(guī)則如下:

uid%4=0和uid%4=2的分別指向A和A0，也就是之前指向uid%2=0的數(shù)據(jù)，分裂為uid%4=0和uid%4=2

uid%4=1和uid%4=3的指向B和B0，也就是之前指向uid%2=1的數(shù)據(jù)，分裂為uid%4=1和uid%4=3

因為A和A0庫的數(shù)據(jù)相同，B和B0數(shù)據(jù)相同，所以此時無需做數(shù)據(jù)遷移即可。只需要變更一下分片配置即可，通過配置中心更新，無需重啟。

由于之前uid%2的數(shù)據(jù)分配在2個庫里面，此時分散到4個庫中，由于老數(shù)據(jù)還存在（uid%4=0,還有一半uid%4=2的數(shù)據(jù)），所以需要對冗余數(shù)據(jù)做一次清理。

而這個清理，不會影響線上數(shù)據(jù)的一致性，可是隨時隨地進行。

處理完成以后，為保證高可用，以及下一步擴容需求?？梢詾楝F(xiàn)有的主庫再次分配一個從庫。

總結一下此方案步驟如下：

1. 修改分片配置，做好新庫和老庫的映射。
2. 同步配置，從庫升級為主庫
3. 解除主從關系
4. 冗余數(shù)據(jù)清理
5. 為新的數(shù)據(jù)節(jié)點搭建新的從庫

四、雙寫遷移

雙寫的方案，更多的是針對線上數(shù)據(jù)庫遷移來用的，當然了，對于分庫的擴展來說也是要遷移數(shù)據(jù)的，因此，也可以來協(xié)助分庫擴容的問題。

原理和上述相同，做分裂擴容，只是數(shù)據(jù)的同步方式不同了。

1.增加新庫寫鏈接

雙寫的核心原理，就是對需要擴容的數(shù)據(jù)庫上，增加新庫，并對現(xiàn)有的分片上增加寫鏈接，同時寫兩份數(shù)據(jù)。

因為新庫的數(shù)據(jù)為空，所以數(shù)據(jù)的CRUD對其沒有影響，在上層的邏輯層，還是以老庫的數(shù)據(jù)為主。

2.新老庫數(shù)據(jù)遷移

通過工具，把老庫的數(shù)據(jù)遷移到新庫里面，此時可以選擇同步分裂后的數(shù)據(jù)（1/2）來同步，也可以全同步，一般建議全同步，最終做數(shù)據(jù)校檢的時候好處理。

3.數(shù)據(jù)校檢

按照理想環(huán)境情況下，數(shù)據(jù)遷移之后，因為是雙寫操作，所以兩邊的數(shù)據(jù)是一致的，特別是insert和update，一致性情況很高。但真實環(huán)境中會有網(wǎng)絡延遲等情況，對于delete情況并不是很理想，比如：

A庫刪除數(shù)據(jù)a的時候，數(shù)據(jù)a正在遷移，還沒有寫入到C庫中，此時C庫的刪除操作已經(jīng)執(zhí)行了，C庫會多出一條數(shù)據(jù)。

此時就需要做好數(shù)據(jù)校檢了，數(shù)據(jù)校檢可以多做幾遍，直到數(shù)據(jù)幾乎一致，盡量以舊庫的數(shù)據(jù)為準。

4.分片配置修改

數(shù)據(jù)同步完畢，就可以把新庫的分片映射重新處理了，還是按照老庫分裂的方式來進行，

u之前uid%2=0,變?yōu)閡id%4=0和uid%4=2的

uid%2=1，變?yōu)閡id%4=1和uid%4=3的。

參考: 

《數(shù)據(jù)庫秒級平滑擴容架構方案》