[[384169]]

一、背景

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

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

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

二、容量規(guī)劃

1.當(dāng)前分庫分表情況

4實(shí)例（16C/64G/3T SSD），4庫（每個(gè)實(shí)例一個(gè)庫），每庫64張表，共256張表。

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

2.容量計(jì)算

實(shí)例數(shù)

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

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

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

表數(shù)

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

庫數(shù)

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

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

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

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

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

1.準(zhǔn)備工作

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

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

需要注意的是：

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

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

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

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

分表規(guī)則梳理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整個(gè)過程中有幾個(gè)問題需要注意：

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

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

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

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

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

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

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

后面進(jìn)行單獨(dú)介紹。

rehash

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

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

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

雙向同步時(shí)的binlog循環(huán)消費(fèi)問題

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

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

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

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

# 開啟事務(wù)，用事務(wù)保證一下sql的原子性和一致性 
start transaction; 
set autocommit = 0; 
# 更新事務(wù)表status=1，標(biāo)識(shí)后面的業(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，標(biāo)識(shí)后面的業(yè)務(wù)數(shù)據(jù)失去染色 
update tb_transaction set status = 0 where tablename = ${tableName}; 
commit; 

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

3.數(shù)據(jù)校驗(yàn)

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

全量校驗(yàn)

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

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

實(shí)時(shí)校驗(yàn)

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

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

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

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

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

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

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

1.整體灰度切流方案

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

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

• 先停寫

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

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

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

2.切流前準(zhǔn)備——ABC驗(yàn)證

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

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

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

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

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

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

3.灰度切流步驟

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

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

• 通過ACM配置灰度比例。

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

• 判斷當(dāng)前是否有灰度白名單，如命中將新庫標(biāo)識(shí)通過ThreadLocal傳遞到分庫分表組件。

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

• 切量時(shí)會(huì)配合ACM配置灰度比例命中的用戶進(jìn)行停寫。

五、總結(jié)

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

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

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