互聯網服務線上數據遷移的原則和方法

互聯網業(yè)務變更非?？?，隨著業(yè)務規(guī)模擴大，線上的業(yè)務也會涉及重構和遷移。比較難的就是存儲遷移，可能從前的存儲不適合新的業(yè)務模型了，例如從關系型數據庫遷移到nosql，或者數據的存儲格式發(fā)生了巨大的變化。

為什么說涉及數據遷移的業(yè)務最難呢？因為數據是有狀態(tài)的，不像邏輯和接入層，方便灰度，即使出問題馬上回滾就能恢復（如果涉及寫數據也也有問題）。然而數據是有狀態(tài)的，如果切換后發(fā)現新的寫存儲數據有問題，是很難修復的，也很難發(fā)現的。

任何遷移或更新，涉及到數據的，都有一個原則：要有驗證比對和回滾能力。

驗證比對

數據遷移后，要有辦法驗證這次遷移是成功的，沒問題的。只是從代碼上說，看，前后邏輯都一樣，肯定沒問題是靠不住的。我們要從結果，從用戶的角度來驗證，查看新老數據是否一致，是否有問題。

一般的方法是雙寫。老的數據庫還對外服務，把寫操作同步一份給新數據庫，兩個庫一起寫。把有改動的用戶數據同步過來，然后再寫一個同步程序，把所有用戶的全量數據導過來。檢測程序，能夠根據每個key進行比對，定期把庫里所有的數據進行新老比對，當比對率達到閾值以后。還要做一個數據比對層，用戶讀寫的時候先走比對層，同時給新老兩個邏輯層同步包，也接收回包。然后把回包進行二進制比對，保證返回給用戶的數據也是一致的。

當都達到一致之后，就可以切換了，切換后以新層為主，老層為輔，也接收同步數據。

回滾數據能力

為什么驗證比對里最后老層還要接收新層的同步呢，直接切換不好嗎？是因為萬一切換后出現bug，發(fā)現其他地方有問題，可以馬上回滾回老數據。保證線上服務正常，給開發(fā)修復bug留下充足的時間，不會有很大的時間壓力。如果不能馬上回滾，只能在線修bug。后續(xù)的每次發(fā)布修改，對開發(fā)的個人能力和狀態(tài)依賴大，不可控因素太多。很難保證服務質量。

再多說一下，由于是重構，有時會發(fā)現從前數據里的錯數據，或邏輯bug。不建議馬上修復，新的要先和老的邏輯數據對齊，穩(wěn)定后再修復老bug。否則bug改完后就沒有一個標桿來驗證數據是否一致了。

有人會說，弄這么多，得多久能完成遷移啊，效率太低。考試題目做的再快，不對也是白搭，之所以做這么多，就是保證萬無一失。欲速則不達，如果數據錯了再去修補，時間花費的更多，而且有時是補不回來的，只能回檔，那時給用戶造成的損失就大了。在QQ后臺，每次數據遷移都要經過幾周的發(fā)布比對才能切換，重大的數據層重構，沒個一年半載達到六個9的一致性，根本不會切換的。這也是為什么一次次在行動的火車上換發(fā)動機能夠成功的原因！

總結

涉及到數據的變更發(fā)布，要有比對能力，有從結果出發(fā)的方法，能夠驗證數據遷移后是正常的才可以。只從代碼邏輯層面分析是不靠譜的。

要有plan B，如果真的有問題，要能夠回滾，有回旋的余地。

做到以上所說，才能立于平滑遷移數據服務的不敗之地！