43 如何把系統不停機遷移到分庫分表的？

1、面試題

現在有乙個未分庫分表的系統，未來要分庫分表，如何設計才可以讓系統從未分庫分表動態切換到分庫分表上？

2、面試官心裡分析

你看看，你現在已經明白為啥要分庫分表了，你也知道常用的分庫分表中介軟體了，你也設計好你們如何分庫分表的方案了（水平拆分、垂直拆分、分表），那問題來了，你接下來該怎麼把你那個單庫單錶的系統給遷移到分庫分表上去？

所以這都是一環扣一環的，就是看你有沒有全流程經歷過這個過程。

3個庫，每個庫里分了4個表，每個表要放50萬的資料量

假設你已經選擇了乙個分庫分表的資料庫中介軟體，sharding-jdbc，mycat，都可以

你怎麼把線上系統平滑地遷移到分庫分表上面去

sharding-jdbc：自己上官網，找乙個官網最基本的例子，自己寫一下，試一下，跑跑看，是非常簡單的

mycat：自己上官網，找乙個官網最基本的例子，自己寫一下，試一下看看

1個小時以內就可以搞定了

3、面試題剖析

這個其實從low到高大上有好幾種方案，我們都玩兒過，我都給你說一下

（1）停機遷移方案

接著到0點，停機，系統挺掉，沒有流量寫入了，此時老的單庫單錶資料庫靜止了。然後你之前得寫好乙個導數的一次***，此時直接跑起來，然後將單庫單錶的資料嘩嘩嘩讀出來，寫到分庫分表裡面去。

導數完了之後，就ok了，修改系統的資料庫連線配置啥的，包括可能**和sql也許有修改，那你就用最新的**，然後直接啟動連到新的分庫分表上去。

驗證一下，ok了，完美，大家伸個懶腰，看看看凌晨4點鐘的北京夜景，打個滴滴回家吧！

但是這個方案比較low，誰都能幹，我們來看看高大上一點的方案。

長時間停機分庫分表.png

（2）雙寫遷移方案

這個是我們常用的一種遷移方案，比較靠譜一些，不用停機，不用看北京凌晨4點的風景

然後系統部署之後，新庫資料差太遠，用之前說的導數工具，跑起來讀老庫資料寫新庫，寫的時候要根據gmt_modified這類字段判斷這條資料最後修改的時間，除非是讀出來的資料在新庫里沒有，或者是比新庫的資料新才會寫。

接著導萬一輪之後，有可能資料還是存在不一致，那麼就程式自動做一輪校驗，比對新老庫每個表的每條資料，接著如果有不一樣的，就針對那些不一樣的，從老庫讀資料再次寫。反覆迴圈，直到兩個庫每個表的資料都完全一致為止。

不停機雙寫方案.png

接著當資料完全一致了，就ok了，基於僅僅使用分庫分表的最新**，重新部署一次，不就僅僅基於分庫分表在操作了麼，還沒有幾個小時的停機時間，很穩。所以現在基本玩兒資料遷移之類的，都是這麼幹了。

文集：