背景

采購(gòu)系統(tǒng)（BIP）在經(jīng)歷多年演進(jìn)后，系統(tǒng)整體復(fù)雜度和數(shù)據(jù)量?jī)叭灰呀?jīng)極具規(guī)模，本文著重討論海量數(shù)據(jù)的治理

存儲(chǔ)現(xiàn)狀：工程端實(shí)時(shí)訂單庫(kù)采用MySQL 5.5集群，其中主庫(kù)配置為32C/48G/6000G，無法歸檔的訂單熱數(shù)據(jù)占磁盤空間85%（5.1T）

痛點(diǎn)：6T磁盤已經(jīng)單容器最大，無法繼續(xù)擴(kuò)容，剩余磁盤余量過小，難適應(yīng)未來發(fā)展

目標(biāo)

降低磁盤容量，優(yōu)化數(shù)據(jù)模型，提升系統(tǒng)穩(wěn)定性

調(diào)研

首先，既然是要解決存儲(chǔ)容量的問題，就要對(duì)詳細(xì)的容量情況有個(gè)更加清楚的了解。總結(jié)下當(dāng)前存儲(chǔ)容量問題，最大的表是訂單操作日志表lifecycle共1.3T，大于500G的表2張共1.5T；100G~500G的表10張共2.6T。以下是優(yōu)化前庫(kù)里大表（大于100G）的詳細(xì)空間占用情況：

其次，確認(rèn)當(dāng)前最高效的優(yōu)化思路是將lifecycle表遷移到其他庫(kù)，原因有二：1.lifecycle表的含義是操作日志，在業(yè)務(wù)上不算訂單域內(nèi)最核心的模型，風(fēng)險(xiǎn)可控；2.占用空間大，單表46億行數(shù)據(jù)，空間占用1.3T，一張表占了磁盤空間的22%，優(yōu)化的ROI高

最后，想說明下，為什么沒有直接將整個(gè)庫(kù)，從傳統(tǒng)MySQL切換到JED，原因也有二：1.JED和MySQL的查詢語法還是有一定差異，直接切換，成本和風(fēng)險(xiǎn)極高；2.切換存儲(chǔ)中間件，獲取分布式架構(gòu)下更大的存儲(chǔ)空間并不是銀彈，理智告訴我們要結(jié)合系統(tǒng)現(xiàn)狀，不可盲目下定論

挑戰(zhàn)

保障海量數(shù)據(jù)（存量46億行，增量600w+行/天，TPS峰值：500+，QPS峰值：200+）遷移期間讀、寫穩(wěn)定和準(zhǔn)確。需要補(bǔ)充一下：lifecycle雖然不算訂單最核心業(yè)務(wù)模型，但依舊是輔助業(yè)務(wù)決策的關(guān)鍵數(shù)據(jù)，也非常重要

例子：

方案

整體方案

數(shù)據(jù)同步 -> 雙讀 -> 雙寫 -> 離線驗(yàn)證 -> 數(shù)據(jù)清理

詳細(xì)設(shè)計(jì)

?數(shù)據(jù)同步，通過DRC實(shí)現(xiàn)，歷史全量+增量，其中有以下幾點(diǎn)使用心得：

?同步速度問題，本次是使用傳統(tǒng)MySQL5.5 -> JED 底層MySQL 8.0 單表同步，效率大概是4M/S，一共花了3天半左右

?數(shù)據(jù)同步過程中不要操作暫停，否則任務(wù)重啟后，會(huì)重新同步歷史數(shù)據(jù)，導(dǎo)致數(shù)據(jù)同步周期變長(zhǎng)。詳情參考： 關(guān)于全量任務(wù)暫停重啟之后數(shù)據(jù)同步慢的原因

?字段兼容問題，老庫(kù)歷史時(shí)間字段類型是datetime，新庫(kù)需要改為datetime(3)，這種數(shù)據(jù)同步是可以兼容的（下文會(huì)講為什么要優(yōu)化時(shí)間字段精度）

