[[430710]]

圖片來自 包圖網(wǎng)

提起分庫分表，對于大部分服務(wù)器開發(fā)來說，其實并不是一個新鮮的名詞。隨著業(yè)務(wù)的發(fā)展，我們表中的數(shù)據(jù)量會變的越來越大，字段也可能隨著業(yè)務(wù)復(fù)雜度的升高而逐漸增多，我們?yōu)榱私鉀Q單表的查詢性能問題，一般會進行分表操作。

同時我們業(yè)務(wù)的用戶活躍度也會越來越高，并發(fā)量級不斷加大，那么可能會達到單個數(shù)據(jù)庫的處理能力上限。此時我們?yōu)榱私鉀Q數(shù)據(jù)庫的處理性能瓶頸，一般會進行分庫操作。

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

關(guān)于兩種拆分方式的區(qū)別和特點，互聯(lián)網(wǎng)上參考資料眾多，很多人都寫過相關(guān)內(nèi)容，這里就不再進行詳細贅述，有興趣的讀者可以自行檢索。

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

【注 1】本文中的案例均基于 MySQL 數(shù)據(jù)庫，下文中的分庫分表統(tǒng)指水平分庫分表。

【注 2】后文中提到到 M 庫 N 表，均指共 M 個數(shù)據(jù)庫，每個數(shù)據(jù)庫共 N 個分表，即總表個數(shù)其實為 M*N。

什么是一個好的分庫分表方案?

①方案可持續(xù)性

前期業(yè)務(wù)數(shù)據(jù)量級不大，流量較低的時候，我們無需分庫分表，也不建議分庫分表。

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

那何為可持續(xù)性?其實就是：業(yè)務(wù)數(shù)據(jù)量級和業(yè)務(wù)流量未來進一步升高達到新的量級的時候，我們的分庫分表方案可以持續(xù)使用。

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

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

②數(shù)據(jù)偏斜問題

一個良好的分庫分表方案，它的數(shù)據(jù)應(yīng)該是需要比較均勻的分散在各個庫表中的。

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

• 某個數(shù)據(jù)庫實例中，部分表的數(shù)據(jù)很多，而其他表中的數(shù)據(jù)卻寥寥無幾，業(yè)務(wù)上的表現(xiàn)經(jīng)常是延遲忽高忽低，飄忽不定。
• 數(shù)據(jù)庫集群中，部分集群的磁盤使用增長特別塊，而部分集群的磁盤增長卻很緩慢。每個庫的增長步調(diào)不一致，這種情況會給后續(xù)的擴容帶來步調(diào)不一致，無法統(tǒng)一操作的問題。

這邊我們定義分庫分表最大數(shù)據(jù)偏斜率為：(數(shù)據(jù)量最大樣本-數(shù)據(jù)量最小樣本)/數(shù)據(jù)量最小樣本。

一般來說，如果我們的最大數(shù)據(jù)偏斜率在 5% 以內(nèi)是可以接受的。

常見的分庫分表方案

①Range 分庫分表

顧名思義，該方案根據(jù)數(shù)據(jù)范圍劃分數(shù)據(jù)的存放位置。

舉個最簡單例子，我們可以把訂單表按照年份為單位，每年的數(shù)據(jù)存放在單獨的庫(或者表)中。

如下圖所示：

/** 
 * 通過年份分表 
 * 
 * @param orderId 
 * @return 
 */ 
public static String rangeShardByYear(String orderId) { 
    int year = Integer.parseInt(orderId.substring(0, 4)); 
    return "t_order_" + year; 
} 

通過數(shù)據(jù)的范圍進行分庫分表，該方案是最樸實的一種分庫方案，它也可以和其他分庫分表方案靈活結(jié)合使用。

時下非常流行的分布式數(shù)據(jù)庫：TiDB 數(shù)據(jù)庫，針對 TiKV 中數(shù)據(jù)的打散，也是基于 Range 的方式進行，將不同范圍內(nèi)的[StartKey，EndKey)分配到不同的 Region 上。

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

