分庫分表，我再講最後一次！

「來源： ｜51CTO技術棧 ID：blog51cto」

關注

51CTO技術棧

，悅享技術，成就 CTO 夢想

“

提起分庫分表，對於大部分伺服器開發來說，其實並不是一個新鮮的名詞。隨著業務的發展，我們表中的資料量會變的越來越大，欄位也可能隨著業務複雜度的升高而逐漸增多，我們為了解決單表的查詢效能問題，一般會進行分表操作。

圖片來自 Pexels

同時我們業務的使用者活躍度也會越來越高，併發量級不斷加大，那麼可能會達到單個數據庫的處理能力上限。此時我們為了解決資料庫的處理效能瓶頸，一般會進行分庫操作。

不管是分庫操作還是分表操作，我們一般都有兩種方式應對，一種是垂直拆分，一種是水平拆分。

關於兩種拆分方式的區別和特點，網際網路上參考資料眾多，很多人都寫過相關內容，這裡就不再進行詳細贅述，有興趣的讀者可以自行檢索。

此文主要詳細聊一聊，我們最實用最常見的水平分庫分表方式中的一些特殊細節，希望能幫助大家避免走彎路，找到最合適自身業務的分庫分表設計。

【注 1】本文中的案例均基於 MySQL 資料庫，下文中的分庫分表統指水平分庫分表。

【注 2】後文中提到到 M 庫 N 表，均指共 M 個數據庫，每個資料庫共 N 個分表，即總表個數其實為 M*N。

什麼是一個好的分庫分表方案？

①方案可持續性

前期業務資料量級不大，流量較低的時候，我們無需分庫分表，也不建議分庫分表。

但是一旦我們要對業務進行分庫分表設計時，就一定要考慮到分庫分表方案的可持續性。

那何為可持續性？其實就是：業務資料量級和業務流量未來進一步升高達到新的量級的時候，我們的分庫分表方案可以持續使用。

一個通俗的案例，假定當前我們分庫分表的方案為 10 庫 100 表，那麼未來某個時間點，若 10 個庫仍然無法應對使用者的流量壓力，或者 10 個庫的磁碟使用即將達到物理上限時，我們的方案能夠進行平滑擴容。

在後文中我們將介紹下目前業界常用的翻倍擴容法和一致性 Hash 擴容法。

②資料偏斜問題

一個良好的分庫分表方案，它的資料應該是需要比較均勻的分散在各個庫表中的。

如果我們進行一個拍腦袋式的分庫分表設計，很容易會遇到以下類似問題：

某個資料庫例項中，部分表的資料很多，而其他表中的資料卻寥寥無幾，業務上的表現經常是延遲忽高忽低，飄忽不定。

資料庫叢集中，部分叢集的磁碟使用增長特別塊，而部分叢集的磁碟增長卻很緩慢。每個庫的增長步調不一致，這種情況會給後續的擴容帶來步調不一致，無法統一操作的問題。

這邊我們定義分庫分表最大資料偏斜率為：（資料量最大樣本-資料量最小樣本）/資料量最小樣本。

一般來說，如果我們的最大資料偏斜率在 5% 以內是可以接受的。

常見的分庫分表方案

①Range 分庫分表

顧名思義，該方案根據資料範圍劃分資料的存放位置。

舉個最簡單例子，我們可以把訂單表按照年份為單位，每年的資料存放在單獨的庫（或者表）中。

如下圖所示：

/**

* 透過年份分表

*

* @param orderId

* @return

*/

publicstatic String rangeShardByYear（String orderId）{

int year = Integer。parseInt（orderId。substring（0， 4））；

return“t_order_” + year；

}

透過資料的範圍進行分庫分表，該方案是最樸實的一種分庫方案，它也可以和其他分庫分表方案靈活結合使用。

時下非常流行的分散式資料庫：TiDB 資料庫，針對 TiKV 中資料的打散，也是基於 Range 的方式進行，將不同範圍內的［StartKey，EndKey）分配到不同的 Region 上。

下面我們看看該方案的缺點：

最明顯的就是資料熱點問題，

