摘要：數(shù)據(jù)遷移，主要利用阿里云數(shù)據(jù)傳輸服務(wù)的數(shù)據(jù)遷移能力，涉及到全量遷移增量遷移一致性校驗及反向任務(wù)。小結(jié)通過周密的遷移方案設(shè)計，以及強(qiáng)大的數(shù)據(jù)遷移工具的能力，閑魚商品庫順利完成億在線數(shù)據(jù)庫服務(wù)遷移，獨立的物理部署顯著提升商品庫在線服務(wù)的穩(wěn)定性。

在系統(tǒng)的快速迭代過程中，業(yè)務(wù)系統(tǒng)往往部署在同一個物理庫，沒有做核心數(shù)據(jù)和非核心數(shù)據(jù)的物理隔離。隨著數(shù)據(jù)量的擴(kuò)大這種情況會帶來穩(wěn)定性的風(fēng)險，如庫的慢sql，磁盤，IO等等都會相互整體影響，從而影響核心系統(tǒng)的業(yè)務(wù)穩(wěn)定性，因此需要將核心業(yè)務(wù)的業(yè)務(wù)表從原有庫里抽取出來，多帶帶到新庫里。而核心數(shù)據(jù)的遷移，涉及到的一個關(guān)鍵難點：如何平穩(wěn)及用戶無感知的遷移數(shù)據(jù)，本文將結(jié)合閑魚商品庫遷移實踐，向大家展示如何解決這個難題的.

閑魚商品數(shù)據(jù)量XX億級別以上，采用分表分庫和讀寫分離的MYSQL數(shù)據(jù)庫集群來支撐線上查詢服務(wù),如下圖，通過TDDL[1]數(shù)據(jù)庫中間件進(jìn)行高效統(tǒng)一管理?？赡苡行┩瑢W(xué)會對分表分庫相關(guān)概念不了解，這里先簡單做些介紹。

01分表分庫原理

本質(zhì)是數(shù)據(jù)庫的水平拆分問題，把一個數(shù)據(jù)庫切分成多個部分放到不同的數(shù)據(jù)庫(server)上，從而緩解單一數(shù)據(jù)庫的性能問題，下圖描述分表分庫的核心原理：

當(dāng)然分表分庫也有負(fù)面影響，就是表結(jié)構(gòu)變更及相關(guān)管理相比單表麻煩，有一定風(fēng)險，具體如何決擇，還是要根據(jù)實際情況來分析。

02分表分庫下全局Sequence生成

分表分庫解決在線服務(wù)容量和性能問題，但是也帶來使用上的復(fù)雜度提升。靈活的配置路由規(guī)則和路由數(shù)據(jù)并提供簡單易用的封裝都是要考慮的，以便業(yè)務(wù)對此無感知。阿里開源中間件產(chǎn)品TDDL提供了解決方案，對應(yīng)阿里云上產(chǎn)品為：DRDS[2]。

TDDL關(guān)鍵原理不多做介紹，但是在數(shù)據(jù)庫遷移過程中主鍵沖突風(fēng)險是故障重要風(fēng)險點，這里簡要介紹下TDDL的全局唯一主鍵生成原理。

如上圖，TDDL Sequence是基于數(shù)據(jù)庫更新＋內(nèi)存分配：每次操作批量分配id，分配id的數(shù)量就是sequence的內(nèi)步長，而原有id值就加上外部長值，后續(xù)的分配直接就在內(nèi)存里拿，這樣的優(yōu)勢：簡單高效 缺點：無法保證自增順序。

另外數(shù)據(jù)遷移過程中，在新庫中，為了保證跟原數(shù)據(jù)庫主鍵非沖突，需要設(shè)置一個躍遷比較大的主鍵，防止出現(xiàn)兩個庫中的主鍵沖突，這是后續(xù)遷移中要注意的關(guān)鍵點之一。