• 最明顯的就是數(shù)據(jù)熱點問題，例如上面案例中的訂單表，很明顯當前年度所在的庫表屬于熱點數(shù)據(jù)，需要承載大部分的 IO 和計算資源。
• 新庫和新表的追加問題。一般我們線上運行的應(yīng)用程序是沒有數(shù)據(jù)庫的建庫建表權(quán)限的，故我們需要提前將新的庫表提前建立，防止線上故障。
• 這點非常容易被遺忘，尤其是穩(wěn)定跑了幾年沒有迭代任務(wù)，或者人員又交替頻繁的模塊。

業(yè)務(wù)上的交叉范圍內(nèi)數(shù)據(jù)的處理。舉個例子，訂單模塊無法避免一些中間狀態(tài)的數(shù)據(jù)補償邏輯，即需要通過定時任務(wù)到訂單表中掃描那些長時間處于待支付確認等狀態(tài)的訂單。

這里就需要注意了，因為是通過年份進行分庫分表，那么元旦的那一天，你的定時任務(wù)很有可能會漏掉上一年的最后一天的數(shù)據(jù)掃描。

②Hash 分庫分表

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

針對 Hash 分庫分表的細節(jié)部分，相關(guān)的資料并不多。大部分都是闡述一下概念舉幾個示例，而細節(jié)部分并沒有特別多的深入，如果未結(jié)合自身業(yè)務(wù)貿(mào)然參考引用，后期非常容易出現(xiàn)各種問題。

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

常見錯誤案例一：非互質(zhì)關(guān)系導(dǎo)致的數(shù)據(jù)偏斜問題

public static ShardCfg shard(String userId) { 
    int hash = userId.hashCode(); 
    // 對庫數(shù)量取余結(jié)果為庫序號 
    int dbIdx = Math.abs(hash % DB_CNT); 
    // 對表數(shù)量取余結(jié)果為表序號 
    int tblIdx = Math.abs(hash % TBL_CNT); 
 
    return new ShardCfg(dbIdx, tblIdx); 
} 

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

其實稍微思索一下，我們就會發(fā)現(xiàn)，以 10 庫 100 表為例，如果一個 Hash 值對 100 取余為 0，那么它對 10 取余也必然為 0。

這就意味著只有 0 庫里面的 0 表才可能有數(shù)據(jù)，而其他庫中的 0 表永遠為空!

類似的我們還能推導(dǎo)到，0 庫里面的共 100 張表，只有 10 張表中(個位數(shù)為 0 的表序號)才可能有數(shù)據(jù)。

這就帶來了非常嚴重的數(shù)據(jù)偏斜問題，因為某些表中永遠不可能有數(shù)據(jù)，最大數(shù)據(jù)偏斜率達到了無窮大。

那么很明顯，該方案是一個未達到預(yù)期效果的錯誤方案。數(shù)據(jù)的散落情況大致示意圖如下：

事實上，只要庫數(shù)量和表數(shù)量非互質(zhì)關(guān)系，都會出現(xiàn)某些表中無數(shù)據(jù)的問題。

證明如下：

那么是不是只要庫數(shù)量和表數(shù)量互質(zhì)就可用用這種分庫分表方案呢?比如我用 11 庫 100 表的方案，是不是就合理了呢?

答案是否定的，我們除了要考慮數(shù)據(jù)偏斜的問題，還需要考慮可持續(xù)性擴容的問題，一般這種 Hash 分庫分表的方案后期的擴容方式都是通過翻倍擴容法，那 11 庫翻倍后，和 100 又不再互質(zhì)。

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

常見錯誤案例二：擴容難以持續(xù)

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

我們把 10 庫 100 表看成總共 1000 個邏輯表，將求得的 Hash 值對 1000 取余，得到一個介于[0，999)中的數(shù)，然后再將這個數(shù)二次均分到每個庫和每個表中。

大概邏輯代碼如下：