例如上面案例中的訂單表，很明顯當前年度所在的庫表屬於熱點資料，需要承載大部分的 IO 和計算資源。

新庫和新表的追加問題。

一般我們線上執行的應用程式是沒有資料庫的建庫建表許可權的，故我們需要提前將新的庫表提前建立，防止線上故障。

這點非常容易被遺忘，尤其是穩定跑了幾年沒有迭代任務，或者人員又交替頻繁的模組。

業務上的交叉範圍內資料的處理。

舉個例子，訂單模組無法避免一些中間狀態的資料補償邏輯，即需要透過定時任務到訂單表中掃描那些長時間處於待支付確認等狀態的訂單。

這裡就需要注意了，因為是透過年份進行分庫分表，那麼元旦的那一天，你的定時任務很有可能會漏掉上一年的最後一天的資料掃描。

②Hash 分庫分表

雖然分庫分表的方案眾多，但是 Hash 分庫分表是最大眾最普遍的方案，也是本文花最大篇幅描述的部分。

針對 Hash 分庫分表的細節部分，相關的資料並不多。大部分都是闡述一下概念舉幾個示例，而細節部分並沒有特別多的深入，如果未結合自身業務貿然參考引用，後期非常容易出現各種問題。

在正式介紹這種分庫分表方式之前，我們先看幾個常見的錯誤案例。

常見錯誤案例一：非互質關係導致的資料偏斜問題

publicstatic ShardCfg shard（String userId）{

int hash = userId。hashCode（）；

// 對庫數量取餘結果為庫序號

int dbIdx = Math。abs（hash % DB_CNT）；

// 對錶數量取餘結果為表序號

int tblIdx = Math。abs（hash % TBL_CNT）；

returnnew ShardCfg（dbIdx， tblIdx）；

}

上述方案是初次使用者特別容易進入的誤區，用 Hash 值分別對分庫數和分表數取餘，得到庫序號和表序號。

其實稍微思索一下，我們就會發現，以 10 庫 100 表為例，如果一個 Hash 值對 100 取餘為 0，那麼它對 10 取餘也必然為 0。

這就意味著只有 0 庫裡面的 0 表才可能有資料，而其他庫中的 0 表永遠為空！

類似的我們還能推導到，0 庫裡面的共 100 張表，只有 10 張表中（個位數為 0 的表序號）才可能有資料。

這就帶來了非常嚴重的資料偏斜問題，因為某些表中永遠不可能有資料，最大資料偏斜率達到了無窮大。

那麼很明顯，該方案是一個未達到預期效果的錯誤方案。資料的散落情況大致示意圖如下：

事實上，只要庫數量和表數量非互質關係，都會出現某些表中無資料的問題。

證明如下：

那麼是不是隻要庫數量和表數量互質就可用用這種分庫分表方案呢？比如我用 11 庫 100 表的方案，是不是就合理了呢？

答案是否定的，我們除了要考慮資料偏斜的問題，還需要考慮可持續性擴容的問題，一般這種 Hash 分庫分表的方案後期的擴容方式都是透過翻倍擴容法，那 11 庫翻倍後，和 100 又不再互質。

當然，如果分庫數和分表數不僅互質，而且分表數為奇數（例如 10 庫 101 表），則理論上可以使用該方案，但是我想大部分人可能都會覺得使用奇數的分表數比較奇怪吧。

常見錯誤案例二：擴容難以持續

如果避開了上述案例一的陷阱，那麼我們又很容易一頭扎進另一個陷阱，大概思路如下。

我們把 10 庫 100 表看成總共 1000 個邏輯表，將求得的 Hash 值對 1000 取餘，得到一個介於［0，999）中的數，然後再將這個數二次均分到每個庫和每個表中。

大概邏輯程式碼如下：

publicstatic ShardCfg shard（String userId）{

// ① 算Hash

int hash = userId。hashCode（）；

// ② 總分片數

int sumSlot = DB_CNT * TBL_CNT；

// ③ 分片序號

int slot = Math。abs（hash % sumSlot）；

// ④ 計算庫序號和表序號的錯誤案例

int dbIdx = slot % DB_CNT ；

int tblIdx = slot / DB_CNT ；

returnnew ShardCfg（dbIdx， tblIdx）；

}

