方案：
上線代碼中啓動的時候獲取表中最大的id，記爲maxId,然後如果insert 插入新的庫，查詢刪除修改判斷id是否大於maxId，如果是走新庫。對於小於等於maxId的數據走老庫，同時監聽binlog ，發到消息隊列堆積，暫不消費，因爲可能老數據還沒有遷移，做數據糾正。然後注意一下如果插入數據要唯一，注意去老庫校驗一下唯一性，因爲新庫沒數據。
問題1 如何保證一上線之後的對老數據的修改都監聽到 不漏？
通過上面的做法，大於maxId的數據都是沒問題的，然後跑你事先寫好的遷移老數據的腳本，以爲是批量執行，所以這一段時間內可能你遷到新庫之後，又對老庫修改了，數據就又舊了。遷移腳本執行完只能保證小於等於maxId的數據老庫有 新庫也有，但是可能舊於老庫。然後消費消息隊列的日誌，做數據訂正，只需要處理delete update，消息隊列中的binlog，可能不需要執行，也可能需要執行，不需要執行時因爲遷的數據已經是新的了，需要執行是因爲腳步先遷移，然後在修改了數據，這時候這個binlog是需要的。對於不需要執行的情況，delete的數據無論在delete還是update都是沒有關係的，對於沒有刪除的數據 如果delete或update 對應的binlog如果不執行就使用會有問題，所以我覺得得消費完之後在切庫。問題是消費不玩咋辦。對於一些敏感的數據，比如金額，庫存，會導致超額超賣。
當消費完之後切庫，修改代碼對於小於等於maxId的數據也走新庫。
問題2 只要對老庫的小於等於maxId的數據做修改，消息隊列一直會有數據，何時消費完？
寫到這裏發現這裏數據不一致的問題根本就是cap問題，因爲你數據要遷移，最後如果要保證嚴格一直，即cp，那麼必須捨棄a可用性，如停機遷移 這完全犧牲了a，或者查詢新庫發現沒有數據，加個分佈式鎖，對於這一行的數據的增刪改查都等到這一行數據複製過來再執行，這也是cp。而我上面說的如果不等消息隊列的數據執行完就切庫，那就是最終一致性。