[[384169]]

一、背景

2020年， 筆者負責的一個高德打車彈外訂單系統(tǒng)進行了一次擴分庫分表和數(shù)據(jù)庫遷移。 該訂單系統(tǒng)整體部署在阿里云上，服務(wù)使用阿里云ECS部署，數(shù)據(jù)庫采用阿里云RDS，配置中心基于阿里云ACM自 研，數(shù) 據(jù)同步基于阿里云DTS自研以及自研分庫分表組件、分布式ID組件等等。

此次進行擴分庫分表的背景是，原4實例4庫、每個庫64張表一共256張表，部分單表已超千萬量級，按當前每日單量量級，一年內(nèi)單表會達到上億條記錄，單表數(shù)據(jù)量過大會帶來數(shù)據(jù)庫性能問題。

注 ： 【彈內(nèi)彈外】彈是指彈性計算，彈內(nèi)與彈外其實是指兩套獨立的彈性計算網(wǎng)絡(luò)環(huán)境。 彈內(nèi)主要是指部署在阿里生產(chǎn)網(wǎng)的彈性計算環(huán)境，最早是基于原有淘寶技術(shù)構(gòu)建的，主要用于支撐淘寶業(yè)務(wù)。 彈外主要是指部署在阿里公有云的彈性計算環(huán)境，支撐了阿里云計算業(yè)務(wù)。

二、容量規(guī)劃

1.當前分庫分表情況

4實例（16C/64G/3T SSD），4庫（每個實例一個庫），每庫64張表，共256張表。

通過RDS后臺一鍵診斷功能，來計算表空間使用情況（這里 拿測試環(huán)境數(shù)據(jù)庫舉例） 。

2.容量計算

實例數(shù)

數(shù)據(jù)庫的瓶頸主要體現(xiàn)在：磁盤、CPU、內(nèi)存、網(wǎng)絡(luò)、連接數(shù)，而連接數(shù)主要是受 CPU 和內(nèi)存影響。 CPU 和內(nèi)存可以通過動態(tài)升配來提升，但是SSD磁盤容量最大支持到6T（32C以下最大3T、32C及以上最大6T）。

但是現(xiàn)階段兼顧成本，可先將實例擴容一倍，采用8個實例(16C/64G/3T SSD)，每個實例建4個庫（database）、每個庫128張表（這里實際上是一個成本取舍的過程，理論上應(yīng)該采取"多庫少表"的原則，單庫128張表其實太多了，單庫建議32或64張表為宜） 。

后續(xù)如果實例壓力提升可進行實例配置升級(16C/128G、32C/128G、32C/256G等)；未來如出現(xiàn)單實例升配無法解決，在考慮擴容實例，只需要將database遷移至新實例，遷移成本較小。

表數(shù)

按單表最多1000w條數(shù)據(jù)評估，4096張表可支持日5000w單*3年(10.1壓測標準)、日2000w單*5年的架構(gòu)。（因業(yè)務(wù)表比較多，此處忽略掉單條數(shù)據(jù)大小的計算過程）

庫數(shù)

32個庫，每個庫128張表。未來可最大擴容到32個實例，無需rehash，只需要遷移數(shù)據(jù)。  

阿里云RDS規(guī)格和價格一覽

三、數(shù)據(jù)遷移

因擴分庫分表涉及到rehash過程（256表變4096表），而阿里云DTS只支持同構(gòu)庫數(shù)據(jù)遷移，所以我們基于DTS的binlog轉(zhuǎn)kafka能力自研了數(shù)據(jù)同步中間件。

整個數(shù)據(jù)遷移工作包括：前期準備、數(shù)據(jù)同步環(huán)節(jié)（歷史數(shù)據(jù)全量同步、增量數(shù)據(jù)實時同步、rehash）、數(shù)據(jù)校驗環(huán)節(jié)（全量校驗、實時校驗、校驗規(guī)則配置）、數(shù)據(jù)修復(fù)工具等。

1.準備工作

唯一業(yè)務(wù)ID

在進行數(shù)據(jù)同步前，需要先梳理所有表的唯一業(yè)務(wù)ID，只有確定了唯一業(yè)務(wù)ID才能實現(xiàn)數(shù)據(jù)的同步操作。

需要注意的是：

• 業(yè)務(wù)中是否有使用數(shù)據(jù)庫自增ID做為業(yè)務(wù)ID使用的，如果有需要業(yè)務(wù)先進行改造，還好訂單業(yè)務(wù)里沒有。

• 每個表是否都有唯一索引，這個在梳理的過程中發(fā)現(xiàn)有幾張表沒有唯一索引。

一旦表中沒有唯一索引，就會在數(shù)據(jù)同步過程中造成數(shù)據(jù)重復(fù)的風險，所以我們先將沒有唯一索引的表根據(jù)業(yè)務(wù)場景增加唯一索引（有可能是聯(lián)合唯一索引）。

