面試題 如何設計可以動態擴容縮容的分庫分表方案?

2021-09-25 02:40:09 字數 2225 閱讀 5023

如何設計可以動態擴容縮容的分庫分表方案?

對於分庫分表來說,主要是面對以下問題:

這個是你必須面對的乙個事兒,就是你已經弄好分庫分表方案了,然後一堆庫和表都建好了,基於分庫分表中介軟體的**開發啥的都好了,測試都 ok 了,資料能均勻分布到各個庫和各個表裡去,而且接著你還通過雙寫的方案咔嚓一下上了系統,已經直接基於分庫分表方案在搞了。

那麼現在問題來了,你現在這些庫和表又支撐不住了,要繼續擴容咋辦?這個可能就是說你的每個庫的容量又快滿了,或者是你的表資料量又太大了,也可能是你每個庫的寫併發太高了,你得繼續擴容。

這都是玩兒分庫分表線上必須經歷的事兒。

這個方案就跟停機遷移一樣,步驟幾乎一致,唯一的一點就是那個導數的工具,是把現有庫表的資料抽出來慢慢倒入到新的庫和表裡去。但是最好別這麼玩兒,有點不太靠譜,因為既然分庫分表就說明資料量實在是太大了,可能多達幾億條,甚至幾十億,你這麼玩兒,可能會出問題。

從單庫單錶遷移到分庫分表的時候,資料量並不是很大,單錶最大也就兩三千萬。那麼你寫個工具,多弄幾台機器並行跑,1小時資料就導完了。這沒有問題。

如果 3 個庫 + 12 個表,跑了一段時間了,資料量都 1~2 億了。光是導 2 億資料,都要導個幾個小時,6 點,剛剛導完資料,還要搞後續的修改配置,重啟系統,測試驗證,10 點才可以搞完。所以不能這麼搞。

一開始上來就是 32 個庫,每個庫 32 個表,那麼總共是 1024 張表。

我可以告訴各位同學,這個分法,第一,基本上國內的網際網路肯定都是夠用了,第二,無論是併發支撐還是資料量支撐都沒問題。

每個庫正常承載的寫入併發量是 1000,那麼 32 個庫就可以承載 32 * 1000 = 32000 的寫併發,如果每個庫承載 1500 的寫併發,32 * 1500 = 48000 的寫併發,接近 5 萬每秒的寫入併發,前面再加乙個mq,削峰,每秒寫入 mq 8 萬條資料,每秒消費 5 萬條資料。

有些除非是國內排名非常靠前的這些公司,他們的最核心的系統的資料庫,可能會出現幾百台資料庫的這麼乙個規模,128 個庫,256 個庫,512 個庫。

1024 張表,假設每個表放 500 萬資料,在 mysql 裡可以放 50 億條資料。

每秒 5 萬的寫併發,總共 50 億條資料,對於國內大部分的網際網路公司來說,其實一般來說都夠了。

談分庫分表的擴容,第一次分庫分表,就一次性給他分個夠,32 個庫,1024 張表,可能對大部分的中小型網際網路公司來說,已經可以支撐好幾年了。

乙個實踐是利用32 * 32來分庫分表,即分為 32 個庫,每個庫里乙個表分為 32 張表。一共就是 1024 張表。根據某個 id 先根據 32 取模路由到庫,再根據 32 取模路由到庫里的表。

orderid

id % 32 (庫)

id / 32 % 32 (表)

2593

8118955

3520

114593

1715

剛開始的時候,這個庫可能就是邏輯庫,建在乙個資料庫上的,就是乙個 mysql 伺服器可能建了 n 個庫,比如 32 個庫。後面如果要拆分,就是不斷在庫和 mysql 伺服器之間做遷移就可以了。然後系統配合改一下配置即可。

比如說最多可以擴充套件到 32 個資料庫伺服器,每個資料庫伺服器是乙個庫。如果還是不夠?最多可以擴充套件到 1024 個資料庫伺服器,每個資料庫伺服器上面乙個庫乙個表。因為最多是 1024 個表。

這麼搞,是不用自己寫**做資料遷移的,都交給 dba 來搞好了,但是 dba 確實是需要做一些庫表遷移的工作,但是總比你自己寫**,然後抽資料導資料來的效率高得多吧。

哪怕是要減少庫的數量,也很簡單,其實說白了就是按倍數縮容就可以了,然後修改一下路由規則。

這裡對步驟做乙個總結:

設定好幾臺資料庫伺服器,每台伺服器上幾個庫,每個庫多少個表,推薦是 32 庫 * 32 表,對於大部分公司來說,可能幾年都夠了。

路由的規則,orderid 模 32 = 庫,orderid / 32 模 32 = 表

擴容的時候,申請增加更多的資料庫伺服器,裝好 mysql,呈倍數擴容,4 臺伺服器,擴到 8 臺伺服器,再到 16 臺伺服器。

由 dba 負責將原先資料庫伺服器的庫,遷移到新的資料庫伺服器上去,庫遷移是有一些便捷的工具的。

我們這邊就是修改一下配置,調整遷移的庫所在資料庫伺服器的位址。

重新發布系統,上線,原先的路由規則變都不用變,直接可以基於 n 倍的資料庫伺服器的資源,繼續進行線上系統的提供服務。

如何設計可以動態擴容縮容的分庫分表方案?

如何設計可以動態擴容縮容的分庫分表方案?對於分庫分表來說,主要是面對以下問題 這個是你必須面對的乙個事兒,就是你已經弄好分庫分表方案了,然後一堆庫和表都建好了,基於分庫分表中介軟體的 開發啥的都好了,測試都 ok 了,資料能均勻分布到各個庫和各個表裡去,而且接著你還通過雙寫的方案咔嚓一下上了系統,已...

如何設計可以動態擴容縮容的分庫分表方案?

如何設計可以動態擴容縮容的分庫分表方案?對於分庫分表來說,主要是面對以下問題 這個是你必須面對的乙個事兒,就是你已經弄好分庫分表方案了,然後一堆庫和表都建好了,基於分庫分表中介軟體的 開發啥的都好了,測試都 ok 了,資料能均勻分布到各個庫和各個表裡去,而且接著你還通過雙寫的方案咔嚓一下上了系統,已...

如何設計可以動態擴容縮容的分庫分表方案

這個方案就跟停機遷移一樣,步驟幾乎一致,唯一的一點就是那個導數的工具,是把現有庫表的資料抽出來慢慢倒入到新的庫和表裡去。但是最好別這麼玩兒,有點不太靠譜,因為既然分庫分表就說明資料量實在是太大了,可能多達幾億條,甚至幾十億,你這麼玩兒,可能會出問題。從單庫單錶遷移到分庫分表的時候,資料量並不是很大,...