該方案確實很巧妙的解決了資料偏斜的問題，只要 Hash 值足夠均勻，那麼理論上分配序號也會足夠平均，於是每個庫和表中的資料量也能保持較均衡的狀態。

但是該方案有個比較大的問題，那就是在計算表序號的時候，依賴了總庫的數量，那麼後續翻倍擴容法進行擴容時，會出現擴容前後資料不在同一個表中，從而無法實施。

如上圖中，例如擴容前 Hash 為 1986 的資料應該存放在 6 庫 98 表，但是翻倍擴容成 20 庫 100 表後，它分配到了 6 庫 99 表，表序號發生了偏移。

這樣的話，我們在後續在擴容的時候，不僅要基於庫遷移資料，還要基於表遷移資料，非常麻煩且易錯。

看完了上面的幾種典型的錯誤案例，那麼我們有哪些比較正確的方案呢？下面將結合一些實際場景案例介紹幾種 Hash 分庫分表的方案。

常用姿勢一：標準的二次分片法

上述錯誤案例二中，整體思路完全正確，只是最後計算庫序號和表序號的時候，使用了庫數量作為影響表序號的因子，導致擴容時表序號偏移而無法進行。

事實上，我們只需要換種寫法，就能得出一個比較大眾化的分庫分表方案。

publicstatic ShardCfg shard2（String userId）{

// ① 算Hash

int hash = userId。hashCode（）；

// ② 總分片數

int sumSlot = DB_CNT * TBL_CNT；

// ③ 分片序號

int slot = Math。abs（hash % sumSlot）；

// ④ 重新修改二次求值方案

int dbIdx = slot / TBL_CNT ；

int tblIdx = slot % TBL_CNT ；

returnnew ShardCfg（dbIdx， tblIdx）；

}

大家可以注意到，和錯誤案例二中的區別就是透過分配序號重新計算庫序號和表序號的邏輯發生了變化。

它的分配情況如下：

那為何使用這種方案就能夠有很好的擴充套件永續性呢？我們進行一個簡短的證明：

透過上面結論我們知道，透過翻倍擴容後，我們的表序號一定維持不變，庫序號可能還是在原來庫，也可能平移到了新庫中（原庫序號加上原分庫數），完全符合我們需要的擴容永續性方案。

方案缺點：

翻倍擴容法前期操作性高，但是後續如果分庫數已經是大幾十的時候，每次擴容都非常耗費資源。

連續的分片鍵 Hash 值大機率會散落在相同的庫中，某些業務可能容易存在庫熱點（例如新生成的使用者 Hash 相鄰且遞增，且新增使用者又是高機率的活躍使用者，那麼一段時間內生成的新使用者都會集中在相鄰的幾個庫中）。

常用姿勢二：關係表冗餘

我們可以將分片鍵對應庫的關係透過關係表記錄下來，我們把這張關係表稱為“路由關係表”。

publicstatic ShardCfg shard（String userId） {

int tblIdx = Math。abs（userId。hashCode（） % TBL_CNT）；

// 從快取獲取

Integer dbIdx = loadFromCache（userId）；

if （null == dbIdx） {

// 從路由表獲取

dbIdx = loadFromRouteTable（userId）；

if （null ！= dbIdx） {

// 儲存到快取

saveRouteCache（userId， dbIdx）；

}

}

if （null == dbIdx） {

// 此處可以自由實現計算庫的邏輯

dbIdx = selectRandomDbIdx（）；

saveToRouteTable（userId， dbIdx）；

saveRouteCache（userId， dbIdx）；

}

returnnew ShardCfg（dbIdx， tblIdx）；

}

該方案還是透過常規的 Hash 演算法計算表序號，而計算庫序號時，則從路由表讀取資料。

因為在每次資料查詢時，都需要讀取路由表，故我們需要將分片鍵和庫序號的對應關係記錄同時維護在快取中以提升效能。