public static ShardCfg shard(String userId) { 
        // ① 算Hash 
        int hash = userId.hashCode(); 
        // ② 總分片數(shù) 
        int sumSlot = DB_CNT * TBL_CNT; 
        // ③ 分片序號 
        int slot = Math.abs(hash % sumSlot); 
        // ④ 計算庫序號和表序號的錯誤案例 
        int dbIdx = slot % DB_CNT ; 
        int tblIdx = slot / DB_CNT ; 
 
        return new ShardCfg(dbIdx, tblIdx); 
    } 

該方案確實很巧妙的解決了數(shù)據(jù)偏斜的問題，只要 Hash 值足夠均勻，那么理論上分配序號也會足夠平均，于是每個庫和表中的數(shù)據(jù)量也能保持較均衡的狀態(tài)。

但是該方案有個比較大的問題，那就是在計算表序號的時候，依賴了總庫的數(shù)量，那么后續(xù)翻倍擴容法進行擴容時，會出現(xiàn)擴容前后數(shù)據(jù)不在同一個表中，從而無法實施。

如上圖中，例如擴容前 Hash 為 1986 的數(shù)據(jù)應(yīng)該存放在 6 庫 98 表，但是翻倍擴容成 20 庫 100 表后，它分配到了 6 庫 99 表，表序號發(fā)生了偏移。

這樣的話，我們在后續(xù)在擴容的時候，不僅要基于庫遷移數(shù)據(jù)，還要基于表遷移數(shù)據(jù)，非常麻煩且易錯。

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

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

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

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

public static ShardCfg shard2(String userId) { 
        // ① 算Hash 
        int hash = userId.hashCode(); 
        // ② 總分片數(shù) 
        int sumSlot = DB_CNT * TBL_CNT; 
        // ③ 分片序號 
        int slot = Math.abs(hash % sumSlot); 
        // ④ 重新修改二次求值方案 
        int dbIdx = slot / TBL_CNT ; 
        int tblIdx = slot % TBL_CNT ; 
 
        return new ShardCfg(dbIdx, tblIdx); 
    } 

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

它的分配情況如下：

那為何使用這種方案就能夠有很好的擴展持久性呢?我們進行一個簡短的證明：

通過上面結(jié)論我們知道，通過翻倍擴容后，我們的表序號一定維持不變，庫序號可能還是在原來庫，也可能平移到了新庫中(原庫序號加上原分庫數(shù))，完全符合我們需要的擴容持久性方案。

方案缺點：

• 翻倍擴容法前期操作性高，但是后續(xù)如果分庫數(shù)已經(jīng)是大幾十的時候，每次擴容都非常耗費資源。
• 連續(xù)的分片鍵 Hash 值大概率會散落在相同的庫中，某些業(yè)務(wù)可能容易存在庫熱點(例如新生成的用戶 Hash 相鄰且遞增，且新增用戶又是高概率的活躍用戶，那么一段時間內(nèi)生成的新用戶都會集中在相鄰的幾個庫中)。

常用姿勢二：關(guān)系表冗余

我們可以將分片鍵對應(yīng)庫的關(guān)系通過關(guān)系表記錄下來，我們把這張關(guān)系表稱為"路由關(guān)系表"。

public static 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) { 
            // 此處可以自由實現(xiàn)計算庫的邏輯 
            dbIdx = selectRandomDbIdx(); 
            saveToRouteTable(userId, dbIdx); 
            saveRouteCache(userId, dbIdx); 
        } 
 
        return new ShardCfg(dbIdx, tblIdx); 
    } 

該方案還是通過常規(guī)的 Hash 算法計算表序號，而計算庫序號時，則從路由表讀取數(shù)據(jù)。

因為在每次數(shù)據(jù)查詢時，都需要讀取路由表，故我們需要將分片鍵和庫序號的對應(yīng)關(guān)系記錄同時維護在緩存中以提升性能。

上述實例中 selectRandomDbIdx 方法作用為生成該分片鍵對應(yīng)的存儲庫序號，這邊可以非常靈活的動態(tài)配置。

例如可以為每個庫指定一個權(quán)重，權(quán)重大的被選中的概率更高，權(quán)重配置成0則可以將關(guān)閉某些庫的分配。當發(fā)現(xiàn)數(shù)據(jù)存在偏斜時，也可以調(diào)整權(quán)重使得各個庫的使用量調(diào)整趨向接近。

