如何設計能夠動態擴容縮容的分庫分表方案？

　　

　　對於分庫分表來講，主要是面對如下問題：

• 選擇一個數據庫中間件，調研、學習、測試；
• 設計你的分庫分表的一個方案，你要分紅多少個庫，每一個庫分紅多少個表，好比 3 個庫，每一個庫 4 個表；
• 基於選擇好的數據庫中間件，以及在測試環境創建好的分庫分表的環境，而後測試一下可否正常進行分庫分表的讀寫；
• 完成單庫單表到分庫分表的遷移，雙寫方案；
• 線上系統開始基於分庫分表對外提供服務；
• 擴容了，擴容成 6 個庫，每一個庫須要 12 個表，你怎麼來增長更多庫和表呢？

　　是你必須面對的一個事兒，就是你已經弄好分庫分表方案了，而後一堆庫和表都建好了，基於分庫分表中間件的代碼開發啥的都好了，測試都 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 (表)
259	3	8
1189	5	5
352	0	11
4593	17	15

　　剛開始的時候，這個庫可能就是邏輯庫，建在一個數據庫上的，就是一個mysql服務器可能建了 n 個庫，好比 32 個庫。後面若是要拆分，就是不斷在庫和 mysql 服務器之間作遷移就能夠了。而後系統配合改一下配置便可。

　　好比說最多能夠擴展到32個數據庫服務器，每一個數據庫服務器是一個庫。若是仍是不夠？最多能夠擴展到 1024 個數據庫服務器，每一個數據庫服務器上面一個庫一個表。由於最可能是1024個表。

　　這麼搞，是不用本身寫代碼作數據遷移的，都交給 dba 來搞好了，可是 dba 確實是須要作一些庫表遷移的工做，可是總比你本身寫代碼，而後抽數據導數據來的效率高得多吧。

　　哪怕是要減小庫的數量，也很簡單，其實說白了就是按倍數縮容就能夠了，而後修改一下路由規則。

　　這裏對步驟作一個總結：

1. 設定好幾臺數據庫服務器，每臺服務器上幾個庫，每一個庫多少個表，推薦是 32庫 * 32表，對於大部分公司來講，可能幾年都夠了。
2. 路由的規則，orderId 模 32 = 庫，orderId / 32 模 32 = 表
3. 擴容的時候，申請增長更多的數據庫服務器，裝好 mysql，呈倍數擴容，4 臺服務器，擴到 8 臺服務器，再到 16 臺服務器。
4. 由 dba 負責將原先數據庫服務器的庫，遷移到新的數據庫服務器上去，庫遷移是有一些便捷的工具的。
5. 咱們這邊就是修改一下配置，調整遷移的庫所在數據庫服務器的地址。
6. 從新發布系統，上線，原先的路由規則變都不用變，直接能夠基於 n 倍的數據庫服務器的資源，繼續進行線上系統的提供服務。