在這里順便提一下，阿里云DTS做同構(gòu)數(shù)據(jù)遷移，使用的是數(shù)據(jù)庫自增ID做為唯一ID使用的，這種情況如果做雙向同步，會造成數(shù)據(jù)覆蓋的問題。解決方案也有，之前我們的做法是，新舊實體采用自增ID單雙號解決，保證新舊實例的自增ID不會出現(xiàn)沖突就行。因為這次我們使用的自研雙向同步組件，這個問題這里不細聊。

分表規(guī)則梳理

分表規(guī)則不同決定著rehash和數(shù)據(jù)校驗的不同。需逐個表梳理是用戶ID緯度分表還是非用戶ID緯度分表、是否只分庫不分表、是否不分庫不分表等等。

2.數(shù)據(jù)同步

數(shù)據(jù)同步整體方案見下圖，數(shù)據(jù)同步基于binlog，獨立的中間服務(wù)做同步，對業(yè)務(wù)代碼無侵入。

接下來對每一個環(huán)節(jié)進行介紹。

歷史數(shù)據(jù)全量同步

單獨一個服務(wù)，使用游標的方式從舊庫分批select數(shù)據(jù)，經(jīng)過rehash后批量插入（batch insert）到新庫，此處需要配置jdbc連接串參數(shù)rewriteBatchedStatements=true才能使批處理操作生效。

另外特別需要注意的是，歷史數(shù)據(jù)也會存在不斷的更新，如果先開啟歷史數(shù)據(jù)全量同步，則剛同步完成的數(shù)據(jù)有可能不是最新的。所以這里的做法是，先開啟增量數(shù)據(jù)單向同步（從舊庫到新庫），此時只是開啟積壓kafka消息并不會真正消費；然后在開始歷史數(shù)據(jù)全量同步，當歷史全量數(shù)據(jù)同步完成后，在開啟消費kafka消息進行增量數(shù)據(jù)同步（提高全量同步效率減少積壓也是關(guān)鍵的一環(huán)），這樣來保證遷移數(shù)據(jù)過程中的數(shù)據(jù)一致。

增量數(shù)據(jù)實時同步

增量數(shù)據(jù)同步考慮到灰度切流穩(wěn)定性、容災(zāi)和可回滾能力，采用實時雙向同步方案，切流過程中一旦新庫出現(xiàn)穩(wěn)定性問題或者新庫出現(xiàn)數(shù)據(jù)一致問題，可快速回滾切回舊庫，保證數(shù)據(jù)庫的穩(wěn)定和數(shù)據(jù)可靠。

增量數(shù)據(jù)實時同步采用基于阿里云DTS的數(shù)據(jù)訂閱自研數(shù)據(jù)同步組件data-sync實現(xiàn)，主要方案是DTS數(shù)據(jù)訂閱能力會自動將被訂閱的數(shù)據(jù)庫binlog轉(zhuǎn)為kafka，data-sync組件訂閱kafka消息、將消息進行過濾、合并、分組、rehash、拆表、批量insert/update，最后再提交offset等一系列操作，最終完成數(shù)據(jù)同步工作。

• 過濾循環(huán)消息：需要過濾掉循環(huán)同步的binlog消息，這個問題比較重要后面將進行單獨介紹。

• 數(shù)據(jù)合并：同一條記錄的多條操作只保留最后一條。為了提高性能，data-sync組件接到kafka消息后不會立刻進行數(shù)據(jù)流轉(zhuǎn)，而是先存到本地阻塞隊列，然后由本地定時任務(wù)每X秒將本地隊列中的N條數(shù)據(jù)進行數(shù)據(jù)流轉(zhuǎn)操作。此時N條數(shù)據(jù)有可能是對同一張表同一條記錄的操作，所以此處只需要保留最后一條（類似于redis aof重寫） 。

• update轉(zhuǎn)insert：數(shù)據(jù)合并時，如果數(shù)據(jù)中有insert+update只保留最后一條update，會執(zhí)行失敗，所以此處需要將update轉(zhuǎn)為insert語句。

• 按新表合并：將最終要提交的N條數(shù)據(jù)，按照新表進行拆分合并，這樣可以直接按照新表緯度進行數(shù)據(jù)庫批量操作，提高插入效率。

整個過程中有幾個問題需要注意：

問題1：怎么防止因異步消息無順序而導(dǎo)致的數(shù)據(jù)一致問題？

首先kafka異步消息是存在順序問題的，但是要知道的是binlog是順序的，所以dts在對詳細進行kafka消息投遞時也是順序的，此處要做的就是一個庫保證只有一個消費者就能保障數(shù)據(jù)的順序問題、不會出現(xiàn)數(shù)據(jù)狀態(tài)覆蓋，從而解決數(shù)據(jù)一致問題。