該方案還有個優(yōu)點，就是理論上后續(xù)進行擴容的時候，僅需要掛載上新的數(shù)據(jù)庫節(jié)點，將權(quán)重配置成較大值即可，無需進行任何的數(shù)據(jù)遷移即可完成。

如下圖所示：最開始我們?yōu)?4 個數(shù)據(jù)庫分配了相同的權(quán)重，理論上落在每個庫的數(shù)據(jù)概率均等。

但是由于用戶也有高頻低頻之分，可能某些庫的數(shù)據(jù)增長會比較快。當掛載新的數(shù)據(jù)庫節(jié)點后，我們靈活的調(diào)整了每個庫的新權(quán)重。

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

以下舉例說明：

• 每次讀取數(shù)據(jù)需要訪問路由表，雖然使用了緩存，但是還是有一定的性能損耗。
• 路由關(guān)系表的存儲方面，有些場景并不合適。例如上述案例中用戶 id 的規(guī)模大概是在 10 億以內(nèi)，我們用單庫百表存儲該關(guān)系表即可。

但如果例如要用文件 MD5 摘要值作為分片鍵，因為樣本集過大，無法為每個 md5 值都去指定關(guān)系(當然我們也可以使用 md5 前 N 位來存儲關(guān)系)。

• 饑餓占位問題，如下詳敘：我們知道，該方案的特點是后續(xù)無需擴容，可以隨時修改權(quán)重調(diào)整每個庫的存儲增長速度。

但是這個愿景是比較縹緲，并且很難實施的，我們選取一個簡單的業(yè)務(wù)場景考慮以下幾個問題。

【業(yè)務(wù)場景】：以用戶存放文件到云端的云盤業(yè)務(wù)為例，需要對用戶的文件信息進行分庫分表設(shè)計。

有以下假定場景：

• 假定有 2 億理論用戶，假設(shè)當前有 3000W 有效用戶。
• 平均每個用戶文件量級在 2000 個以內(nèi)
• 用戶 id 為隨機 16 位字符串
• 初期為 10 庫，每個庫 100 張表。

我們使用路由表記錄每個用戶所在的庫序號信息。那么該方案會有以下問題：

第一：我們總共有 2 億個用戶，只有 3000W 個產(chǎn)生過事務(wù)的用戶。若程序不加處理，用戶發(fā)起任何請求則創(chuàng)建路由表數(shù)據(jù)，會導(dǎo)致為大量實際沒有事務(wù)數(shù)據(jù)的用戶提前創(chuàng)建路由表。

筆者最初存儲云盤用戶數(shù)據(jù)的時候便遇到了這個問題，客戶端 app 會在首頁查詢用戶空間使用情況，這樣導(dǎo)致幾乎一開始就為每個使用者分配好了路由。

隨著時間的推移，這部分沒有數(shù)據(jù)的"靜默"的用戶，隨時可能開始他的云盤使用之旅而“復(fù)蘇”，從而導(dǎo)致它所在的庫迅速增長并超過單個庫的空間容量極限，從而被迫拆分擴容。

解決這個問題的方案，其實就是只針對事務(wù)操作(例如購買空間，上傳數(shù)據(jù)，創(chuàng)建文件夾等等)才進行路由的分配，這樣對代碼層面便有了一些傾入。

第二、按照前面描述的業(yè)務(wù)場景，一個用戶最終平均有 2000 條數(shù)據(jù)，假定每行大小為 1K。

為了保證 B+樹的層級在 3 層，我們限制每張表的數(shù)據(jù)量在 2000W，分表數(shù)為 100 的話，可以得到理論上每個庫的用戶數(shù)不能超過 100W 個用戶。

也就是如果是 3000W 個產(chǎn)生過事務(wù)的用戶，我們需要為其分配 30 個庫，這樣會在業(yè)務(wù)前期，用戶平均數(shù)據(jù)量相對較少的時候，存在非常大的數(shù)據(jù)庫資源的浪費。

