分庫分表？如何作到永不遷移數據和避免熱點？ (轉)

1、前言

---

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

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

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

 

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

 

2、分庫分表方案 

---

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

一、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方案，放到新的規劃分表中。也就是咱們要作數據遷移。這個是很痛苦的事情。有些小公司能夠接受晚上停機遷移，但大公司是不容許停機作數據遷移的。

固然作數據遷移能夠結合本身的公司的業務，作一個工具進行，不過也帶來了不少工做量，每次擴容都要作數據遷移

　　那有沒有不須要作數據遷移的方案呢，咱們看下面的方案

二、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方案：不須要遷移數據，但有熱點問題。

那有什麼方案能夠作到二者的優勢結合呢？，即不須要遷移數據，又能解決數據熱點的問題呢？

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

 

3、方案思路

---

　　 hash是能夠解決數據均勻的問題，range能夠解決數據遷移問題，那咱們能夠不能夠二者相結合呢？利用這二者的特性呢？

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

　　但又要考慮到數據均勻，那是否是能夠在必定的範圍內數據均勻的呢？由於咱們每次的擴容確定會事先設計好此次擴容的範圍大小，咱們只要保證此次的範圍內的數據均勻是否是就ok了。

 

 4、方案設計

---

 咱們先定義一個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中的哪張表呢？

 

5、核心主流程

---

 

 

　　按照上面的流程，咱們就能夠根據此規則，定位一個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在哪些範圍內，落地到哪一個表而已。

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

 

6、如何擴容

---

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

 

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

 

7、系統設計

---

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

　　　　　　　　　　　　　　　　group和DB的關係

 

　　　　　　　　　　　　　　　　　　table和db的關係

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

　　一旦須要擴容，小夥伴是否是要增長一下group02關聯關係，那應用服務須要從新啓動嗎？

　　簡單點的話，就凌晨配置，重啓應用服務就好了。但若是是大型公司，是不容許的，由於凌晨也有訂單的。那怎麼辦呢？本地jvm緩存怎麼更新呢？

　　其實方案也不少，可使用用zookeeper，也可使用分佈式配置，這裏是比較推薦使用分佈式配置中心的，能夠將這些數據配置到分佈式配置中心去

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

這邊隱含了一個關鍵點，那就是路由key（如：id）的值是很是關鍵的，要求必定是有序的，自增的，這個就涉及到分佈式惟一id的方案.

 

 

出處：https://mp.weixin.qq.com/s/pGcDXG6kS3U86HZz7K5fgg

 

簡略版分析分庫分表：

分庫分表，作到永不遷移數據和避免熱點的方法：
    基礎：
      1、數據拆分方式：垂直拆分，水平拆分。
      2、垂直拆分：原來就一個數據庫，數據量一大了，就拆分爲多個數據庫。
      3、水平拆分：原來是t_order表，拆分紅t_order_一、t_order_二、t_order_三、t_order_4。
      4、Mysql單表存儲推薦是百萬級，儘可能別到千萬級。
    分庫分表方案：
      1、經常使用的方案：hash取模、range範圍方案，分庫分表方案最主要的就是路由算法，把路由的key按照指定的算法進行路由存放。        
      2、hash取模方案（無熱點問題，擴容困難）
          （一）、首先預估一下總數據量m，設定每張表的最大數據量n，m/n=z 是表個數。
          （二）、hash方案就是對指定的路由key（如：id）對z進行取模，"t_order_"+id%z 是表名字。
          （三）、優缺點：優勢是數據均勻的分佈在每張表中，不會有熱點問題；缺點是數據的遷移或者擴容會很麻煩。
      3、range範圍方案（不須要遷移數據，有熱點問題）
          （一）、range方案是以範圍進行數據拆分：id=50在0~1000的在t_order_0表、id=1050在1000～2000的t_order_1表等。
          （二）、優缺點：優勢是擴容方便，不須要數據遷移；缺點是id在0-1000時，t_order_0會很忙，t_order_1，t_order_2...t_order_n...都沒有數據的訪問，一段時間只有一個熱點表。
      4、range和hash組合方案
          （一）、設計是比較簡單的，就三張表，把group，db,table之間創建好關聯關係。
          group表字段：group_id,group_name,start_id,end_id
          db表字段：db_id,db_name,group_id,hash_value
          group和db的關係表字段：table_id,table_name,db_id,start_id,end_id
          
  分庫分表就會帶來各類join組合條件的分頁查詢問題，怎樣解決分頁查詢問題，頗有挑戰性。   
  
  1.事務問題：
    (1)、分佈式事務 （2）、經過應用程序與數據庫共同控制實現事務
          方案一：使用分佈式事務
              優勢：交由數據庫管理，簡單有效
              缺點：性能代價高，特別是shard（分片）愈來愈多時
          方案二：由應用程序和數據庫共同控制
               原理：將一個跨多個數據庫的分佈式事務分拆成多個僅處
                     於單個數據庫上面的小事務，並經過應用程序來總控
                     各個小事務。
               優勢：性能上有優點
               缺點：須要應用程序在事務控制上作靈活設計。若是使用  
                     了spring的事務管理，改動起來會面臨必定的困難。
  2.跨節點Join的問題
       只要是進行切分，跨節點Join的問題是不可避免的。可是良好的設計和切分卻能夠減小此類狀況的發生。解決這一問題的廣泛作法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求獲得關聯數據。

  3.跨節點的count,order by,group by以及聚合函數問題
  
  解決方案：與解決跨節點join問題的相似，分別在各個節點上獲得結果後在應用程序端進行合併。和join不一樣的是每一個結點的查詢能夠並行執行，所以不少時候它的速度要比單一大表快不少。但若是結果集很大，對應用程序內存的消耗是一個問題。