問題2：是否會有丟消息問題，比如消費者服務(wù)重啟等情況下？

這里沒有采用自動提交offset，而是每次消費數(shù)據(jù)最終入庫完成后，將offset異步存到一個mysql表中，如果消費者服務(wù)重啟宕機等，重啟后從mysql拿到最新的offset開始消費。這樣唯一的一個問題可能會出現(xiàn)瞬間部分消息重復(fù)消費,但是因為上面介紹的binlog是順序的,所以能保證數(shù)據(jù)的最終一致。

問題3：update轉(zhuǎn)insert會不會丟字段？

binlog是全字段發(fā)送,不會存在丟字段情況。

問題4：循環(huán)消息問題。

后面進行單獨介紹。

rehash

前文有提到，因為是256表變4096表，所以數(shù)據(jù)每一條都需要經(jīng)過一次rehash重新做分庫分表的計算。

要說rehash，就不得不先介紹下當前訂單數(shù)據(jù)的分庫分表策略，訂單ID中冗余了用戶ID的后四位，通過用戶ID后四位做hash計算確定庫號和表號。

數(shù)據(jù)同步過程中，從舊庫到新庫，需要拿到訂單ID中的用戶ID后四位模4096，確定數(shù)據(jù)在新庫中的庫表位置；從新庫到舊庫，則需要用用戶ID后四位模256，確定數(shù)據(jù)在舊庫中的庫表位置。

雙向同步時的binlog循環(huán)消費問題

想象一下，業(yè)務(wù)寫一條數(shù)據(jù)到舊實例的一張表，于是產(chǎn)生了一條binlog；data-sync中間件接到binlog后，將該記錄寫入到新實例，于是在新實例也產(chǎn)生了一條binlog；此時data-sync中間件又接到了該binlog......不斷循環(huán)，消息越來越多，數(shù)據(jù)順序也被打亂。

怎么解決該問題呢？我們采用數(shù)據(jù)染色方案，只要能夠標識寫入到數(shù)據(jù)庫中的數(shù)據(jù)使data-sync中間件寫入而非業(yè)務(wù)寫入，當下次接收到該binlog數(shù)據(jù)的時候就不需要進行再次消息流轉(zhuǎn)。

所以data-sync中間件要求，每個數(shù)據(jù)庫實例創(chuàng)建一個事務(wù)表，該事務(wù)表tb_transaction只有id、tablename、status、create_time、update_time幾個字段，status默認為0。

再回到上面的問題，業(yè)務(wù)寫一條數(shù)據(jù)到舊實例的一張表，于是產(chǎn)生了一條binlog；data-sync中間件接到binlog后，如下操作：

# 開啟事務(wù)，用事務(wù)保證一下sql的原子性和一致性 
start transaction; 
set autocommit = 0; 
# 更新事務(wù)表status=1，標識后面的業(yè)務(wù)數(shù)據(jù)開始染色 
update tb_transaction set status = 1 where tablename = ${tableName}; 
# 以下是業(yè)務(wù)產(chǎn)生binlog 
insert xxx; 
update xxx; 
update xxx; 
# 更新事務(wù)表status=0，標識后面的業(yè)務(wù)數(shù)據(jù)失去染色 
update tb_transaction set status = 0 where tablename = ${tableName}; 
commit; 

此時data-sync中間件將上面這些語句打包一起提交到新實例，新實例更新數(shù)據(jù)后也會生產(chǎn)對應(yīng)上面語句的binlog；當data-sync中間件再次接收到binlog時，只要判斷遇到tb_transaction表status=1的數(shù)據(jù)開始，后面的數(shù)據(jù)都直接丟棄不要，直到遇到status=0時，再繼續(xù)接收數(shù)據(jù)，以此來保證data-sync中間件只會流轉(zhuǎn)業(yè)務(wù)產(chǎn)生的消息。

3.數(shù)據(jù)校驗

數(shù)據(jù)校驗?zāi)K由數(shù)據(jù)校驗服務(wù)data-check模塊來實現(xiàn)，主要是基于數(shù)據(jù)庫層面的數(shù)據(jù)對比，逐條核對每一個數(shù)據(jù)字段是否一致，不一致的話會經(jīng)過配置的校驗規(guī)則來進行重試或者報警。

全量校驗

• 以舊庫為基準，查詢每一條數(shù)據(jù)在新庫是否存在，以及個字段是否一致。

• 以新庫為基準，查詢每一條數(shù)據(jù)在舊庫是否存在，以及個字段是否一致。

實時校驗

• 定時任務(wù)每5分鐘校驗，查詢最近5+1分鐘舊庫和新庫更新的數(shù)據(jù)，做diff。