?數(shù)據(jù)驗(yàn)證問題，當(dāng)時(shí)在歷史數(shù)據(jù)全量同步完畢后開啟了DRC數(shù)據(jù)驗(yàn)證，但是許久未執(zhí)行完成，收到DRC運(yùn)維告知出現(xiàn)大量報(bào)錯(cuò)，最終結(jié)論是暫時(shí)不支持這兩個(gè)版本的數(shù)據(jù)比對(duì)（5.5->8.0），這也是為什么整體架構(gòu)上采用BDP抽數(shù)比對(duì)數(shù)據(jù)的主要原因

?數(shù)據(jù)驗(yàn)證，業(yè)務(wù)程序完成雙寫、雙讀改造

?雙寫

?為什么采用雙寫？答：控制風(fēng)險(xiǎn)。1.團(tuán)隊(duì)內(nèi)還沒有應(yīng)用直接寫入多分片JED的先例，而且新、老庫(kù)的底層MySQL版本也差異比較大（5.5 vs 8.0），當(dāng)時(shí)通過分批次灰度上線完成逐步切量驗(yàn)證；2.方便進(jìn)行數(shù)據(jù)驗(yàn)證，lifecycle是業(yè)務(wù)操作日志，基本涵蓋了所有的寫入場(chǎng)景，其中因?yàn)闅v史問題，不乏一部分邏輯和訂單更新在同一事務(wù)中，現(xiàn)在遷移到新庫(kù)，本地事務(wù)會(huì)存在不生效的場(chǎng)景

?具體改造方案：

?新增【驗(yàn)證開關(guān)】，開啟后新/老庫(kù)雙寫，另外需要要引入vitess驅(qū)動(dòng)，目前只支持JDK8及以上

?新增【上線開關(guān)】，開啟后只寫新庫(kù)，此開關(guān)是在驗(yàn)證邏輯無問題后，最終切換的開關(guān)，代表遷移完成

?注意，開關(guān)改造完成上線后，“全量+增量DRC任務(wù)”在驗(yàn)證期間是一直啟用的，也就是說驗(yàn)證期間，增量數(shù)據(jù)會(huì)寫兩份到新庫(kù)

?一部分是實(shí)際的生產(chǎn)數(shù)據(jù)，一部分是待驗(yàn)證的測(cè)試數(shù)據(jù)。那么就帶來另一個(gè)問題，如何識(shí)別和區(qū)分這兩部分?jǐn)?shù)據(jù)，我們采用的方案是：JED建表指定趨勢(shì)自增的最小id（200億）+【驗(yàn)證開關(guān)】開啟的時(shí)間戳進(jìn)行區(qū)分

?如下圖，其中A和A'都是【驗(yàn)證開關(guān)】切換后的增量數(shù)據(jù)，由于老庫(kù)的id已經(jīng)自增寫到了70億，并且DRC同步任務(wù)也是指定id寫入，所以建表時(shí)指定新增數(shù)據(jù)id是200億（詳情參考： 數(shù)據(jù)庫(kù)自增ID列設(shè)置 ），和老數(shù)據(jù)之間存在一定gap方便識(shí)別。BDP腳本數(shù)據(jù)比對(duì)的也是：老庫(kù).A和新庫(kù).A'（這里默認(rèn)DRC增量同步的數(shù)據(jù)是準(zhǔn)確的）

?清除測(cè)試數(shù)據(jù)，真正完成【上線開關(guān)】切換，需要提前清除測(cè)試數(shù)據(jù)，只需指定id>200億的物理刪除即可。注意：針對(duì)多分片的JED物理刪除delete語句，我們程序上如果為了防止大事務(wù)，而采用“for循環(huán)+limit n”的方式執(zhí)行，實(shí)際的每次SQL語句執(zhí)行結(jié)果是多個(gè)分片的n的聚合，而不是n，如果程序上對(duì)結(jié)果有判斷邏輯，需要額外注意

?雙讀

?整體邏輯基本復(fù)用寫入期間已有開關(guān)，其中針對(duì)新庫(kù)當(dāng)中DRC實(shí)時(shí)同步的數(shù)據(jù)（上圖：新庫(kù).A）會(huì)根據(jù)開關(guān)開啟時(shí)間進(jìn)行過濾

?其中，在驗(yàn)證期間，新、老庫(kù)都會(huì)根據(jù)采購(gòu)單號(hào)進(jìn)行查詢并實(shí)際返回老庫(kù)的查詢結(jié)果，其中還會(huì)進(jìn)行結(jié)果比對(duì)，出現(xiàn)數(shù)據(jù)不一致會(huì)輸出異常日志關(guān)鍵字