通過前文的簡單介紹，大家對閑魚商品庫現(xiàn)狀有了初步了解，下面將給大家介紹一下閑魚是如何做到穩(wěn)定遷移商品庫的。

01核心思路

數(shù)據(jù)遷移核心思路抽象起來其實很簡單，即如何穩(wěn)定平滑遷移數(shù)據(jù)，如下圖所示:

但圍繞這個過程細(xì)化下去，我們會遇到不少問題，如：
1、數(shù)據(jù)我們該如何遷移，是一次性？還是分階段？
2、如何校驗數(shù)據(jù)遷移過程的正確性?
3、我們業(yè)務(wù)改造有問題怎么辦？如何盡早發(fā)現(xiàn)？如何回滾？
4、我們的新庫性能如何？

帶著這些問題，我們進(jìn)一下細(xì)化梳理遷移方案。

02實現(xiàn)方案

如上圖所示，整個方案分為幾個部份：

1、系統(tǒng)改造，包括SQL改造，雙寫開關(guān)，新庫sequence創(chuàng)建。

SQL改造：加載兩套TDDL數(shù)據(jù)源，一套是給老庫的，一套是給新庫的，并且生成兩套mybatis sql 模板。
雙寫開關(guān)：設(shè)置好寫新庫，寫老庫的開關(guān)，用于線上遷移過程中雙寫過程及遇到問題及時回滾。
sequence創(chuàng)建：遷移sequence表時，需要抬升新庫的sequence表中的值，用于防止主鍵沖突，并且需要按照主鍵消耗量評估一個安全值，這是非常重要的一個細(xì)節(jié)，再次強(qiáng)調(diào)一下。

2、穩(wěn)定性保障，遷庫是大事，改造過程中，穩(wěn)定性重中之重，主要有系統(tǒng)壓測，線上流量回放，故障演練。

系統(tǒng)壓測：主要針對新庫進(jìn)行性能測，防止新庫有意外情況。
線上流量回放：Edsger W. Dijkstra說過如果調(diào)試程序是一種標(biāo)準(zhǔn)的可以鏟除BUG的流程，那么，編程就是把他們放進(jìn)來的流程。通過引入線上數(shù)據(jù)在測試環(huán)境回放，可以盡可能的發(fā)現(xiàn)問題，保證改造后的穩(wěn)定性。
故障演練：通過注入一些人為故障，如寫新庫失敗，新庫邏輯有問題，及時的演練回滾策略。

3、數(shù)據(jù)遷移，主要利用阿里云數(shù)據(jù)傳輸服務(wù)DTS[3]的數(shù)據(jù)遷移能力，涉及到全量遷移、增量遷移、一致性校驗及反向任務(wù)。

全量遷移:數(shù)據(jù)遷移首要目標(biāo)如何將歷史全量數(shù)據(jù)遷移到新庫中，我們的做法是指定一個時間點，再根據(jù)這個時間點查找每張源表的最大及最小id,然后分別批量導(dǎo)到目標(biāo)庫中，如圖：

整個過程都是查詢在線庫的備庫，因此不影響在線業(yè)務(wù)的數(shù)據(jù)庫服務(wù)。

增量遷移:由于遷移過程中業(yè)務(wù)服務(wù)一直運(yùn)行，因此全量遷移完全成，并且要將全量時間點后的數(shù)據(jù)追回來，這里核心原理是同步全量時間位點后binlog日志數(shù)據(jù)來保證數(shù)據(jù)一致性，需要注意的是增量時間需要前移一小斷時間(如5分鐘)，其主要原因是全量遷移啟動的那刻會有時間差，需要增量前移來保證數(shù)據(jù)最終一致性，如下圖:

一致性校驗：通過全量及增量的遷移后，此時源庫跟目標(biāo)的數(shù)據(jù)理論上是一致的,但實際上應(yīng)用在經(jīng)過功能測試，線上流量回放等階段，數(shù)據(jù)在這個過程中有可能會現(xiàn)不一致的情況,因此正式上線前，需要做數(shù)據(jù)一致性校驗，其原理是分批查詢源表(跟全量遷移的查詢方式類似)，再跟目標(biāo)庫進(jìn)行比對,如圖所示：

