一、前言

中大型項目中，一旦遇到數據量比較大，小夥伴應該都知道就應該對數據進行拆分了。有垂直和水平兩種。

垂直拆分比較簡單，也就是本來一個數據庫，數據量大之後，從業務角度進行拆分多個庫。如下圖，獨立的拆分出訂單庫和用戶庫。

水平拆分的概念，是同一個業務數據量大之後，進行水平拆分。

上圖中訂單數據達到了 4000 萬，我們也知道 mysql 單表存儲量推薦是百萬級，如果不進行處理，mysql 單表數據太大，會導致性能變慢。使用方案可以參考數據進行水平拆分。把 4000 萬數據拆分 4 張表或者更多。當然也可以分庫，再分表；把壓力從數據庫層級分開。

二、分庫分表方案

分庫分表方案中有常用的方案，hash 取模和 range 範圍方案；分庫分表方案最主要就是路由算法，把路由的 key 按照指定的算法進行路由存放。下邊來介紹一下兩個方案的特點。

1、hash 取模方案

在我們設計系統之前，可以先預估一下大概這幾年的訂單量，如：4000 萬。每張表我們可以容納 1000 萬，也我們可以設計 4 張表進行存儲。

那具體如何路由存儲的呢？hash 的方案就是對指定的路由 key（如：id）對分表總數進行取模，上圖中，id=12 的訂單，對 4 進行取模，也就是會得到 0，那此訂單會放到 0 表中。id=13 的訂單，取模得到爲 1，就會放到 1 表中。爲什麼對 4 取模，是因爲分表總數是 4。

• 優點：

訂單數據可以均勻的放到那 4 張表中，這樣此訂單進行操作時，就不會有熱點問題。

熱點的含義：熱點的意思就是對訂單進行操作集中到 1 個表中，其他表的操作很少。

訂單有個特點就是時間屬性，一般用戶操作訂單數據，都會集中到這段時間產生的訂單。如果這段時間產生的訂單 都在同一張訂單表中，那就會形成熱點，那張表的壓力會比較大。

• 缺點：

將來的數據遷移和擴容，會很難。

如：業務發展很好，訂單量很大，超出了 4000 萬的量，那我們就需要增加分表數。如果我們增加 4 個表

一旦我們增加了分表的總數，取模的基數就會變成 8，以前 id=12 的訂單按照此方案就會到 4 表中查詢，但之前的此訂單時在 0 表的，這樣就導致了數據查不到。就是因爲取模的基數產生了變化。

遇到這個情況，我們小夥伴想到的方案就是做數據遷移，把之前的 4000 萬數據，重新做一個 hash 方案，放到新的規劃分表中。也就是我們要做數據遷移。這個是很痛苦的事情。有些小公司可以接受晚上停機遷移，但大公司是不允許停機做數據遷移的。

當然做數據遷移可以結合自己的公司的業務，做一個工具進行，不過也帶來了很多工作量，每次擴容都要做數據遷移

那有沒有不需要做數據遷移的方案呢，我們看下面的方案

2、range 範圍方案

range 方案也就是以範圍進行拆分數據。

range 方案比較簡單，就是把一定範圍內的訂單，存放到一個表中；如上圖 id=12 放到 0 表中，id=1300 萬的放到 1 表中。設計這個方案時就是前期把表的範圍設計好。通過 id 進行路由存放。

• 優點

我們小夥伴們想一下，此方案是不是有利於將來的擴容，不需要做數據遷移。即時再增加 4 張表，之前的 4 張表的範圍不需要改變，id=12 的還是在 0 表，id=1300 萬的還是在 1 表，新增的 4 張表他們的範圍肯定是 大於 4000 萬之後的範圍劃分的。

• 缺點

有熱點問題，我們想一下，因爲 id 的值會一直遞增變大，那這段時間的訂單是不是會一直在某一張表中，如 id=1000 萬 ～ id=2000 萬之間，這段時間產生的訂單是不是都會集中到此張表中，這個就導致 1 表過熱，壓力過大，而其他的表沒有什麼壓力。

3、總結：

hash 取模方案：沒有熱點問題，但擴容遷移數據痛苦

range 方案：不需要遷移數據，但有熱點問題。

那有什麼方案可以做到兩者的優點結合呢？，即不需要遷移數據，又能解決數據熱點的問題呢？

其實還有一個現實需求，能否根據服務器的性能以及存儲高低，適當均勻調整存儲呢？

三、方案思路

hash 是可以解決數據均勻的問題，range 可以解決數據遷移問題，那我們可以不可以兩者相結合呢？利用這兩者的特性呢？

我們考慮一下數據的擴容代表着，路由 key（如 id）的值變大了，這個是一定的，那我們先保證數據變大的時候，首先用 range 方案讓數據落地到一個範圍裏面。這樣以後 id 再變大，那以前的數據是不需要遷移的。

