在互聯(lián)網(wǎng)業(yè)務中我們會遇到千萬級別數(shù)據(jù)量的表需要拆分成多表存儲，或者底層的數(shù)據(jù)存儲介質(zhì)的變更等原因都需要做數(shù)據(jù)的遷移，今天我們來聊聊數(shù)據(jù)的遷移方案。

1、數(shù)據(jù)的遷移策略

    假設現(xiàn)在又一張千萬級別的訂單明細表，我們需要拆分成多張子表存儲，那么我們按照什么規(guī)則來將訂單的明細放入子表中呢？

（1）哈希取模方式

    訂單明細中可以選擇訂單id作為key進行哈希取模來確定數(shù)據(jù)應該存儲在哪個子表中，如下所示：

圖片

    在具體選擇哪個字段為key的時候，我們能需要根據(jù)實際的業(yè)務中哪個字段的查詢最為頻繁，目的是盡量減少跨表查詢。常見的key可以選擇如訂單id、用戶id等等字段，采用這些字段作為分表的key，可以避免跨表查詢的問題。

（2）基于范圍分表

    首先需要確定一個合適的范圍來進行數(shù)據(jù)遷移，常見的方案又基于時間范圍或基于id范圍進行分表遷移。

    基于時間分表遷移是根據(jù)時間范圍（如同一年的數(shù)據(jù)放在一個表）將數(shù)據(jù)劃分出來，如下所示：

圖片

    基于id范圍進行數(shù)據(jù)遷移的方案是維護一張id訪問表，然后將指定的id范圍放入某張表中，如下所示：

圖片

    具體要用哪種遷移數(shù)據(jù)的策略要根據(jù)具體的業(yè)務場景，主要是基于性能、可維護性等方面考慮，最后再確定遷移的策略。

2、數(shù)據(jù)的遷移方案

2.1 停機遷移

    停機遷移是一種直接且粗暴的方法，停機遷移會影響用戶的正常訪問，所以通常會提前給用戶一個友好的通知，如下是停機遷移的圖：

圖片

    為了降低遷移過程中帶來的影響，一般都是選在凌晨進行數(shù)據(jù)的遷移，這樣盡量將風險降到最小。許多游戲公司的服務器升級，游戲分區(qū)與合區(qū)，都可能會采用類似的方案。

2.2 雙寫策略

    雙寫策略是繼續(xù)向老表寫入數(shù)據(jù)，同時再根據(jù)分表策略把數(shù)據(jù)寫入到新的分表中，并記錄開始同步新表數(shù)據(jù)的時間，如下圖所示：

圖片

    為了保證數(shù)據(jù)雙寫一致性，我們需要使用定時任務對新舊表中的數(shù)據(jù)進行對比，確保數(shù)據(jù)寫入無錯誤。經(jīng)過一段時間的雙寫之后，如果沒有任何的問題，基于最早同步的時間點把原始表之前的數(shù)據(jù)遷移到新表。

2.3 MQ+Redis實現(xiàn)數(shù)據(jù)的遷移

    使用MQ+Redis做數(shù)據(jù)遷移是一種比較平滑遷移方案，方案的流程圖如下所示：

圖片

（1）制定遷移方案

圖片

    對于千萬級別的數(shù)據(jù)量遷移，首先根據(jù)id范圍劃分的策略，如每一萬個數(shù)據(jù)劃分成一組，然后對遷移的原始表和目標都使用Redis的bitmap記錄每條數(shù)據(jù)的遷移情況，數(shù)據(jù)分成多少組，就使用多個Redis的key，key的命名含義如下：

redis_source_key：表示遷移表中Redis的key

source_tb_s1e10：表示遷移表中開始的id從1開始，結束的id是10000，這樣就表示id在1-10000范圍的數(shù)據(jù)。

redis_target_key：表示目標表的Redis的key

target_tb_s1e10：表示目標表中開始的id從1開始，結束的id是10000，這樣就表示id在1-10000范圍的數(shù)據(jù)在目標表中的保存情況（主要是記錄是否保存到目標表）。

    同時在Redis中也需要記錄每個分組（如1-10000）中本次遷移的開始時間，使用key單獨記錄（如source_tb_s1e10_startTime）；記錄每個分組中遷移的狀態(tài)（如遷移完成、正在遷移），使用key單獨記錄（如source_tb_s1e10_status）。

    記錄分組開始的時間和分組的遷移狀態(tài)的目的是為了定時任務做數(shù)據(jù)的補償。

（2）執(zhí)行遷移方案

    執(zhí)行遷移方案就是將源表中的數(shù)據(jù)分組后使用MQ的方式發(fā)送到消息隊列中，然后在Redis的bitmap中記錄每條數(shù)據(jù)的遷移情況，如下所示：

圖片

對應的bit位上為1就表示數(shù)據(jù)已經(jīng)發(fā)送MQ中等待消費。

    在消費端來消費隊列中的消息，然后按照遷移數(shù)據(jù)的策略將數(shù)據(jù)落目標表中保存下來，保存成功之后在Redis的目標key中并記錄消費情況，如下所示：

圖片

對應的bit位上為1就表示數(shù)據(jù)已經(jīng)消費成功。

（3）數(shù)據(jù)補償

    為了保存數(shù)據(jù)遷移中不被遺漏，我們可以采用定時做補償機制，原理是通過掃描Redis中分組遷移狀態(tài)是key（如source_tb_s1e10_status）是成功狀態(tài)，如下所示：

圖片

    然后把遷移狀態(tài)是成功為key的生產(chǎn)端和消費端的bitmap做異或處理，將異或結果為1的數(shù)據(jù)拿出來，如下所示：

圖片

    通過比對發(fā)現(xiàn)bit位的3和4位置上數(shù)據(jù)不一致（也就是生產(chǎn)端生成成功，但是消費端消費失敗），那么根據(jù)這個分組的開始遷移的時間與當前的時間做比對，如過大于設置的時間（如1小時），那么我們就需要手動的補償數(shù)據(jù)。

總結

（1）數(shù)據(jù)的遷移策略有哈希取模、基于時間、基于id范圍等常見的方案。

（2）常見的數(shù)據(jù)遷移的方案有停機遷移、雙寫遷移以及MQ+Redis方案遷移。