1.什么是在線數(shù)據(jù)遷移

在線數(shù)據(jù)遷移，是指將正在提供線上服務(wù)的數(shù)據(jù)，從一個地方遷移到另一個地方，整個遷移過程中要求不停機(jī)，服務(wù)不受影響。根據(jù)數(shù)據(jù)所處層次，可以分為cache遷移和存儲遷移;根據(jù)數(shù)據(jù)遷移前后的變化，又可以分為平移和轉(zhuǎn)移。

平移是指遷移前后數(shù)據(jù)組織形式不變，比如Mysql從1個實(shí)例擴(kuò)展為4個實(shí)例，Redis從4個端口擴(kuò)展到16個端口，HBase從20臺機(jī)器擴(kuò)展到 30臺機(jī)器等等。如果在最初的設(shè)計里就為以后的擴(kuò)容縮容提供了方便，那么數(shù)據(jù)遷移工作就會簡單很多，比如Mysql已經(jīng)做了分庫分表，擴(kuò)展實(shí)例的時候，只需要多做幾個從庫，切換訪問，最后將多余的庫表刪除即可。更進(jìn)一步，在實(shí)現(xiàn)上已經(jīng)做到全自動數(shù)據(jù)遷移，如 HBase，就更簡單了：添加機(jī)器，手工修改配置或者系統(tǒng)自動發(fā)現(xiàn)，然后，沏一杯咖啡，等待系統(tǒng)完成遷移。

轉(zhuǎn)移是指數(shù)據(jù)遷移前后，數(shù)據(jù)組織形式發(fā)生了變化。多年前，某社交平臺曾經(jīng)為ID升級做過一次數(shù)據(jù)遷移，將ID由最初的自增算法修改為巧妙設(shè)計的UUID算法，這次遷移最大的挑戰(zhàn)是要修改數(shù)據(jù)的主鍵，主鍵本來是數(shù)據(jù)的唯一標(biāo)識，它發(fā)生變化，也就意味著原來的數(shù)據(jù)不復(fù)存在，新的數(shù)據(jù)憑空產(chǎn)生，對于整個系統(tǒng)中所有業(yè)務(wù)流程、周邊配套、上下游部門都會產(chǎn)生巨大的兼容性挑戰(zhàn)。不過大部分?jǐn)?shù)據(jù)遷移項目都不會修改主鍵，甚至不會修改數(shù)據(jù)本身，改變的只是數(shù)據(jù)的組織形式。比如某社交平臺計數(shù)器原本為了節(jié)約存儲空間，使用redis hash進(jìn)行存儲，后來為了提升批量查詢的性能，遷移成 KV 形式;又比如某社交平臺的轉(zhuǎn)發(fā)列表和粉絲列表，最初都使用Mysql存儲，后來為了更好的擴(kuò)展性和成本，都遷移到HBase存儲。

2.如何在線數(shù)據(jù)遷移據(jù)遷移

在線數(shù)據(jù)遷移最大的挑戰(zhàn)是如何保證遷移過程服務(wù)不受影響。很多人將其比喻成“飛行過程中換發(fā)動機(jī)”“給行駛的汽車換輪胎”，但實(shí)際上并沒有那么困難，一個入行一兩年的技術(shù)人員，遵從一些經(jīng)驗(yàn)指導(dǎo)，完全可以完成。下面就跟大家分享一下個人在這方面的一些經(jīng)驗(yàn)，作為拋磚引玉。

在線數(shù)據(jù)遷移一般分為四個步驟：

一，上線雙寫，即同時寫入新舊兩種數(shù)據(jù);

二，歷史數(shù)據(jù)離線搬遷，即離線將歷史存量數(shù)據(jù)從舊系統(tǒng)搬到新系統(tǒng);

三，切讀，即將讀請求路由到新系統(tǒng);

