0 Github
1 面試題
設計可動態(tài)擴容的分庫分表
2 考點分析
- 選一個數(shù)據(jù)庫中間件,然后深入之
- 設計分庫分表的方案，要分成多少個庫，每個庫分成多少個表
- 基于已選的數(shù)據(jù)庫中間件，以及在測試環(huán)境建立好的分庫分表，??能否正常執(zhí)行分庫分表的讀寫
- 完成單庫單表到分庫分表的遷移(使用上一文提到的雙寫方案)
- 線上系統(tǒng),開始基于分庫分表對外服務
突然! 擴容了，擴容成6個庫，每個庫需要12個表，你怎么來增加更多庫和表呢？
這個你必須面對的事，就是當你已經(jīng)弄好分庫分表方案，測試也通過了，數(shù)據(jù)能均勻分布到各個庫和表里去，而且接著你還通過雙寫方案上了系統(tǒng)，已經(jīng)直接基于分庫分表方案在搞了。
需求來了~現(xiàn)在這些庫和表又支撐不住了，要繼續(xù)擴容,咋辦？
這個可能就是每個庫的容量又快滿了，或者表數(shù)據(jù)量又太大了，也可能每個庫的寫并發(fā)太高了，得繼續(xù)擴容!
3 停機擴容(不推薦)
這就跟停機遷移一樣，步驟幾乎一致，唯一不同是導數(shù)的工具，是把現(xiàn)有庫表的數(shù)據(jù)抽出來慢慢導入到新的庫和表里去。但是最好別這樣，有點不太靠譜，既然分庫分表,就說明數(shù)據(jù)量實在太大了,你這么玩，可能會出問題!
從單庫單表遷移到分庫分表時，數(shù)據(jù)量并不是很大，單表最大也就兩三千萬
寫個工具，多弄幾臺機器并行跑，1小時數(shù)據(jù)就導完了
但如果是:3個庫+12個表
跑了一段時間了，數(shù)據(jù)量都1億~2億了
光是導2億數(shù)據(jù)，都要導個幾個小時，6點，剛剛導完數(shù)據(jù)，還要搞后續(xù)的修改配置，重啟系統(tǒng)，測試驗證，10點才可以搞完!
4 優(yōu)化方案
一開始上來就是32個庫，每個庫32個表，1024張表
這個分法
- 基本上國內(nèi)的互聯(lián)網(wǎng)肯定都夠用
- 無論并發(fā)支撐還是數(shù)據(jù)量支撐都沒問題
每個庫正常承載的寫入并發(fā)量是1000，那么32個庫就可以承載32 * 1000 = 32000的寫并發(fā)
如果每個庫承載1500的寫并發(fā)，32 * 1500 = 48000的寫并發(fā)，接近5萬/s的寫入并發(fā)
前面再加個MQ，削峰，每秒寫入MQ 8萬條數(shù)據(jù)，每秒消費5萬條數(shù)據(jù)
1024張表，假設每個表放500萬數(shù)據(jù)，在MySQL里可以放50億條數(shù)據(jù)
每秒的5萬寫并發(fā)，總共50億條數(shù)據(jù)，對于國內(nèi)大部分互聯(lián)網(wǎng)公司來說都夠了
談分庫分表的擴容，第一次分庫分表，就一次性給他分個夠
32個庫，1024張表，對大部分的中小型互聯(lián)網(wǎng)公司來說，已經(jīng)可以支撐好幾年
一個實踐是利用32 * 32來分庫分表，即分為32個庫，每個庫里一個表分為32張表,一共就是1024張表
根據(jù)某個id先根據(jù)32取模路由到庫，再根據(jù)32取模路由到庫里的表。
剛開始的時候，這個庫可能就是邏輯庫，建在一個數(shù)據(jù)庫上的
也就是一個MySQL服務器可能建了n個庫,后面如果要拆分，就不斷在庫和MySQL服務器之間做遷移就可以了。然后系統(tǒng)配合改一下配置即可。
比如說最多可以擴展到32個數(shù)據(jù)庫服務器，每個數(shù)據(jù)庫服務器是一個庫。如果還是不夠？
最多可以擴展到1024個數(shù)據(jù)庫服務器，每個數(shù)據(jù)庫服務器上面一個庫一個表。因為最多是1024個表
這么搞，是不用自己寫代碼做數(shù)據(jù)遷移的，都交給DBA來搞好了，但是DBA確實需要做一些庫表遷移的工作，總比你自己寫代碼，抽數(shù)據(jù)導數(shù)據(jù)來的效率高得多
哪怕是要減少庫的數(shù)量，也很簡單，按倍數(shù)縮容就可以了，然后修改一下路由規(guī)則。
5 總結
5.1 確定方案
幾臺數(shù)據(jù)庫服務器,每臺服務器上幾個庫，每個庫多少個表，推薦是32庫 * 32表，對于大部分公司來說，可能幾年都夠了
5.2 路由規(guī)則
orderId 模 32 = 庫，orderId / 32 模 32 = 表
5.3 擴容
當擴容時,申請增加更多的數(shù)據(jù)庫服務器，裝好MySQL，倍數(shù)擴容，4臺服務器，擴到8臺服務器，16臺服務器
5.4 遷移
由DBA負責將原先數(shù)據(jù)庫服務器的庫，遷移到新的數(shù)據(jù)庫服務器上去，很多工具，庫遷移，比較便捷
5.5 配置
我們這邊就是修改一下配置，調整遷移的庫所在數(shù)據(jù)庫服務器的地址
5.6 發(fā)布
重新發(fā)布系統(tǒng)，上線，原先的路由規(guī)則變都不用變，直接可以基于2倍的數(shù)據(jù)庫服務器的資源，繼續(xù)進行線上系統(tǒng)的提供服務
-
分庫分表擴容方案image
參考
- 《Java工程師面試突擊第1季-中華石杉老師》
