一、前言

中大型項目中，一旦遇到數(shù)據(jù)量比較大，小伙伴應(yīng)該都知道就應(yīng)該對數(shù)據(jù)進(jìn)行拆分了。有垂直和水平兩種。

垂直拆分比較簡單，也就是本來一個數(shù)據(jù)庫數(shù)據(jù)量大之后，從業(yè)務(wù)角度進(jìn)行拆分多個庫。如下圖，獨立的拆分出 訂單庫 和 用戶庫。

水平拆分的概念，是同一個業(yè)務(wù)數(shù)據(jù)量大之后，進(jìn)行水平拆分。

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

二、分庫分表方案

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

三、hash取模方案

在我們設(shè)計系統(tǒng)之前，可以先預(yù)估一下大概這幾年的訂單量，如:4000萬。每張表我們可以容納1000萬，也我們可以設(shè)計4張表進(jìn)行存儲。

• 優(yōu)點：

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

• 缺點：

將來的數(shù)據(jù)遷移和擴(kuò)容，會很難。

如:業(yè)務(wù)發(fā)展很好，訂單量很大，超出了4000萬的量，那我們就需要增加分表數(shù)。如果我們增加4個表。

那有沒有不需要做數(shù)據(jù)遷移的方案呢，我們看下面的方案。

四、range范圍方案

range方案也就是以范圍進(jìn)行拆分?jǐn)?shù)據(jù)。

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

• 優(yōu)點

我們小伙伴們想一下，此方案是不是有利于將來的擴(kuò)容，不需要做數(shù)據(jù)遷移。即時再增加4張表，之前的4張表的范圍不需要改變，id=12的還是在0表，id=1300萬的還是在1表，新增的4張表他們的范圍肯定是大于 4000萬之后的范圍劃分的。

• 缺點

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

五、小結(jié)

hash取模方案：沒有熱點問題，但擴(kuò)容遷移數(shù)據(jù)痛苦；

range方案：不需要遷移數(shù)據(jù)，但有熱點問題。

那有沒有一個方案，即不需要遷移數(shù)據(jù)，又能解決數(shù)據(jù)熱點的問題呢？有什么方案可以做到兩者的優(yōu)點結(jié)合呢？

其實還有一個現(xiàn)實需求，能否根據(jù)服務(wù)器的性能以及存儲高低，適當(dāng)均勻調(diào)整存儲呢？

六、方案思路

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

我們考慮一下數(shù)據(jù)的擴(kuò)容代表著，路由key(如id)的值變大了，這個是一定的，那我們先保證數(shù)據(jù)變大的時候，首先用range方案讓數(shù)據(jù)落地到一個范圍里面。這樣以后id再變大，那以前的數(shù)據(jù)是不需要遷移的。

但又要考慮到數(shù)據(jù)均勻，那是不是可以在一定的范圍內(nèi)數(shù)據(jù)均勻的呢？因為我們每次的擴(kuò)容肯定會事先設(shè)計好這次擴(kuò)容的范圍大小，我們只要保證這次的范圍內(nèi)的數(shù)據(jù)均勻是不是就ok了。

七、方案設(shè)計

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

上圖有幾個關(guān)鍵點：

1) id=0~4000萬肯定落到group01組中；

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

3) 根據(jù)hash取模定位DB，那模數(shù)為多少？模數(shù)要為所有此group組DB中的表數(shù)，上圖總表數(shù)為10。為什么要去表的總數(shù)？而不是DB總數(shù)3呢？

4) 如id=12，id%10=2;那值為2，落到哪個DB庫呢？這是設(shè)計是前期設(shè)定好的，那怎么設(shè)定的呢？

5) 一旦設(shè)計定位哪個DB后就需要確定落到DB中的哪張表呢？

八、核心主流程

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

我們看一下，id在【0，1000萬】范圍內(nèi)的，根據(jù)上面的流程設(shè)計，1000萬以內(nèi)的id都均勻的分配到DB 0,DB 1,DB 2三個數(shù)據(jù)庫中的Table_0表中，為什么可以均勻，因為我們用了hash的方案，對10進(jìn)行取模。

在我們安排服務(wù)器時，有些服務(wù)器的性能高，存儲高，就可以安排多存放些數(shù)據(jù)，有些性能低的就少放點數(shù)據(jù)。如果我們?nèi)∧Ｊ前凑誅B總數(shù)3，進(jìn)行取模，那就代表著【0，4000萬】的數(shù)據(jù)是平均分配到3個DB中的，那就不能夠?qū)崿F(xiàn)按照服務(wù)器能力適當(dāng)分配了。

按照Table總數(shù)10就能夠達(dá)到，看如何達(dá)到：

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

上面一大段的介紹，就解決了熱點的問題，以及可以按照服務(wù)器指標(biāo)，設(shè)計數(shù)據(jù)量的分配。

九、如何擴(kuò)容

其實上面設(shè)計思路理解了，擴(kuò)容就已經(jīng)出來了：那就是擴(kuò)容的時候再設(shè)計一個group02組，定義好此group的數(shù)據(jù)范圍就ok了。

因為是新增的一個group01組，所以就沒有什么數(shù)據(jù)遷移概念，完全是新增的group組，而且這個group組照樣就防止了熱點，也就是【4000萬，5500萬】的數(shù)據(jù)，都均勻分配到三個DB的table 0表中，【5500萬~7000萬】數(shù)據(jù)均勻分配到table 1表中。

十、系統(tǒng)設(shè)計

思路確定了，設(shè)計是比較簡單的，就3張表，把group，DB，table之間建立好關(guān)聯(lián)關(guān)系就行了。

group和DB的關(guān)系

table和db的關(guān)系

上面的表關(guān)聯(lián)其實是比較簡單的，只要原理思路理順了，就ok了。小伙伴們在開發(fā)的時候不要每次都去查詢?nèi)龔堦P(guān)聯(lián)表，可以保存到緩存中(本地jvm緩存)，這樣不會影響性能。

?

一旦需要擴(kuò)容，小伙伴是不是要增加一下group02關(guān)聯(lián)關(guān)系，那應(yīng)用服務(wù)需要重新啟動嗎？

簡單點的話，就凌晨配置，重啟應(yīng)用服務(wù)就行了。但如果是大型公司，是不允許的，因為凌晨也有訂單的。那怎么辦呢？本地ivm緩存怎么更新呢？

其實方案也很多，推薦用zookeeper，具體的小伙伴可以上網(wǎng)查詢，以后也會出文章介紹。

到此為止，整體的方案介紹結(jié)束，希望對小伙伴們有所幫助。謝謝?。?！

閱讀原文：https://mp.weixin.qq.com/s/82RGEMy1IN_LBkUSnc0qEg