• 差異數(shù)據(jù)進行二次、三次校驗（由于并發(fā)和數(shù)據(jù)延遲存在），三次校驗都不同則報警。

4.數(shù)據(jù)修復(fù)

經(jīng)過數(shù)據(jù)校驗，一旦發(fā)現(xiàn)數(shù)據(jù)不一致，則需要對數(shù)據(jù)進行修復(fù)操作。

數(shù)據(jù)修復(fù)有兩種方案，一種是適用于大范圍的數(shù)據(jù)不一致，采用重置kafka offset的方式，重新消費數(shù)據(jù)消息，將有問題的數(shù)據(jù)進行覆蓋。

第二種是適用于小范圍的數(shù)據(jù)不一致，數(shù)據(jù)修復(fù)模塊自動拉取數(shù)據(jù)校驗data-check模塊記錄的sls日志，進行日志解析，生成同步語句，更新到目標庫。

四、灰度切換數(shù)據(jù)源

1.整體灰度切流方案

整體灰度方案：SP+用戶緯度來實現(xiàn)，SP緯度：依靠灰度環(huán)境切量來做，用戶緯度：依賴用戶ID后四位百分比切流。

灰度切量的過程一定要配合停寫（秒級），為什么要停寫，因為數(shù)據(jù)同步存在一定延遲（正常毫秒級），而所有業(yè)務(wù)操作一定要保障都在一個實例上，否則在舊庫中業(yè)務(wù)剛剛修改了一條數(shù)據(jù)，此時切換到新庫如果數(shù)據(jù)還沒有同步過來就是舊數(shù)據(jù)會有數(shù)據(jù)一致問題。所以步驟應(yīng)該是：

• 先停寫

• 觀察數(shù)據(jù)全部同步完

• 在切換數(shù)據(jù)源

• 最后關(guān)閉停寫，開始正常業(yè)務(wù)寫入

2.切流前準備——ABC驗證

雖然在切流之前，在測試環(huán)境進過了大量的測試，但是測試環(huán)境畢竟和生產(chǎn)環(huán)境不一樣，生產(chǎn)環(huán)境數(shù)據(jù)庫一旦出問題就可能是滅頂之災(zāi)，雖然上面介紹了數(shù)據(jù)校驗和數(shù)據(jù)修復(fù)流程，但是把問題攔截在發(fā)生之前是做服務(wù)穩(wěn)定性最重要的工作。

因此我們提出了ABC驗證的概念，灰度環(huán)境ABC驗證準備：

• 新購買兩套數(shù)據(jù)庫實例，當前訂單庫為A，新買的兩套為分別為B、C

• 配置DTS從A單項同步到B（dts支持同構(gòu)不需要rehash的數(shù)據(jù)同步），B做為舊庫的驗證庫，C庫做為新庫

• 用B和C做為生產(chǎn)演練驗證

• 當B和C演練完成之后，在將A和C配置為正式的雙向同步

3.灰度切流步驟

具體灰度方案和數(shù)據(jù)源切換流程：

• 代碼提前配置好兩套數(shù)據(jù)庫分庫分表規(guī)則。

• 通過ACM配置灰度比例。

• 代碼攔截mybatis請求，根據(jù)用戶id后四位取模，和ACM設(shè)置中設(shè)置的灰度比例比較，將新庫標識通過ThreadLocal傳遞到分庫分表組件。

• 判斷當前是否有灰度白名單，如命中將新庫標識通過ThreadLocal傳遞到分庫分表組件。

• 分庫分表組件根據(jù)ACM配置拿到新分庫的分表規(guī)則，進行數(shù)據(jù)庫讀寫操作。

• 切量時會配合ACM配置灰度比例命中的用戶進行停寫。

五、總結(jié)

整個數(shù)據(jù)遷移過程還是比較復(fù)雜的，時間也不是很充裕（過程中還穿插著十一全鏈路壓測改造），在有限的時間內(nèi)集大家之力重復(fù)討論挖掘可能存在的問題，然后論證解決方案，不放過任何一個可能出現(xiàn)問題的環(huán)節(jié)，還是那句話，把問題攔截在發(fā)生之前是做服務(wù)穩(wěn)定性最重要的工作。

過程中的細節(jié)還是很多的，從數(shù)據(jù)遷移的準備工作到數(shù)據(jù)同步測試，從灰度流程確定到正式生產(chǎn)切換，尤其是結(jié)合業(yè)務(wù)和數(shù)據(jù)的特點，有很多需要考慮的細節(jié)，文中沒有一一列出。

最終經(jīng)過近兩個月的緊張工作，無業(yè)務(wù)代碼侵入、零事故、平穩(wěn)地完成了擴分庫分表和數(shù)據(jù)遷移的工作。