作者 | 老顧聊技術
鏈接 | www.toutiao.com/i6677459303055491597
中大型專案中，一旦遇到資料量比較大，小伙伴應該都知道就應該對資料進行拆分了，有垂直和水平兩種，
垂直拆分比較簡單，也就是本來一個資料庫，資料量大之后，從業務角度進行拆分多個庫，如下圖，獨立的拆分出訂單庫和用戶庫，
水平拆分的概念，是同一個業務資料量大之后，進行水平拆分，
上圖中訂單資料達到了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，也可以使用分布式配置，這里是比較推薦使用分布式配置中心的，可以將這些資料配置到分布式配置中心去，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了，試試策略模式，真香！！
3.臥槽！Java 中的 xx ≠ null 是什么新語法？
4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/333223.html
標籤：Java
上一篇：移動docker資料檔案到nas共享盤、釋放C盤空間
下一篇：常見的垃圾回收演算法及細節實作