解決第二個問題，我們一般可以將很多數(shù)據(jù)庫放在一個實例上，后續(xù)隨著增長情況進行拆分。也可以后續(xù)針對將滿的庫，使用常規(guī)手段進行拆分和遷移。

常用姿勢三：基因法

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

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

public static ShardCfg shard(String userId) { 
    int dbIdx = Math.abs(userId.substring(0, 4).hashCode() % DB_CNT ); 
    int tblIdx = Math.abs(userId.hashCode() % TBL_CNT); 
    return new ShardCfg(dbIdx, tblIdx); 
} 

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

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

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

筆者曾在云盤的空間模塊的分庫分表實踐中采用了該方案，使用 16 庫 100 表拆分數(shù)據(jù)，上線初期數(shù)據(jù)正常。

然而當數(shù)據(jù)量級增長起來后，發(fā)現(xiàn)每個庫的用戶數(shù)量嚴重不均等，故猜測該方案存在一定的數(shù)據(jù)偏斜。

為了驗證觀點，進行如下測試，隨機 2 億個用戶 id(16 位的隨機字符串)，針對不同的 M 庫 N 表方案，重復(fù)若干次后求平均值得到結(jié)論如下：

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% 

我們發(fā)現(xiàn)該方案中，分庫數(shù)為 16，分表數(shù)為 100，數(shù)量最小行數(shù)僅為 10W 不到，但是最多的已經(jīng)達到了 15W+，最大數(shù)據(jù)偏斜率高達 61%。

按這個趨勢發(fā)展下去，后期很可能出現(xiàn)一臺數(shù)據(jù)庫容量已經(jīng)使用滿，而另一臺還剩下 30%+ 的容量。

該方案并不是一定不行，而是我們在采用的時候，要綜合分片鍵的樣本規(guī)則，選取的分片鍵前綴位數(shù)，庫數(shù)量，表數(shù)量，四個變量對最終的偏斜率都有影響。

例如上述例子中，如果不是 16 庫 100 表，而是 8 庫 100 表，或者 20 庫 100 表，數(shù)據(jù)偏斜率都能降低到了 5% 以下的可接受范圍。

所以該方案的隱藏的"坑"較多，我們不僅要估算上線初期的偏斜率，還需要測算若干次翻倍擴容后的數(shù)據(jù)偏斜率。

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

常用姿勢四：剔除公因數(shù)法

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

那么我們是不是可以有辦法去除掉公因數(shù)的影響呢?下面為一個可以考慮的實現(xiàn)案例：

public static ShardCfg shard(String userId) { 
        int dbIdx = Math.abs(userId.hashCode() % DB_CNT); 
        // 計算表序號時先剔除掉公約數(shù)的影響 
        int tblIdx = Math.abs((userId.hashCode() / TBL_CNT) % TBL_CNT); 
        return new ShardCfg(dbIdx, tblIdx); 
} 

經(jīng)過測算，該方案的最大數(shù)據(jù)偏斜度也比較小，針對不少業(yè)務(wù)從 N 庫 1 表升級到 N 庫 M 表下，需要維護庫序號不變的場景下可以考慮。

常用姿勢五：一致性 Hash 法

一致性 Hash 算法也是一種比較流行的集群數(shù)據(jù)分區(qū)算法，比如 RedisCluster 即是通過一致性 Hash 算法，使用 16384 個虛擬槽節(jié)點進行每個分片數(shù)據(jù)的管理。

關(guān)于一致性 Hash 的具體原理這邊不再重復(fù)描述，讀者可以自行翻閱資料。這邊詳細介紹如何使用一致性 Hash 進行分庫分表的設(shè)計。

我們通常會將每個實際節(jié)點的配置持久化在一個配置項或者是數(shù)據(jù)庫中，應(yīng)用啟動時或者是進行切換操作的時候會去加載配置。

配置一般包括一個[StartKey，Endkey)的左閉右開區(qū)間和一個數(shù)據(jù)庫節(jié)點信息，例如：

示例代碼：

