- 選一個資料庫中間件,然後深入之
- 設計分庫分表的方案，要分成多少個庫，每個庫分成多少個表
- 基于已選的資料庫中間件，以及在測試環境建立好的分庫分表，?能否正常執行分庫分表的讀寫
- 完成單庫單表到分庫分表的遷移(使用上一文提到的雙寫方案)
- 線上系統,開始基于分庫分表對外服務
突然! 擴容了，擴容成6個庫，每個庫需要12個表，你怎麼來增加更多庫和表？
當你已經弄好分庫分表方案，測試也通過了，資料能均勻分布到各個庫和表裡去，而且接着你還通過雙寫方案上了系統，已經直接基于分庫分表方案在搞了。
需求來了~現在這些庫和表又支撐不住了，要繼續擴容，咋辦？
可能
- 每個庫的容量又快滿了
- 表資料量又太大
- 每個庫的寫并發太高
得繼續擴容!
停機擴容(不推薦)
和停機遷移一樣，步驟幾乎一緻，唯一不同是導資料的工具，是把現有庫表的資料抽出來慢慢導入到新的庫和表裡去。
最好别這樣，有點不太靠譜，既然分庫分表，就說明資料量實在太大，這麼玩可能玩脫。
從單庫單表遷移到分庫分表時，資料量并不是很大，單表最大也就兩三千萬。寫個工具，多弄幾台機器并行跑，1小時資料就導完了。
但如果是：3個庫+12個表。跑一段時間，資料量都1億~2億了，光是導2億資料，都要導個幾個小時，6點，剛剛導完資料，還要搞後續的修改配置，重新開機系統，測試驗證，大半天才搞完。
優化方案
一開始上來就是32個庫，每個庫32個表，1024張表：
- 基本上國内網際網路肯定都夠用
- 無論并發支撐還是資料量支撐都沒問題
每個庫正常承載的寫入并發量是1000，那麼32個庫就可以承載32 * 1000 = 32000的寫并發。
如果每個庫承載1500的寫并發，32 * 1500 = 48000的寫并發，接近5萬/s的寫并發。
前面再加個MQ，削峰，每秒寫入MQ 8萬條資料，每秒消費5萬條資料。
1024張表，假設每個表放500萬資料，在MySQL裡可以放50億條資料。
每秒的5萬寫并發，總共50億條資料，對于國内大部分網際網路公司來說都夠。
分庫分表的擴容，第一次分庫分表，就一次性給他分個夠。
32個庫，1024張表，對大部分的中小型網際網路公司來說，已經可以支撐好幾年。
一個實踐是利用32 * 32來分庫分表，即分為32個庫，每個庫裡一個表分為32張表，一共就是1024張表。根據某個id先根據32取模路由到庫，再根據32取模路由到庫裡的表。
剛開始的時候，這個庫可能就是邏輯庫，建在一個資料庫上的
也就是一個MySQL伺服器可能建了n個庫,後面如果要拆分，就不斷在庫和MySQL伺服器之間做遷移就可以了。然後系統配合改一下配置即可。
比如說最多可以擴充到32個資料庫伺服器，每個資料庫伺服器是一個庫。如果還是不夠？
最多可以擴充到1024個資料庫伺服器，每個資料庫伺服器上面一個庫一個表。因為最多是1024個表
這麼搞，是不用自己寫代碼做資料遷移的，都交給DBA來搞好了，但是DBA确實需要做一些庫表遷移的工作，總比你自己寫代碼，抽資料導資料來的效率高得多
哪怕是要減少庫的數量，也很簡單，按倍數縮容就可以了，然後修改一下路由規則。
5 總結
5.1 确定方案
幾台資料庫伺服器,每台伺服器上幾個庫，每個庫多少個表，推薦是
32庫 * 32表
，對于大部分公司來說，可能幾年都夠了
5.2 路由規則
orderId 模 32 = 庫，orderId / 32 模 32 = 表
5.3 擴容
當擴容時,申請增加更多的資料庫伺服器，裝好MySQL，倍數擴容，4台伺服器，擴到8台伺服器，16台伺服器
5.4 遷移
由DBA負責将原先資料庫伺服器的庫，遷移到新的資料庫伺服器上去，很多工具，庫遷移，比較便捷
5.5 配置
我們這邊就是修改一下配置，調整遷移的庫所在資料庫伺服器的位址
5.6 釋出
重新釋出系統，上線，原先的路由規則變都不用變，直接可以基于2倍的資料庫伺服器的資源，繼續進行線上系統的提供服務
分庫分表擴容方案
參考
- 《Java工程師面試突擊》