水平分庫如何做到平滑擴充套件

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

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

為了增加db的併發能力，常見的方案就是對資料進行sharding，也就是常說的分庫分表，這個需要在初期對資料規劃有乙個預期，從而預先分配出足夠的庫來處理。

比如目前規劃了3個資料庫，基於uid進行取餘分片，那麼每個庫上的劃分規則如下:

如上我們可以看到，資料可以均衡的分配到3個資料庫裡面。

但是，如果後續業務發展的速度很快，使用者量資料大量上公升，當前容量不足以支撐，應該怎麼辦？

需要對資料庫進行水平擴容，再增加新庫來分解。新庫加入之後，原先sharding到3個庫的資料，就可以sharding到四個庫裡面了

不過此時由於分片規則進行了變化(uid%3 變為uid%4)，大部分的資料，無法命中在原有的資料庫上了，需要重新分配，大量資料需要遷移。

一般有以下幾種方式。

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

預估停服時間，發布停服公告

停服，通過事先做好的資料遷移工具，按照新的分片規則，進行遷移

修改分片規則

啟動服務

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

停服，傷害使用者體驗，同時也降低了伺服器的可用性

必須在制定時間內完成遷移，如果失敗，需要擇日再次進行。同時增加了開發人員的壓力，容易發生大的事故

資料量的巨大的時候，遷移需要大量時間

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

線上資料庫，我們為了保持其高可用，一般都會每台主庫配一台從庫，讀寫在主庫，然後主從同步到從庫。如下，a，b是主庫，a0和b0是從庫。

此時，當需要擴容的時候，我們把a0和b0公升級為新的主庫節點，如此由2個分庫變為4個分庫。同時在上層的分片配置，做好對映，規則如下:

uid%4=0和uid%4=2的分別指向a和a0，也就是之前指向uid%2=0的資料，**為uid%4=0和uid%4=2

uid%4=1和uid%4=3的指向b和b0，也就是之前指向uid%2=1的資料，**為uid%4=1和uid%4=3

因為a和a0庫的資料相同，b和b0資料相同，所以此時無需做資料遷移即可。只需要變更一下分片配置即可，通過配置中心更新，無需重啟。

由於之前uid%2的資料分配在2個庫裡面，此時分散到4個庫中，由於老資料還存在（uid%4=0,還有一半uid%4=2的資料），所以需要對冗餘資料做一次清理。

而這個清理，不會影響線上資料的一致性，可是隨時隨地進行。

處理完成以後，為保證高可用，以及下一步擴容需求。可以為現有的主庫再次分配乙個從庫。

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

修改分片配置，做好新庫和老庫的對映。

同步配置，從庫公升級為主庫

解除主從關係

冗餘資料清理

為新的資料節點搭建新的從庫

雙寫的方案，更多的是針對線上資料庫遷移來用的，當然了，對於分庫的擴充套件來說也是要遷移資料的，因此，也可以來協助分庫擴容的問題。

原理和上述相同，做**擴容，只是資料的同步方式不同了。

1.增加新庫寫鏈結

雙寫的核心原理，就是對需要擴容的資料庫上，增加新庫，並對現有的分片上增加寫鏈結，同時寫兩份資料。

因為新庫的資料為空，所以資料的crud對其沒有影響，在上層的邏輯層，還是以老庫的資料為主。

2.新老庫資料遷移

通過工具，把老庫的資料遷移到新庫裡面，此時可以選擇同步**後的資料（1/2）來同步，也可以全同步，一般建議全同步，最終做資料校檢的時候好處理。

3.資料校檢

按照理想環境情況下，資料遷移之後，因為是雙寫操作，所以兩邊的資料是一致的，特別是insert和update，一致性情況很高。但真實環境中會有網路延遲等情況，對於delete情況並不是很理想，比如：

a庫刪除資料a的時候，資料a正在遷移，還沒有寫入到c庫中，此時c庫的刪除操作已經執行了，c庫會多出一條資料。

此時就需要做好資料校檢了，資料校檢可以多做幾遍，直到資料幾乎一致，盡量以舊庫的資料為準。

4.分片配置修改

資料同步完畢，就可以把新庫的分片對映重新處理了，還是按照老庫**的方式來進行，

u之前uid%2=0,變為uid%4=0和uid%4=2的

uid%2=1，變為uid%4=1和uid%4=3的。

引用:

mysql 分表平滑擴充套件 水平分庫如何做到平滑擴充套件

這個對於我們常用的分庫分表方案來說，有很大的優勢，分庫分表的擴容是一件頭疼的問題，如果採用對db層做一致性hash，或是中間價的支援，它的成本過於高昂了，如果不如此，只能停機維護來處理，對高可用性會產生影響。那是否有方案，既可以快速擴充套件，又不降低可用性？這一篇，我們聊聊分庫分表的擴充套件方案，供...

SQLServer效能優化之 水平分庫擴充套件

彙總篇 第一次引入檔案組的概念 上次說了其他的解決方案 就是沒有說水平分庫，這次好好說下。上次共享的第乙份大資料，這次正好來演示一下水平分庫 1.模擬部分資料 2.建立索引後，發現可以根據日期來分組 按資料量大致分一下 步入正軌 gui方法 3.0建立檔案組 新增檔案到檔案組 命令操作 注意 big...

面試官 如何做到不停機分庫分表遷移？

類似訂單表，使用者表這種未來規模上億甚至上十億百億的海量資料表，在專案初期為了快速上線，一般只是單錶設計，不需要考慮分庫分表。隨著業務的發展，單錶容量超過千萬甚至達到億級別以上，這時候就需要考慮分庫分表這個問題了，而不停機分庫分表遷移，這應該是分庫分表最基本的需求，畢竟網際網路專案不可能掛個廣告牌 ...