反向任務(wù)：遷移到新庫后，會有一線離線業(yè)務(wù)對老庫還有依賴，需要建立從新庫到老庫的回流任務(wù)，原理跟增量遷移一樣，只是變更一下原庫及目標(biāo)庫。

03遷庫流程

到這里大家應(yīng)該對遷庫所涉及到點比較清楚了，但還有一個非常重要的事，即梳理整個遷庫步驟非常關(guān)鍵，通常會有兩種方案。

方案一：

1、DTS數(shù)據(jù)追平，即全量同步完成，開啟增量同步，并且延遲在秒級以內(nèi)。
2、上線前校驗，主要有線上流量回放、壓測、一致性校驗，故障演練。
3、線上開雙寫，線上同時寫新庫及老庫，這時需要關(guān)閉增量同步任務(wù)，防止無效覆蓋。
4、線上校驗，執(zhí)行預(yù)先準(zhǔn)備的測試腳本并結(jié)合一致性校驗工具，同時將讀流量慢慢切到新庫，驗證雙寫邏輯。
5、切換數(shù)據(jù)源，關(guān)閉雙寫并正式寫入新庫。
6、創(chuàng)建反向任務(wù)，數(shù)據(jù)回流老庫。

方案二：

1、DTS數(shù)據(jù)追平，即全量同步完成，開啟增量同步，并且延遲在秒級以內(nèi)。
2、上線前校驗，主要有線上流量回放、壓測、一致性校驗，故障演練。
3、線上切開關(guān)，寫新庫， 同時需要關(guān)閉增量同步任務(wù)，防止無效覆蓋。
4、創(chuàng)建反向任務(wù)，數(shù)據(jù)回流老庫。

方案優(yōu)缺點對比：

總結(jié)起來方案1遷移流程相對復(fù)雜，對遷移的控制力度更細(xì)，適合業(yè)務(wù)復(fù)雜，底層改造比較多，想精細(xì)化控制遷移步驟的場景，方案2遷移相對簡單，過程快速，適合業(yè)務(wù)流程相對簡單，可控，想快速切換的場景，具體選選擇哪個方案，同學(xué)們可以根據(jù)自身的業(yè)務(wù)情況做選擇。

這里考慮到閑魚商品業(yè)務(wù)復(fù)雜，底層改造較多，從穩(wěn)定性的角度考慮，最終選擇方案1。

方案1，最關(guān)鍵的是3、4、5步驟，因此需要預(yù)先做好回滾計劃。

04回滾方案

回滾方案總原則是不丟數(shù)據(jù)。最有可能的發(fā)生點是雙寫期間新庫出問題，導(dǎo)致線上服務(wù)異常，這時只要立即關(guān)閉寫新庫即可，另外就是切到新庫后，新庫出問題了(如性能問題)，可以立即切回到老庫，并通過反向任務(wù)，保持?jǐn)?shù)據(jù)一致性，最后若沒啟用分布式事務(wù),雙寫的時間越短越好,有可能會有數(shù)據(jù)不一致情況。

通過周密的遷移方案設(shè)計，以及DTS強(qiáng)大的數(shù)據(jù)遷移工具的能力，閑魚商品庫順利完成XX億在線數(shù)據(jù)庫服務(wù)遷移，獨立的物理部署顯著提升商品庫在線服務(wù)的穩(wěn)定性。然而不同業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫情況可能會有差異，如單庫向多庫遷移，單表向多表遷移等，不過整體方案大致類似，希望本文遷庫實踐方案能給大家提供一個可行的參考。

閱讀原文

本文來自云棲社區(qū)合作伙伴“閑魚技術(shù)”，如需轉(zhuǎn)載請聯(lián)系原作者。