private TreeMap<Long, Integer> nodeTreeMap = new TreeMap<>(); 
 
@Override 
public void afterPropertiesSet() { 
    // 啟動時加載分區(qū)配置 
    List<HashCfg> 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); 
    return new ShardCfg(dbIdx, tblIdx); 
} 

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

正規(guī)的一致性 Hash 算法會引入虛擬節(jié)點，每個虛擬節(jié)點會指向一個真實的物理節(jié)點。

這樣設(shè)計方案主要是能夠在加入新節(jié)點后的時候，可以有方案保證每個節(jié)點遷移的數(shù)據(jù)量級和遷移后每個節(jié)點的壓力保持幾乎均等。

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

主要有以下原因：

• 應(yīng)用程序需要花費額外的耗時和內(nèi)存來加載虛擬節(jié)點的配置信息。如果虛擬節(jié)點較多，內(nèi)存的占用也會有些不太樂觀。
• 由于 MySQL 有非常完善的主從復(fù)制方案，與其通過從各個虛擬節(jié)點中篩選需要遷移的范圍數(shù)據(jù)進行遷移，不如通過從庫升級方式處理后再刪除冗余數(shù)據(jù)簡單可控。
• 虛擬節(jié)點主要解決的痛點是節(jié)點數(shù)據(jù)搬遷過程中各個節(jié)點的負載不均衡問題，通過虛擬節(jié)點打散到各個節(jié)點中均攤壓力進行處理。

而作為 OLTP 數(shù)據(jù)庫，我們很少需要突然將某個數(shù)據(jù)庫下線，新增節(jié)點后一般也不會從 0 開始從其他節(jié)點搬遷數(shù)據(jù)，而是前置準備好大部分數(shù)據(jù)的方式，故一般來說沒有必要引入虛擬節(jié)點來增加復(fù)雜度。

常見擴容方案

①翻倍擴容法

翻倍擴容法的主要思維是每次擴容，庫的數(shù)量均翻倍處理，而翻倍的數(shù)據(jù)源通常是由原數(shù)據(jù)源通過主從復(fù)制方式得到的從庫升級成主庫提供服務(wù)的方式。故有些文檔將其稱作"從庫升級法"。

理論上，經(jīng)過翻倍擴容法后，我們會多一倍的數(shù)據(jù)庫用來存儲數(shù)據(jù)和應(yīng)對流量，原先數(shù)據(jù)庫的磁盤使用量也將得到一半空間的釋放。

如下圖所示：

具體的流程大致如下：

時間點 t1：為每個節(jié)點都新增從庫，開啟主從同步進行數(shù)據(jù)同步。

時間點 t2：主從同步完成后，對主庫進行禁寫。

此處禁寫主要是為了保證數(shù)據(jù)的正確性。若不進行禁寫操作，在以下兩個時間窗口期內(nèi)將出現(xiàn)數(shù)據(jù)不一致的問題：

• 斷開主從后，若主庫不禁寫，主庫若還有數(shù)據(jù)寫入，這部分數(shù)據(jù)將無法同步到從庫中。
• 應(yīng)用集群識別到分庫數(shù)翻倍的時間點無法嚴格一致，在某個時間點可能兩臺應(yīng)用使用不同的分庫數(shù)，運算到不同的庫序號，導(dǎo)致錯誤寫入。

時間點 t3：同步完全完成后，斷開主從關(guān)系，理論上此時從庫和主庫有著完全一樣的數(shù)據(jù)集。

時間點t4：從庫升級為集群節(jié)點，業(yè)務(wù)應(yīng)用識別到新的分庫數(shù)后，將應(yīng)用新的路由算法。

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

這里需要注意的是，業(yè)務(wù)應(yīng)用接收到新的配置的時間點不一定一致，所以必定存在一個時間窗口期，該期間部分機器使用原分庫數(shù)，部分節(jié)點使用新分庫數(shù)。這也正是我們的禁寫操作一定要在此步完成后才能放開的原因。

時間點 t5：確定所有的應(yīng)用均接受到庫總數(shù)的配置后，放開原主庫的禁寫操作，此時應(yīng)用完全恢復(fù)服務(wù)。