上述例項中 selectRandomDbIdx 方法作用為生成該分片鍵對應的儲存庫序號，這邊可以非常靈活的動態配置。

例如可以為每個庫指定一個權重，權重大的被選中的機率更高，權重配置成0則可以將關閉某些庫的分配。當發現數據存在偏斜時，也可以調整權重使得各個庫的使用量調整趨向接近。

該方案還有個優點，就是理論上後續進行擴容的時候，僅需要掛載上新的資料庫節點，將權重配置成較大值即可，無需進行任何的資料遷移即可完成。

如下圖所示：最開始我們為 4 個數據庫分配了相同的權重，理論上落在每個庫的資料機率均等。

但是由於使用者也有高頻低頻之分，可能某些庫的資料增長會比較快。當掛載新的資料庫節點後，我們靈活的調整了每個庫的新權重。

該方案似乎解決了很多問題，那麼它有沒有什麼不適合的場景呢？當然有，該方案在很多場景下其實並不太適合。

以下舉例說明：

每次讀取資料需要訪問路由表，雖然使用了快取，但是還是有一定的效能損耗。

路由關係表的儲存方面，有些場景並不合適。例如上述案例中使用者 id 的規模大概是在 10 億以內，我們用單庫百表儲存該關係表即可。

但如果例如要用檔案 MD5 摘要值作為分片鍵，因為樣本集過大，無法為每個 md5 值都去指定關係（當然我們也可以使用 md5 前 N 位來儲存關係）。

飢餓佔位問題，如下詳敘：我們知道，該方案的特點是後續無需擴容，可以隨時修改權重調整每個庫的儲存增長速度。

但是這個願景是比較縹緲，並且很難實施的，我們選取一個簡單的業務場景考慮以下幾個問題。

【業務場景】：

以使用者存放檔案到雲端的雲盤業務為例，需要對使用者的檔案資訊進行分庫分表設計。

有以下假定場景：

假定有 2 億理論使用者，假設當前有 3000W 有效使用者。

平均每個使用者檔案量級在 2000 個以內

使用者 id 為隨機 16 位字串

初期為 10 庫，每個庫 100 張表。

我們使用路由表記錄每個使用者所在的庫序號資訊。那麼該方案會有以下問題：

第一：我們總共有 2 億個使用者，只有 3000W 個產生過事務的使用者。若程式不加處理，使用者發起任何請求則建立路由表資料，會導致為大量實際沒有事務資料的使用者提前建立路由表。

筆者最初儲存雲盤使用者資料的時候便遇到了這個問題，客戶端 app 會在首頁查詢使用者空間使用情況，這樣導致幾乎一開始就為每個使用者分配好了路由。

隨著時間的推移，這部分沒有資料的“靜默”的使用者，隨時可能開始他的雲盤使用之旅而“復甦”，從而導致它所在的庫迅速增長並超過單個庫的空間容量極限，從而被迫拆分擴容。

解決這個問題的方案，其實就是隻針對事務操作（例如購買空間，上傳資料，建立資料夾等等）才進行路由的分配，這樣對程式碼層面便有了一些傾入。

第二、按照前面描述的業務場景，一個使用者最終平均有 2000 條資料，假定每行大小為 1K。

為了保證 B+樹的層級在 3 層，我們限制每張表的資料量在 2000W，分表數為 100 的話，可以得到理論上每個庫的使用者數不能超過 100W 個使用者。

也就是如果是 3000W 個產生過事務的使用者，我們需要為其分配 30 個庫，這樣會在業務前期，使用者平均資料量相對較少的時候，存在非常大的資料庫資源的浪費。

解決第二個問題，我們一般可以將很多資料庫放在一個例項上，後續隨著增長情況進行拆分。也可以後續針對將滿的庫，使用常規手段進行拆分和遷移。

常用姿勢三：基因法

還是由錯誤案例一啟發，我們發現案例一不合理的主要原因，就是因為庫序號和表序號的計算邏輯中，有公約數這個因子在影響庫表的獨立性。

