隨著企業(yè)數字化的深入，系統(tǒng)上云或者國產化改造的需求也是越來越多，數據遷移作為其中的重點中的重點，絕對是不可繞開的一個關鍵環(huán)節(jié)?？赡苡腥藭X得數據遷移不是很簡單嗎，用binlog把數據同步到新庫不就完了嗎？這就把問題想簡單了，事實上數據遷移架構可能會非常復雜，而且每個企業(yè)可能都面臨著不同的現狀與歷史情況。比如不是所有的系統(tǒng)數據庫都是Mysql，像金融等大型企業(yè)的系統(tǒng)早期大量使用了Oracle或其它的一些商業(yè)數據庫，甚至在某些限制的情況下DBA團隊都不提供7*24小時的主備同步的功能。這時你的架構應該怎么設計？

一般來說系統(tǒng)按服務對象可以分為ToC、ToB、ToG，對于后兩類系統(tǒng)或者規(guī)模較小的ToC類系統(tǒng)，通?？梢杂型C發(fā)布窗口，有停機窗口的系統(tǒng)數據遷移比無停機窗口7*24小時提供在線服務的系統(tǒng)相對來說會簡單不少

對于小型系統(tǒng)來說，系統(tǒng)的割接可能比較簡單，通常會在新系統(tǒng)中驗證通過后觀察一段時間，確認不存在回切風險后逐步下線舊系統(tǒng)即可。而對于大型系統(tǒng)來說，系統(tǒng)割接的時間可能持續(xù)幾個月甚至數年的時間，就像在飛行的飛機上換發(fā)動機一樣。對于高并發(fā)系統(tǒng)，數據的遷移除了數據庫的遷移外還需要考慮緩存的數據遷移或預熱以防止新系統(tǒng)在切入流量后發(fā)生緩存擊穿而雪崩。下面是一些常用的策略和對限制性條件下的思考：

最簡單的數據遷移策略

先來看一下最簡單的數據遷移策略：即可停機的一次性遷移。也就是說在停機發(fā)布窗口內，完成數據遷移并完成新環(huán)境的功能驗證測試，等恢復后用戶訪問到的系統(tǒng)已經更新為新系統(tǒng)。這種方式的優(yōu)點是方案簡單，缺點是當正常提供服務時間發(fā)現新環(huán)境存在重大問題時，由于新環(huán)境的數據庫通常已經寫入了新數據，已經沒辦法切回到舊環(huán)境的舊系統(tǒng)，所以這種策略適用于小規(guī)模系統(tǒng)。

具體的做法是在停機維護開始后先在舊數據庫中執(zhí)行mysqldump，再在新數據庫中導入dump文件，這種方式甚至都不要求新舊環(huán)境之間的網絡互通。在dump文件導入成功后，先進行數據驗證，通過后數據遷移工作即基本完成。再對新環(huán)境的應用程序進行功能驗證測試，通過后切換流量入口讓新環(huán)境接替舊環(huán)境對外提供服務。見下圖：

可回切的遷移策略

再來看一下稍微復雜一點的數據遷移策略：可回切的遷移策略。為了降低遷移的風險，企業(yè)通常會考慮在遷移完成并開始對外提供服務出現問題時進行回切。為了滿足回切的需求，我們通常會讓新舊兩套數據庫之間進行數據同步，新環(huán)境數據庫為主庫，舊環(huán)境數據庫為從庫，在回切時進行手工的主從倒換。這種方式也要求新舊環(huán)境間的網絡是互通的。

如上圖，剛開始，舊環(huán)境數據庫作為主庫，新環(huán)境數據庫作為從庫。為了進一步減少數據遷移的時間，可先把新環(huán)境的應用程序部署等各類工作提前做好，先不切入流量入口即可。

如上圖，在停機發(fā)布窗口到來時，先停止舊環(huán)境流量，確認主從數據庫數據同步完成后，手工執(zhí)行主從倒換將舊環(huán)境數據庫轉換為從庫，新環(huán)境數據庫轉換為主庫。在對外提供服務后，由于寫入新數據庫的數據也會同步到舊數據庫，只要新舊庫之間的數據一致，舊服務就具備了回切的條件。

當發(fā)現新環(huán)境服務存在嚴重問題需要回切時，先停止新環(huán)境流量，確認數據同步完成后手工執(zhí)行主從倒換并將流量入口切回舊環(huán)境。由于主從間的同步可以在數據遷移前就持續(xù)進行，真正遷移時只需要確認從庫的數據追上了主庫的數據后進行手工主從倒換，所以在這種方式也適用于很短停機窗口的系統(tǒng)。

雙寫的遷移策略