啟動離線的定時任務(wù)，清除各庫中的約一半冗余數(shù)據(jù)。

為了節(jié)省磁盤的使用率，我們可以選擇離線定時任務(wù)清除冗余的數(shù)據(jù)。也可以在業(yè)務(wù)初期表結(jié)構(gòu)設(shè)計的時候，將索引鍵的 Hash 值存為一個字段。

那么以上述常用姿勢四為例，我們離線的清除任務(wù)可以簡單的通過 sql 即可實現(xiàn)(需要防止鎖住全表，可以拆分成若干個 id 范圍的子 sql 執(zhí)行)：

delete from db0.tbl0 where hash_val mod 4 <> 0;  
delete from db1.tbl0 where hash_val mod 4 <> 1; 
delete from db2.tbl0 where hash_val mod 4 <> 2; 
delete from db3.tbl0 where hash_val mod 4 <> 3; 

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

總結(jié)：通過上述遷移方案可以看出，從時間點 t2 到 t5 時間窗口呢內(nèi)，需要對數(shù)據(jù)庫禁寫，相當于是該時間范圍內(nèi)服務(wù)器是部分有損的，該階段整體耗時差不多是在分鐘級范圍內(nèi)。若業(yè)務(wù)可以接受，可以在業(yè)務(wù)低峰期進行該操作。

當然也會有不少應(yīng)用無法容忍分鐘級寫入不可用，例如寫操作遠遠大于讀操作的應(yīng)用，此時可以結(jié)合 canel 開源框架進行窗口期內(nèi)數(shù)據(jù)雙寫操作以保證數(shù)據(jù)的一致性。

該方案主要借助于 MySQL 強大完善的主從同步機制，能在事前提前準備好新的節(jié)點中大部分需要的數(shù)據(jù)，節(jié)省大量的人為數(shù)據(jù)遷移操作。

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

②一致性 Hash 擴容

我們主要還是看下不帶虛擬槽的一致性 Hash 擴容方法，假如當前數(shù)據(jù)庫節(jié)點 DB0 負載或磁盤使用過大需要擴容，我們通過擴容可以達到例如下圖的效果。

下圖中，擴容前配置了三個 Hash 分段，發(fā)現(xiàn)[-Inf，-10000)范圍內(nèi)的的數(shù)據(jù)量過大或者壓力過高時，需要對其進行擴容。

主要步驟如下：

• 時間點 t1：針對需要擴容的數(shù)據(jù)庫節(jié)點增加從節(jié)點，開啟主從同步進行數(shù)據(jù)同步。
• 時間點 t2：完成主從同步后，對原主庫進行禁寫。此處原因和翻倍擴容法類似，需要保證新的從庫和原來主庫中數(shù)據(jù)的一致性。
• 時間點 t3：同步完全完成后，斷開主從關(guān)系，理論上此時從庫和主庫有著完全一樣的數(shù)據(jù)集。
• 時間點 t4：修改一致性 Hash 范圍的配置，并使應(yīng)用服務(wù)重新讀取并生效。
• 時間點 t5：確定所有的應(yīng)用均接受到新的一致性 Hash 范圍配置后，放開原主庫的禁寫操作，此時應(yīng)用完全恢復(fù)服務(wù)。

啟動離線的定時任務(wù)，清除冗余數(shù)據(jù)。

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

小結(jié)

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

我們在進行分庫分表設(shè)計時，可以選擇例如范圍分表，Hash 分表，路由表，或者一致性 Hash 分表等各種方案。進行選擇時需要充分考慮到后續(xù)的擴容可持續(xù)性，最大數(shù)據(jù)偏斜率等因素。

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

我們在實際進行選擇時，一定要考慮自身的業(yè)務(wù)特點，充分驗證分片鍵在各個參數(shù)因子下的數(shù)據(jù)偏斜程度，并提前規(guī)劃考慮好后續(xù)擴容的方案。

作者：Han Lei

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號vivo互聯(lián)網(wǎng)技術(shù)(ID：vivoVMIC)