四，清理沉淀，包括清理舊的數(shù)據(jù)，回收資源，及清理舊的代碼邏輯，舊的配套系統(tǒng)等等，將遷移過程中的經(jīng)驗(yàn)教訓(xùn)進(jìn)行總結(jié)沉淀，將過程中開發(fā)或使用的工具進(jìn)行通用化改造，以備下次使用。注意，某些情況下，步驟一和步驟二也可能倒過來，先做歷史數(shù)據(jù)搬遷，然后再寫入新數(shù)據(jù)，這時候就需要謹(jǐn)慎的處理搬遷這段時間里產(chǎn)生的新數(shù)據(jù)，一般使用 queue 緩存寫入的方式，稱為“追數(shù)據(jù)”。

圖1：在線數(shù)據(jù)遷移步驟示意圖

下面以某社交平臺粉絲列表從Mysql遷移到HBase為例子，展開來講講每個步驟具體實(shí)施、可能的問題及對策。

在遷移之前，根據(jù)以往的經(jīng)驗(yàn)制定了更詳細(xì)的流程，如圖：

圖2：粉絲列表遷移到HBase工作流程圖

3.上線雙寫

編寫雙寫的代碼邏輯之前，首先要根據(jù)業(yè)務(wù)規(guī)則和性能指標(biāo)確定HBase的表結(jié)構(gòu)和主鍵設(shè)計。

對于列表類的需求，HBase有兩種典型的用法，一種是高表模式，與傳統(tǒng)的Mysql模式非常類似，列表中的每一項存一行，每一行有固定的屬性列;另一種是寬表模式，一個列表存一行，列表中的每一項存成一個單獨(dú)的列，各種屬性都打包到列內(nèi)部的value中。如圖：

圖3：粉絲列表業(yè)務(wù)分別使用HBase高表模式和寬表模式存儲示意圖

高表模式的好處在于與Mysql類似，各種業(yè)務(wù)邏輯的實(shí)現(xiàn)也比較像，認(rèn)知和改造成本較低，劣勢在于因?yàn)镠Base的實(shí)現(xiàn)機(jī)制導(dǎo)致單個列表可能被分別存儲在多個不同的Region里，查詢的性能較差。而寬表的優(yōu)劣勢正好與高表相反。在高并發(fā)大流量系統(tǒng)中，技術(shù)方案很多特性都可以妥協(xié)，但唯獨(dú)性能永遠(yuǎn)是不能妥協(xié)的，所以我們選擇寬表模式。

很多高并發(fā)系統(tǒng)都采用上行異步化，通過將操作轉(zhuǎn)化為消息，寫入消息隊列，后臺異步處理的方式來削峰填谷，并獲得更好的可用性。大部分消息隊列都支持單個消息被多個業(yè)務(wù)模塊重復(fù)處理，并支持串聯(lián)和并聯(lián)。所以在這里我們將寫入HBase的代碼邏輯單獨(dú)封裝到一個模塊中，將它配置為與寫入舊Mysql代碼串聯(lián)或并聯(lián)即可。

為了支持消息異步處理的重試機(jī)制，建議將業(yè)務(wù)模塊設(shè)計成具有冪等特性，即同一條消息可以重試多次，而不會破壞最終的結(jié)果。有一些模塊，如計數(shù)器，提醒等，業(yè)務(wù)本身不支持重試，可以通過“重復(fù)消息檢測模塊”為它們提供短時間內(nèi)的重試支持。大部分Mysql存儲都通過主鍵或者單獨(dú)的Unique key索引來達(dá)到冪等要求，相應(yīng)的，HBase高表模式通過主鍵保證，寬表模式通過column qualifier保證。在粉絲列表遷移過程中，因?yàn)閏olumn qualifier不能保證冪等，導(dǎo)致數(shù)據(jù)一致性無法達(dá)到要求，最后也是通過引入額外的重復(fù)消息檢測模塊解決。

另外，HBase當(dāng)前不提供二級索引、覆蓋索引、join、order by等Mysql高級查詢功能，需要在遷移之前做好評估，確定新方案能夠支持所有的業(yè)務(wù)特性。比如粉絲列表一般都是查詢最新的5000個粉絲，但如果還要支持查詢最初100個粉絲列表的功能，就會比較費(fèi)勁。