那麼我們是否可以換一種思路呢？我們使用相對獨立的 Hash 值來計算庫序號和表序號。

publicstatic ShardCfg shard（String userId）{

int dbIdx = Math。abs（userId。substring（0， 4）。hashCode（） % DB_CNT ）；

int tblIdx = Math。abs（userId。hashCode（） % TBL_CNT）；

returnnew ShardCfg（dbIdx， tblIdx）；

}

如上所示，我們計算庫序號的時候做了部分改動，我們使用分片鍵的前四位作為 Hash 值來計算庫序號。

這也是一種常用的方案，我們稱為基因法，即使用原分片鍵中的某些基因（例如前四位）作為庫的計算因子，而使用另外一些基因作為表的計算因子。

該方案也是網上不少的實踐方案或者是其變種，看起來非常巧妙的解決了問題，然而在實際生成過程中還是需要慎重。

筆者曾在雲盤的空間模組的分庫分表實踐中採用了該方案，使用 16 庫 100 表拆分資料，上線初期資料正常。

然而當資料量級增長起來後，發現每個庫的使用者數量嚴重不均等，故猜測該方案存在一定的資料偏斜。

為了驗證觀點，進行如下測試，隨機 2 億個使用者 id（16 位的隨機字串），針對不同的 M 庫 N 表方案，重複若干次後求平均值得到結論如下：

8庫100表

min=248305（dbIdx=2， tblIdx=64）， max=251419（dbIdx=7， tblIdx=8）， rate= 1。25% √

16庫100表

min=95560（dbIdx=8， tblIdx=42）， max=154476（dbIdx=0， tblIdx=87）， rate= 61。65% ×

20庫100表

min=98351（dbIdx=14， tblIdx=78）， max=101228（dbIdx=6， tblIdx=71）， rate= 2。93%

我們發現該方案中，分庫數為 16，分表數為 100，數量最小行數僅為 10W 不到，但是最多的已經達到了 15W+，最大資料偏斜率高達 61%。

按這個趨勢發展下去，後期很可能出現一臺資料庫容量已經使用滿，而另一臺還剩下 30%+ 的容量。

該方案並不是一定不行，而是我們在採用的時候，要綜合分片鍵的樣本規則，選取的分片鍵字首位數，庫數量，表數量，四個變數對最終的偏斜率都有影響。

例如上述例子中，如果不是 16 庫 100 表，而是 8 庫 100 表，或者 20 庫 100 表，資料偏斜率都能降低到了 5% 以下的可接受範圍。

所以該方案的隱藏的“坑”較多，我們不僅要估算上線初期的偏斜率，還需要測算若干次翻倍擴容後的資料偏斜率。

例如你用著初期比較完美的 8 庫 100 表的方案，後期擴容成 16 庫 100 表的時候，麻煩就接踵而至。

常用姿勢四：剔除公因數法

還是基於錯誤案例一啟發，在很多場景下我們還是希望相鄰的 Hash 能分到不同的庫中。就像 N 庫單表的時候，我們計算庫序號一般直接用 Hash 值對庫數量取餘。

那麼我們是不是可以有辦法去除掉公因數的影響呢？下面為一個可以考慮的實現案例：

publicstatic ShardCfg shard（String userId）{

int dbIdx = Math。abs（userId。hashCode（） % DB_CNT）；

// 計算表序號時先剔除掉公約數的影響

int tblIdx = Math。abs（（userId。hashCode（） / TBL_CNT） % TBL_CNT）；

returnnew ShardCfg（dbIdx， tblIdx）；

}

經過測算，該方案的最大資料偏斜度也比較小，針對不少業務從 N 庫 1 表升級到 N 庫 M 表下，需要維護庫序號不變的場景下可以考慮。

常用姿勢五：一致性 Hash 法

一致性 Hash 演算法也是一種比較流行的叢集資料分割槽演算法，比如 RedisCluster 即是透過一致性 Hash 演算法，使用 16384 個虛擬槽節點進行每個分片資料的管理。