但又要考慮到數據均勻，那是不是可以在一定的範圍內數據均勻的呢？因爲我們每次的擴容肯定會事先設計好這次擴容的範圍大小，我們只要保證這次的範圍內的數據均勻是不是就 ok 了。

四、方案設計

我們先定義一個 group 組概念，這組裏麪包含了一些分庫以及分表，如下圖

上圖有幾個關鍵點：

1）id=0～4000 萬肯定落到 group01 組中

2）group01 組有 3 個 DB，那一個 id 如何路由到哪個 DB？

3）根據 hash 取模定位 DB，那模數爲多少？模數要爲所有此 group 組 DB 中的表數，上圖總表數爲 10。爲什麼要去表的總數？而不是 DB 總數 3 呢？

4）如 id=12，id%10=2；那值爲 2，落到哪個 DB 庫呢？這是設計是前期設定好的，那怎麼設定的呢？

5）一旦設計定位哪個 DB 後，就需要確定落到 DB 中的哪張表呢？

五、核心主流程

按照上面的流程，我們就可以根據此規則，定位一個 id，我們看看有沒有避免熱點問題。

我們看一下，id 在【0，1000 萬】範圍內的，根據上面的流程設計，1000 萬以內的 id 都均勻的分配到 DB_0,DB_1,DB_2 三個數據庫中的 Table_0 表中，爲什麼可以均勻，因爲我們用了 hash 的方案，對 10 進行取模。

上面我們也提了疑問，爲什麼對錶的總數 10 取模，而不是 DB 的總數 3 進行取模？我們看一下爲什麼 DB_0 是 4 張表，其他兩個 DB_1 是 3 張表？

在我們安排服務器時，有些服務器的性能高，存儲高，就可以安排多存放些數據，有些性能低的就少放點數據。如果我們取模是按照 DB 總數 3，進行取模，那就代表着【0，4000 萬】的數據是平均分配到 3 個 DB 中的，那就不能夠實現按照服務器能力適當分配了。

按照 Table 總數 10 就能夠達到，看如何達到

上圖中我們對 10 進行取模，如果值爲【0，1，2，3】就路由到 DB_0，【4，5，6】路由到 DB_1，【7，8，9】路由到 DB_2。現在小夥伴們有沒有理解，這樣的設計就可以把多一點的數據放到 DB_0 中，其他 2 個 DB 數據量就可以少一點。DB_0 承擔了 4/10 的數據量，DB_1 承擔了 3/10 的數據量，DB_2 也承擔了 3/10 的數據量。整個 Group01 承擔了【0，4000 萬】的數據量。

注意：小夥伴千萬不要被 DB_1 或 DB_2 中 table 的範圍也是 0～4000 萬疑惑了，這個是範圍區間，也就是 id 在哪些範圍內，落地到哪個表而已。

上面一大段的介紹，就解決了熱點的問題，以及可以按照服務器指標，設計數據量的分配。

六、如何擴容

其實上面設計思路理解了，擴容就已經出來了；那就是擴容的時候再設計一個 group02 組，定義好此 group 的數據範圍就 ok 了。

因爲是新增的一個 group01 組，所以就沒有什麼數據遷移概念，完全是新增的 group 組，而且這個 group 組照樣就防止了熱點，也就是【4000 萬，5500 萬】的數據，都均勻分配到三個 DB 的 table_0 表中，【5500 萬～7000 萬】數據均勻分配到 table_1 表中。

七、系統設計

思路確定了，設計是比較簡單的，就 3 張表，把 group，DB，table 之間建立好關聯關係就行了。

group 和 DB 的關係

table 和 db 的關係

上面的表關聯其實是比較簡單的，只要原理思路理順了，就 ok 了。小夥伴們在開發的時候不要每次都去查詢三張關聯表，可以保存到緩存中（本地 jvm 緩存），這樣不會影響性能。

一旦需要擴容，小夥伴是不是要增加一下 group02 關聯關係，那應用服務需要重新啓動嗎？

簡單點的話，就凌晨配置，重啓應用服務就行了。但如果是大型公司，是不允許的，因爲凌晨也有訂單的。那怎麼辦呢？本地 jvm 緩存怎麼更新呢？

其實方案也很多，可以使用用 zookeeper，也可以使用分佈式配置，這裏是比較推薦使用分佈式配置中心的，可以將這些數據配置到分佈式配置中心去，對分佈式配置中心不瞭解的，可以看下《三種主流的微服務配置中心深度對比！你怎麼看！》

到此爲止，整體的方案介紹結束，希望對小夥伴們有所幫助。謝謝！！！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/kBB2WOZ4AmOSsfwZVpg-yw