分庫分表之終極設計方案

一 前言

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

垂直拆分

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

水平拆分

是同一個業務數據量大以後，進行水平拆分

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

二 傳統分庫分表設計方案

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

2.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.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表過熱，壓力過大，而其餘的表沒有什麼壓力。 

總結

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了。在開發的時候不要每次都去查詢三張關聯表，能夠保存到緩存中，這樣不會影響性能。

'''
這邊隱含了一個關鍵點，那就是路由key（如：id）的值是很是關鍵的，要求必定是有序的，自增的
'''