關於一致性 Hash 的具體原理這邊不再重複描述，讀者可以自行翻閱資料。這邊詳細介紹如何使用一致性 Hash 進行分庫分表的設計。

我們通常會將每個實際節點的配置持久化在一個配置項或者是資料庫中，應用啟動時或者是進行切換操作的時候會去載入配置。

配置一般包括一個［StartKey，Endkey）的左閉右開區間和一個數據庫節點資訊，例如：

示例程式碼：

private TreeMap nodeTreeMap = new TreeMap<>（）；

@Override

publicvoidafterPropertiesSet（）{

// 啟動時載入分割槽配置

List cfgList = fetchCfgFromDb（）；

for （HashCfg cfg ： cfgList） {

nodeTreeMap。put（cfg。endKey， cfg。nodeIdx）；

}

}

public ShardCfg shard（String userId）{

int hash = userId。hashCode（）；

int dbIdx = nodeTreeMap。tailMap（（long） hash， false）。firstEntry（）。getValue（）；

int tblIdx = Math。abs（hash % 100）；

returnnew ShardCfg（dbIdx， tblIdx）；

}

我們可以看到，這種形式和上文描述的 Range 分表非常相似，Range 分庫分表方式針對分片鍵本身劃分範圍，而一致性 Hash 是針對分片鍵的 Hash 值進行範圍配置。

正規的一致性 Hash 演算法會引入虛擬節點，每個虛擬節點會指向一個真實的物理節點。

這樣設計方案主要是能夠在加入新節點後的時候，可以有方案保證每個節點遷移的資料量級和遷移後每個節點的壓力保持幾乎均等。

但是用在分庫分表上，一般大部分都只用實際節點，引入虛擬節點的案例不多。

主要有以下原因：

應用程式需要花費額外的耗時和記憶體來載入虛擬節點的配置資訊。如果虛擬節點較多，記憶體的佔用也會有些不太樂觀。

由於 MySQL 有非常完善的主從複製方案，與其透過從各個虛擬節點中篩選需要遷移的範圍資料進行遷移，不如透過從庫升級方式處理後再刪除冗餘資料簡單可控。

虛擬節點主要解決的痛點是節點資料搬遷過程中各個節點的負載不均衡問題，透過虛擬節點打散到各個節點中均攤壓力進行處理。

而作為 OLTP 資料庫，我們很少需要突然將某個資料庫下線，新增節點後一般也不會從 0 開始從其他節點搬遷資料，而是前置準備好大部分資料的方式，故一般來說沒有必要引入虛擬節點來增加複雜度。

常見擴容方案

①翻倍擴容法

翻倍擴容法的主要思維是每次擴容，庫的數量均翻倍處理，而翻倍的資料來源通常是由原資料來源透過主從複製方式得到的從庫升級成主庫提供服務的方式。故有些文件將其稱作“從庫升級法”。

理論上，經過翻倍擴容法後，我們會多一倍的資料庫用來儲存資料和應對流量，原先資料庫的磁碟使用量也將得到一半空間的釋放。

如下圖所示：

具體的流程大致如下：

時間點 t1：

為每個節點都新增從庫，開啟主從同步進行資料同步。

時間點 t2：

主從同步完成後，對主庫進行禁寫。

此處禁寫主要是為了保證資料的正確性。若不進行禁寫操作，在以下兩個時間視窗期內將出現資料不一致的問題：

斷開主從後，若主庫不禁寫，主庫若還有資料寫入，這部分資料將無法同步到從庫中。

應用叢集識別到分庫數翻倍的時間點無法嚴格一致，在某個時間點可能兩臺應用使用不同的分庫數，運算到不同的庫序號，導致錯誤寫入。

時間點 t3：

同步完全完成後，斷開主從關係，理論上此時從庫和主庫有著完全一樣的資料集。

時間點t4：

從庫升級為叢集節點，業務應用識別到新的分庫數後，將應用新的路由演算法。

一般情況下，我們將分庫數的配置放到配置中心中，當上述三個步驟完成後，我們修改分庫數進行翻倍，應用生效後，應用服務將使用新的配置。