上線雙寫完成后，需要對雙寫的數(shù)據(jù)進(jìn)行一致性校驗(yàn)。數(shù)據(jù)一致性校驗(yàn)需要從兩個維度進(jìn)行：存儲維度和業(yè)務(wù)維度。存儲維度是指直接取Mysql和HBase里的數(shù)據(jù)進(jìn)行對比;業(yè)務(wù)維度是指從最終用戶看到的數(shù)據(jù)維度進(jìn)行校驗(yàn)，即訪問粉絲列表頁面，看結(jié)果是否與原來一致。大型系統(tǒng)的數(shù)據(jù)一致性校驗(yàn)建議及格線是6個9，即99.9999%，也就是說每一百萬條數(shù)據(jù)中，差別不能超過1條。

4.歷史數(shù)據(jù)搬遷

上線雙寫并校驗(yàn)確認(rèn)通過后，就可以開始搬遷歷史數(shù)據(jù)了。

搬遷歷史數(shù)據(jù)的步驟中，最大的困難是保證搬遷過程與線上業(yè)務(wù)寫入互不干擾。對于列表類功能，最大的干擾是來自于這樣一種業(yè)務(wù)場景：搬遷程序從Mysql中select出來一個列表，在插入到HBase之前，這個列表發(fā)生了變化。如果是增加一個元素，由于HBase的冪等保證，最終結(jié)果并不會產(chǎn)生偏差，但如果是刪除一個或多個元素，那么最終會表現(xiàn)為HBase中刪除操作未生效，因?yàn)榫€上業(yè)務(wù)執(zhí)行完刪除操作后，搬遷程序又執(zhí)行了插入操作。本質(zhì)上，這是因?yàn)槲覀冊谶@樣的數(shù)據(jù)量規(guī)模下不能使用事務(wù)引起的，如果引入事務(wù)，能夠解決這個問題，但同時也會將搬遷耗時從幾天延長到幾周甚至幾個月。為了解決這個問題，可以通過引入輕量級的Memcache鎖來模擬Serializable級別的事務(wù)隔離。

歷史數(shù)據(jù)搬遷完成后也需要進(jìn)行一致性校驗(yàn)。實(shí)際上，建議在搬遷全量數(shù)據(jù)之前，先搬遷部分?jǐn)?shù)據(jù)，并進(jìn)行一致性校驗(yàn)。部分?jǐn)?shù)據(jù)一致性校驗(yàn)通過后，再對全量數(shù)據(jù)進(jìn)行搬遷。這種方式可以極大的節(jié)約搬遷時間，降低因?yàn)榘徇w流程或代碼不完善導(dǎo)致的延期風(fēng)險。

5.切讀

全量數(shù)據(jù)搬遷并校驗(yàn)完成后，即可以進(jìn)行讀請求切換了。通用的切換方式是在代碼中埋入開關(guān)，通過 Config Service 或類似機(jī)制進(jìn)行切換操作。切換的流程為：Tcpcopy環(huán)境 –> 線上環(huán)境 uid 白名單(內(nèi)部工程師)–> 線上環(huán)境百分比灰度 0.01%，1%，10% –> 線上環(huán)境全量。tcpcopy 環(huán)境用來驗(yàn)證代碼在線上環(huán)境是否正常，uid白名單用來驗(yàn)證功能是否正常，百分比灰度用來驗(yàn)證性能和資源壓力是否正常，所有驗(yàn)證都通過后，最后才進(jìn)行全量切換。一般這個過程會持續(xù)一周到兩周。

6.清理沉淀

切讀完成后，整個數(shù)據(jù)遷移過程可以認(rèn)為已經(jīng)完成了。但項目工作并沒有完結(jié)，舊的邏輯代碼清理，舊的配套系統(tǒng)下線，舊資源回收，以及最重要的一個環(huán)節(jié)：經(jīng)驗(yàn)教訓(xùn)總結(jié)、分享，流程完善，工具通用化改造。

在線數(shù)據(jù)遷移并不是一項需要高深技術(shù)的工作，它更多需要的是對業(yè)務(wù)邏輯的把控，對操作流程的理解，對新舊系統(tǒng)特性的掌握，以及對細(xì)節(jié)的敬畏之心。

來源：微信公眾號大數(shù)據(jù)雜談