接下來我們來看一下更為復雜的異構數據庫遷移策略：雙寫策略。前面介紹的兩種策略都適用于同構數據庫的數據遷移，但是對于異構數據庫之間的數據遷移，我們應該如何設計呢？畢竟國產化改造多數情況是從一些商業(yè)數據庫往國產或開源的數據庫上進行遷移居多。

有一些商業(yè)的異構數據遷移工具號稱可以支持7*24小時的異構數據庫同步，但由于不同商業(yè)數據庫擁有各自豐富的特性，很難覆蓋所有方面。因此，我認為可以使用這類商業(yè)工具來進行存量數據的輔助遷移和驗證，但對于實時產生的增量數據，主要還是依靠應用程序的雙寫機制來處理。

關于雙寫的實現方法，有多種選擇，每種方法都有其優(yōu)缺點和適用環(huán)境。根據增量數據的來源不同，主要有增量日志訂閱方案和應用層雙寫方案。

增量日志訂閱方案中，最常見的是使用開源工具Canal來訂閱主庫的Mysql binlog變化，并消費binlog以獲取增量數據。這種方式只適用于Mysql作為源數據庫的情況。雖然也有一些方案可以支持Oracle等商業(yè)數據庫的數據遷移，例如愚公等工具，但它們需要額外的物化視圖權限，并且可能對性能產生影響，實際應用中使用時會有一定限制。

應用層雙寫方案包括應用同步雙寫和異步雙寫兩種方式。應用同步雙寫是指應用程序同時連接兩個數據源，在寫入數據時同時向兩個數據庫中寫入數據。這種方式會在一定程度上降低應用程序的性能，因為現在需要同時插入兩個庫，而不僅僅是一個庫。此外，該方式還要求應用與兩個數據庫必須在相同機房或者同一可用區(qū)，否則跨網絡導致的時間開銷會大大增加。應用異步雙寫方案與同步雙寫的不同之處在于，第二個庫的寫入是異步進行的?？梢酝ㄟ^使用消息隊列的方式來實現這種異步操作。由于采用了異步雙寫，對應用程序的性能影響非常小。

異步雙寫方案的具體實現如上圖所示。在這種方案中，應用在寫入數據時同時將數據寫入消息隊列。為了確保單個表的時序正確性，可以為每個表配置一個獨立的消費者來處理消息隊列中的數據。此外，為了進一步保證數據的一致性，還需要設計一個基于增量行的檢查程序，該程序依賴于源表中的last_update_time字段，用于確保兩個數據庫之間的數據一致性。

對于換數據庫與上云同時存在的需求，其實應該考慮分步去實施，即先完成一項再完成另一項，這樣在上云的過程中可以利用同構數據庫的主從同步方案，在換數據庫過程中不需要考慮跨機房網絡損耗問題帶來的各種限制。

迭代的遷移策略

在實際情況中，數據遷移可能需要采取迭代進行的策略。例如，在云原生重構方案中，企業(yè)可以安排一部分人員對系統(tǒng)進行重構，同時讓另一部分人員繼續(xù)在舊系統(tǒng)中進行需求的迭代開發(fā)。支持迭代遷移的基礎是前端能夠靈活地支持路由策略，即前端可以同時將部分服務路由到新環(huán)境，將其他服務路由到舊環(huán)境中。前端需要支持路由策略設計見下圖：

與異構數據庫遷移策略相比，迭代遷移策略需要持續(xù)的周期。這種策略通常伴隨著系統(tǒng)的重構，并且一般按照模塊進行。為了更好地實施迭代遷移，對每個模塊的遷移甚至可以將遷移過程分為兩個步驟：非實時讀業(yè)務的遷移和實時讀寫業(yè)務的遷移。

緩存的數據遷移策略

在進行緩存遷移時，一般不會直接遷移緩存數據，但需要考慮緩存的預熱。對于中小規(guī)模的系統(tǒng)，也可以直接丟棄緩存數據，讓新環(huán)境的系統(tǒng)在運行過程中逐漸生成新的緩存。然而，在高并發(fā)環(huán)境下，為了防止新環(huán)境系統(tǒng)在接收流量后發(fā)生緩存擊穿并導致雪崩效應，我們需要進行緩存的預熱。為了使預熱的數據更符合實際情況，我們可以將舊環(huán)境中一定比例的寫入緩存操作異步同步給新環(huán)境的緩存服務器，從而實現預熱的效果。由于新緩存的更新是異步的且按比例進行，對系統(tǒng)性能的影響很小。

如上圖，當舊環(huán)境的緩存服務發(fā)生更新時，異步地刷新環(huán)境緩存服務器的內容，這樣新環(huán)境緩存服務器的數據就根據實際的數據分布提前完成了預熱。