這裡需要注意的是，業務應用接收到新的配置的時間點不一定一致，所以必定存在一個時間視窗期，該期間部分機器使用原分庫數，部分節點使用新分庫數。這也正是我們的禁寫操作一定要在此步完成後才能放開的原因。

時間點 t5：

確定所有的應用均接受到庫總數的配置後，放開原主庫的禁寫操作，此時應用完全恢復服務。

啟動離線的定時任務，

清除各庫中的約一半冗餘資料。

為了節省磁碟的使用率，我們可以選擇離線定時任務清除冗餘的資料。也可以在業務初期表結構設計的時候，將索引鍵的 Hash 值存為一個欄位。

那麼以上述常用姿勢四為例，我們離線的清除任務可以簡單的透過 sql 即可實現（需要防止鎖住全表，可以拆分成若干個 id 範圍的子 sql 執行）：

deletefrom db0。tbl0 where hash_val mod4 <> 0；

deletefrom db1。tbl0 where hash_val mod4 <> 1；

deletefrom db2。tbl0 where hash_val mod4 <> 2；

deletefrom db3。tbl0 where hash_val mod4 <> 3；

具體的擴容步驟可參考下圖：

總結：

透過上述遷移方案可以看出，從時間點 t2 到 t5 時間視窗呢內，需要對資料庫禁寫，相當於是該時間範圍內伺服器是部分有損的，該階段整體耗時差不多是在分鐘級範圍內。若業務可以接受，可以在業務低峰期進行該操作。

當然也會有不少應用無法容忍分鐘級寫入不可用，例如寫操作遠遠大於讀操作的應用，此時可以結合 canel 開源框架進行視窗期內資料雙寫操作以保證資料的一致性。

該方案主要藉助於 MySQL 強大完善的主從同步機制，能在事前提前準備好新的節點中大部分需要的資料，節省大量的人為資料遷移操作。

但是缺點也很明顯，一是過程中整個服務可能需要以有損為代價，二是每次擴容均需要對庫數量進行翻倍，會提前浪費不少的資料庫資源。

②一致性 Hash 擴容

我們主要還是看下不帶虛擬槽的一致性 Hash 擴容方法，假如當前資料庫節點 DB0 負載或磁碟使用過大需要擴容，我們透過擴容可以達到例如下圖的效果。

下圖中，擴容前配置了三個 Hash 分段，發現［-Inf，-10000）範圍內的的資料量過大或者壓力過高時，需要對其進行擴容。

主要步驟如下：

時間點 t1：

針對需要擴容的資料庫節點增加從節點，開啟主從同步進行資料同步。

時間點 t2：

完成主從同步後，對原主庫進行禁寫。此處原因和翻倍擴容法類似，需要保證新的從庫和原來主庫中資料的一致性。

時間點 t3：

同步完全完成後，斷開主從關係，理論上此時從庫和主庫有著完全一樣的資料集。

時間點 t4：

修改一致性 Hash 範圍的配置，並使應用服務重新讀取並生效。

時間點 t5：

確定所有的應用均接受到新的一致性 Hash 範圍配置後，放開原主庫的禁寫操作，此時應用完全恢復服務。

啟動離線的定時任務，

清除冗餘資料。

可以看到，該方案和翻倍擴容法的方案比較類似，但是它更加靈活，可以根據當前叢集每個節點的壓力情況選擇性擴容，而無需整個叢集同時翻倍進行擴容。

小結

本文主要描述了我們進行水平分庫分表設計時的一些常見方案。

我們在進行分庫分表設計時，可以選擇例如範圍分表，Hash 分表，路由表，或者一致性 Hash 分表等各種方案。進行選擇時需要充分考慮到後續的擴容可持續性，最大資料偏斜率等因素。

文中也列舉了一些常見的錯誤示例，例如庫表計算邏輯中公約數的影響，使用前若干位計算庫序號常見的資料傾斜因素等等。

我們在實際進行選擇時，一定要考慮自身的業務特點，充分驗證分片鍵在各個引數因子下的資料偏斜程度，並提前規劃考慮好後續擴容的方案。