?另外，因?yàn)閘ifecycle操作日志數(shù)據(jù)是有先后順序的，老庫(kù)的處理方式是根據(jù)自增id進(jìn)行倒排，到了新庫(kù)以后，由于采用的是JED分片（分布式存儲(chǔ)的磁盤空間更大），考慮到開發(fā)成本，數(shù)據(jù)id采用的是趨勢(shì)遞增的自增主鍵（詳情參考： Vitess全局唯一ID生成的實(shí)現(xiàn)方案 ），這時(shí)多集群并行寫入無法繼續(xù)使用基于id倒排的方式返回結(jié)果（后寫入的數(shù)據(jù)可能id較小，可以參考sequece發(fā)號(hào)器的ID生成），所以將原始的數(shù)據(jù)寫入時(shí)間戳從datetime提高精度到datetime(3)，通過數(shù)據(jù)寫入時(shí)間進(jìn)行倒排，這里也解釋了上文，新庫(kù)DRC數(shù)據(jù)同步為什么要考慮字段兼容的問題

?補(bǔ)充1：這里基于時(shí)間倒排在業(yè)務(wù)上是準(zhǔn)確的，因?yàn)閘ifecycle數(shù)據(jù)是根據(jù)訂單號(hào)進(jìn)行分片的，所以同一訂單一定落在單分片上，也就是說不存在不同分片時(shí)鐘偏移的問題，單訂單的操作日志的時(shí)間序列一定是按照寫入順序逐漸增加的

?補(bǔ)充2：新庫(kù)字段類型變更（datetime->datetime(3)），32分片，共46億行數(shù)據(jù)，執(zhí)行了大概1小時(shí)，期間主從延遲最高30分鐘，容器負(fù)載正常

?補(bǔ)充3：應(yīng)用的關(guān)鍵字告警配置，日志文件僅支持以error.log、err.log、exception.log結(jié)尾，并開啟歷史日志的路徑

?最后，雙讀期間共通過業(yè)務(wù)的實(shí)際查詢流量發(fā)現(xiàn)數(shù)據(jù)不一致問題2個(gè)+，在并未影響到業(yè)務(wù)使用的前提下及時(shí)發(fā)現(xiàn)了系統(tǒng)異常

?離線驗(yàn)證

?lifecycle歸根結(jié)底還是寫多讀少的業(yè)務(wù)場(chǎng)景，為了防止出現(xiàn)上文數(shù)據(jù)比對(duì)驗(yàn)證的遺漏，我們會(huì)采用BDP離線任務(wù)會(huì)分別開啟增量數(shù)據(jù)+歷史全量數(shù)據(jù)驗(yàn)證。通過對(duì)新、老庫(kù)的全量數(shù)據(jù)字段相互sql inner join的方式完成比對(duì)，其中會(huì)忽略id和寫入時(shí)間，因?yàn)樾聨?kù)的id不是單調(diào)遞增、時(shí)間精確到了毫秒。期間共發(fā)現(xiàn)有效數(shù)據(jù)問題3個(gè)+，均是因?yàn)楸镜厥聞?wù)回滾導(dǎo)致的數(shù)據(jù)不一致的場(chǎng)景

?收尾工作

?完成【上線開關(guān)】切換，只讀、寫新庫(kù)，完成整體平滑遷移。在無QA參與前提下，驗(yàn)證期間未出現(xiàn)過數(shù)據(jù)丟失、重復(fù)、錯(cuò)誤等異常

?切換完成后，老庫(kù)老表和DRC同步任務(wù)依舊保留了一周的時(shí)間，防止出現(xiàn)場(chǎng)景遺漏，產(chǎn)生數(shù)據(jù)丟失

?46億行大表清理，采用drop+create的方式實(shí)現(xiàn)效率、穩(wěn)定性更高，在業(yè)務(wù)低峰期完成腳本執(zhí)行，大概花費(fèi)10秒的時(shí)間，容器負(fù)載、內(nèi)存等指標(biāo)正常。但是當(dāng)時(shí)碰上了DBA的備份任務(wù)，導(dǎo)致有一個(gè)從庫(kù)主從延遲升高，這個(gè)后續(xù)需要注意

審核編輯 黃宇