如何設計可以動态擴容縮容的分庫分表方案?
(1)選擇一個資料庫中間件,調研、學習、測試
(2)設計你的分庫分表的一個方案,你要分成多少個庫,每個庫分成多少個表,3個庫每個庫4個表
(3)基于選擇好的資料庫中間件,以及在測試環境建立好的分庫分表的環境,然後測試一下能否正常進行分庫分表的讀寫
(4)完成單庫單表到分庫分表的遷移,雙寫方案
(5)線上系統開始基于分庫分表對外提供服務
(6)擴容了,擴容成6個庫,每個庫需要12個表,你怎麼來增加更多庫和表呢?
這個是你必須面對的一個事兒,就是你已經弄好分庫分表方案了,然後一堆庫和表都建好了,基于分庫分表中間件的代碼開發啥的都好了,測試都ok了,資料能均勻分布到各個庫和各個表裡去,而且接着你還通過雙寫的方案咔嚓一下上了系統,已經直接基于分庫分表方案在搞了。
那麼現在問題來了,你現在這些庫和表又支撐不住了,要繼續擴容咋辦?這個可能就是說你的每個庫的容量又快滿了,或者是你的表資料量又太大了,也可能是你每個庫的寫并發太高了,你得繼續擴容。
這都是玩兒分庫分表線上必須經曆的事兒
剖析
(1)停機擴容
這個方案就跟停機遷移一樣,步驟幾乎一緻,唯一的一點就是那個導數的工具,是把現有庫表的資料抽出來慢慢倒入到新的庫和表裡去。但是最好别這麼玩兒,有點不太靠譜,因為既然分庫分表就說明資料量實在是太大了,可能多達幾億條,甚至幾十億,你這麼玩兒,可能會出問題。
從單庫單表遷移到分庫分表的時候,資料量并不是很大,單表最大也就兩三千萬
寫個工具,多弄幾台機器并行跑,1小時資料就導完了
3個庫+12個表,跑了一段時間了,資料量都1億~2億了。光是導2億資料,都要導個幾個小時,6點,剛剛導完資料,還要搞後續的修改配置,重新開機系統,測試驗證,10點才可以搞完
(2)優化後的方案
一開始上來就是32個庫,每個庫32個表,1024張表 (設計前期就搞好)
我可以告訴各位同學說,這個分法,第一,基本上國内的網際網路肯定都是夠用了,第二,無論是并發支撐還是資料量支撐都沒問題
每個庫正常承載的寫入并發量是1000,那麼32個庫就可以承載32 * 1000 = 32000的寫并發,如果每個庫承載1500的寫并發,32 * 1500 = 48000的寫并發,接近5萬/s的寫入并發,前面再加一個MQ,削峰,每秒寫入MQ 8萬條資料,每秒消費5萬條資料。
有些除非是國内排名非常靠前的這些公司,他們的最核心的系統的資料庫,可能會出現幾百台資料庫的這麼一個規模,128個庫,256個庫,512個庫
1024張表,假設每個表放500萬資料,在MySQL裡可以放50億條資料
每秒的5萬寫并發,總共50億條資料,對于國内大部分的網際網路公司來說,其實一般來說都夠了
談分庫分表的擴容,第一次分庫分表,就一次性給他分個夠,32個庫,1024張表,可能對大部分的中小型網際網路公司來說,已經可以支撐好幾年了
一個實踐是利用32 * 32來分庫分表,即分為32個庫,每個庫裡一個表分為32張表。一共就是1024張表。根據某個id先根據32取模路由到庫,再根據32取模路由到庫裡的表。
剛開始的時候,這個庫可能就是邏輯庫,建在一個資料庫上的,就是一個mysql伺服器可能建了n個庫,比如16個庫。後面如果要拆分,就是不斷在庫和mysql伺服器之間做遷移就可以了。然後系統配合改一下配置即可。
比如說最多可以擴充到32個資料庫伺服器,每個資料庫伺服器是一個庫。如果還是不夠?最多可以擴充到1024個資料庫伺服器,每個資料庫伺服器上面一個庫一個表。因為最多是1024個表麼。
這麼搞,是不用自己寫代碼做資料遷移的,都交給dba來搞好了,但是dba确實是需要做一些庫表遷移的工作,但是總比你自己寫代碼,抽資料導資料來的效率高得多了。
哪怕是要減少庫的數量,也很簡單,其實說白了就是按倍數縮容就可以了,然後修改一下路由規則。
對2 ^ n取模
orderId 模 32 = 庫
orderId / 32 模 32 = 表
259 3 8
1189 5 5
352 0 11
4593 17 15
1、設定好幾台資料庫伺服器,每台伺服器上幾個庫,每個庫多少個表,推薦是32庫 * 32表,對于大部分公司來說,可能幾年都夠了
2、路由的規則,orderId 模 32 = 庫,orderId / 32 模 32 = 表
3、擴容的時候,申請增加更多的資料庫伺服器,裝好mysql,倍數擴容,4台伺服器,擴到8台伺服器,16台伺服器
4、由dba負責将原先資料庫伺服器的庫,遷移到新的資料庫伺服器上去,很多工具,庫遷移,比較便捷
5、我們這邊就是修改一下配置,調整遷移的庫所在資料庫伺服器的位址
6、重新釋出系統,上線,原先的路由規則變都不用變,直接可以基于2倍的資料庫伺服器的資源,繼續進行線上系統的提供服務