背景

采購系統（BIP）在經歷多年演進后，系統整體復雜度和數據量儼然已經極具規模，本文著重討論海量數據的治理

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

痛點：6T磁盤已經單容器最大，無法繼續擴容，剩余磁盤余量過小，難適應未來發展

目標

降低磁盤容量，優化數據模型，提升系統穩定性

調研

首先，既然是要解決存儲容量的問題，就要對詳細的容量情況有個更加清楚的了解。總結下當前存儲容量問題，最大的表是訂單操作日志表lifecycle共1.3T，大于500G的表2張共1.5T；100G~500G的表10張共2.6T。以下是優化前庫里大表（大于100G）的詳細空間占用情況：

其次，確認當前最高效的優化思路是將lifecycle表遷移到其他庫，原因有二：1.lifecycle表的含義是操作日志，在業務上不算訂單域內最核心的模型，風險可控；2.占用空間大，單表46億行數據，空間占用1.3T，一張表占了磁盤空間的22%，優化的ROI高

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

挑戰

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

例子：

方案

整體方案

數據同步 -> 雙讀 -> 雙寫 -> 離線驗證 -> 數據清理

詳細設計

?數據同步，通過DRC實現，歷史全量+增量，其中有以下幾點使用心得：

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

?數據同步過程中不要操作暫停，否則任務重啟后，會重新同步歷史數據，導致數據同步周期變長。詳情參考： 關于全量任務暫停重啟之后數據同步慢的原因

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

?數據驗證問題，當時在歷史數據全量同步完畢后開啟了DRC數據驗證，但是許久未執行完成，收到DRC運維告知出現大量報錯，最終結論是暫時不支持這兩個版本的數據比對（5.5->8.0），這也是為什么整體架構上采用BDP抽數比對數據的主要原因

?數據驗證，業務程序完成雙寫、雙讀改造

?雙寫

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

?具體改造方案：

?新增【驗證開關】，開啟后新/老庫雙寫，另外需要要引入vitess驅動，目前只支持JDK8及以上

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

?注意，開關改造完成上線后，“全量+增量DRC任務”在驗證期間是一直啟用的，也就是說驗證期間，增量數據會寫兩份到新庫

?一部分是實際的生產數據，一部分是待驗證的測試數據。那么就帶來另一個問題，如何識別和區分這兩部分數據，我們采用的方案是：JED建表指定趨勢自增的最小id（200億）+【驗證開關】開啟的時間戳進行區分

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

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

?雙讀

?整體邏輯基本復用寫入期間已有開關，其中針對新庫當中DRC實時同步的數據（上圖：新庫.A）會根據開關開啟時間進行過濾

?其中，在驗證期間，新、老庫都會根據采購單號進行查詢并實際返回老庫的查詢結果，其中還會進行結果比對，出現數據不一致會輸出異常日志關鍵字

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

?補充1：這里基于時間倒排在業務上是準確的，因為lifecycle數據是根據訂單號進行分片的，所以同一訂單一定落在單分片上，也就是說不存在不同分片時鐘偏移的問題，單訂單的操作日志的時間序列一定是按照寫入順序逐漸增加的

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

?補充3：應用的關鍵字告警配置，日志文件僅支持以error.log、err.log、exception.log結尾，并開啟歷史日志的路徑

?最后，雙讀期間共通過業務的實際查詢流量發現數據不一致問題2個+，在并未影響到業務使用的前提下及時發現了系統異常

?離線驗證

?lifecycle歸根結底還是寫多讀少的業務場景，為了防止出現上文數據比對驗證的遺漏，我們會采用BDP離線任務會分別開啟增量數據+歷史全量數據驗證。通過對新、老庫的全量數據字段相互sql inner join的方式完成比對，其中會忽略id和寫入時間，因為新庫的id不是單調遞增、時間精確到了毫秒。期間共發現有效數據問題3個+，均是因為本地事務回滾導致的數據不一致的場景

?收尾工作

?完成【上線開關】切換，只讀、寫新庫，完成整體平滑遷移。在無QA參與前提下，驗證期間未出現過數據丟失、重復、錯誤等異常

?切換完成后，老庫老表和DRC同步任務依舊保留了一周的時間，防止出現場景遺漏，產生數據丟失

?46億行大表清理，采用drop+create的方式實現效率、穩定性更高，在業務低峰期完成腳本執行，大概花費10秒的時間，容器負載、內存等指標正常。但是當時碰上了DBA的備份任務，導致有一個從庫主從延遲升高，這個后續需要注意

審核編輯 黃宇