導讀：在經過了近半年的測試驗證和遷移準備之後，神州金庫3.0核心系統 WMS 正式從 MySQL 遷移到了分散式 HTAP 資料庫 TiDB，上線後不久即經歷了第一次雙11的考驗，TiDB的效能和穩定性表現遠超預期，給後續的全平臺遷移計劃打下了堅實的基礎。神州數碼 TiDB 交付團隊與科捷物流技術、業務團隊緊密配合，完全自主化地實施了整個遷移過程，成為團隊在又一新行業成功交付的典型案例。
業務背景
北京科捷物流有限公司於2003年在北京正式成立，是ISO質量管理體系認證企業、國家AAAAA級物流企業、海關AEO高階認證企業，註冊資金1億元，是中國領先的大資料科技公司——神州控股的全資子公司。科捷物流融合B2B和B2C的客戶需求，基於遍佈全國的物流網路與自主智慧財產權的物流管理系統，為客戶提供定製化的一站式供應鏈服務，在全國擁有231個倉儲中心，總面積超100萬平方米，年運送貨值超5000億元，日傳送包裹超40萬個，並在IT、通訊、精密儀器、汽車配件及電商物流領域處於行業領先地位。
神州金庫（KINGKOO）是科捷物流結合二十年物流運營經驗自主研發，支援雲服務模式、實時資料介面的專業物流管理平臺，包含有四大核心子系統：訂單管理系統（OMS）、倉儲管理系統（WMS）、運輸管理系統（TMS）、物流核算系統（BMS），實現了物流業務體系的數字化全覆蓋，為客戶提供了一體化的供應鏈系統解決方案。
神州金庫平臺經過十幾年的更新迭代，支撐了科捷物流自營倉儲體系、眾多電商平臺商家、第三方物流公司的核心業務，積累了龐大的資料量。為應對持續增長的業務規模，以及每年多次的電商大促活動，急需尋找更加高效高效能的資料儲存方案。
現狀與挑戰
神州金庫服務端採用微服務架構體系設計，不同的業務模組採用獨立的叢集部署模式，技術棧基於Java Spring框架構建，資料庫目前主要使用 MySQL 主從叢集，多臺高效能物理機部署，透過 MyCat 做代理層進行讀寫請求轉發。前端接入了多種不同的客戶端形態，包括Web、APP、IoT裝置、掃描槍、計重器、機器人、報表、第三方API等等。
隨著資料量的持續快速增長，MySQL 的儲存容量即將達到上限，SQL 響應時間開始變慢，業務受到影響。如果維持現有的技術架構，下一步勢必要引入分表機制，同時擴充套件容量更大的叢集，這其中資料遷移就是非常大的工程量，應用端還要引入額外的 sharding 中介軟體進行改造，後續資料庫維護成本和難度成倍上升。
其次，大量的資料包表和分析需求凸顯，僅僅依靠 MySQL 從庫提供分析查詢能力，效率已經達不到業務需求。某些場景下彙總資料的時效性要求非常高，直接影響到下一步的業務決策，引入傳統的T+1離線分析方案無法滿足。
除此之外，在應對電商大促場景下需要資料庫提供足夠的併發能力，響應比平時多出幾十倍的流量高峰，同時資料庫還可以保證穩定的效能。在平時業務量較小的時候，需要縮減配置控制成本，達到彈性易於擴充套件的目的。
基於以上需求，技術團隊決定引入分散式資料庫代替 MySQL 單機資料庫，在充分考慮了應用和資料雙方面遷移難度，以及一系列 POC 驗證後，選擇了使 TiDB 來替換 MySQL，並用神州金庫的核心子系統 WMS 作為首期試點專案。
選擇使用 TiDB 的主要因素有：
-
1、語法層面高度相容 MySQL，應用端程式碼中沒有使用 TiDB 不支援的特性， 最小程度減少應用改造成本，更換資料庫連線串即可。
-
2、儲存計算分離架構能夠滿足彈性擴充套件需求，針對不同時期的業務量動態調整節點達到所需的效能和容量，還可以把不同業務單元的 MySQL 庫合併到一個 TiDB 叢集中，自帶高可用特性省去了 MySQL 從庫的硬體成本，資料庫維護起來簡單高效。
-
3、一站式 HTAP 體驗，同時滿足交易型和分析性業務場景，且對應用端透明。
-
4、開源產品，技術社群活躍，產品迭代快，碰到問題容易解決。
TiDB 解決方案
測試
為趕在雙11之前完成遷移任務，我們做前期做了充足的測試工作，包括應用相容性測試和改造、多輪帶實際業務的壓力測試、模擬未來數十倍資料量的效能測試、穩定性測試、高可用測試、生產遷移演練等。在壓測中選取了倉儲業務中最核心的出庫流程，一共包含6個場景，分別是建立出庫單、排程、建立波次、單據複核、單據交接、交接確認。
其中穩定性測試過程中除了使用傳統的長時間高壓業務負載，還引入了 Chaos Mesh 混沌測試，對CPU、記憶體、網路等發生異常情況進行模擬，觀察 TiDB 在測試期間的表現。從監控顯示，壓測期間資源使用率和資料庫響應時間都非常穩定。
遷移
生產環境 TiDB 叢集部署架構和資料遷移流程如下圖所示：
在 TiDB 叢集部署完成後，使用官方提供的資料遷移工具 TiDB Data Migration（DM）開始把全量和增量資料同步到 TiDB 中，然後找一個業務低峰期切斷應用端到 MySQL 的流量，待 DM 把資料追平後使用校驗工具 Sync-Diff 對上下游資料做一致性檢查，校驗完成開啟 TiDB 到 MySQL 的回退鏈路，防止切換出現故障可以隨時回滾到 MySQL。驗證 TiDB Binlog 同步正常以後把應用端資料庫連線切換到 TiDB 代理層的VIP，透過 HAProxy 轉發請求到 TiDB 計算層。
收益
遷移之後經過一個月的觀察和調整，各方面的效能指標都很穩定，P99 延時基本在100ms以下，伺服器資源使用率普遍較低，各節點壓力均衡。10月31日晚上9點左右，迎來了雙11的第一輪業務高峰期，一直持續到11月3日，在這期間 P99 延時沒有明顯波動，但是叢集 QPS 較平時上漲了5-8倍，最高峰值達到1萬多。
在11月1日和11月11日兩輪業務高峰期，TiDB 均表現得非常穩定，沒有發生任何故障和效能問題。本次遷移的 WMS 3.0在雙11期間的流量約佔整個金庫系統的10%，基於目前 TiDB 的優秀表現，我們有充足的信心把所有業務系統逐步遷移到 TiDB。
短期來看，TiDB 可能需要投入較高的硬體成本，但是隨著資料規模增長，TiDB 的價效比會大幅提升。首先 TiDB 的資料壓縮比非常高，三副本所需要的儲存空間遠低於三臺 MySQL 主從節點，這意味著三臺 TiKV 可以儲存比 MySQL更多的資料。其次，要提高資料庫整體併發能力只需要增加 TiDB Server 節點， 要擴充套件資料庫容量只需要增加 TiKV 節點，從運維成本和硬體成本都要低於 MySQL。
問題
從單機資料庫到分散式資料庫，除了語法層面的相容性之外，我們還需要關注相同的 SQL 表現行為是否一致。
例如在早期的測試中發現，當不顯式指定排序欄位時，MySQL 查詢結果能得到固定的順序，但是在 TiDB 中就會出現結果集順序不穩定的情況，這主要是分散式特性帶來的表現差異。TiDB 會把掃描資料的請求並行下發給多個 TiKV 節點，如果沒有強制使用排序欄位，受 TiKV 返回資料時間不一致的影響，最終的彙總結果必然沒辦法保證順序，這就要求業務開發過程中要保持良好的 SQL 編寫規範。
再就是使用 TiDB 普遍會遇到的熱點問題，上線初期由於某張表的索引建立不當，導致某個索引讀熱點問題非常嚴重，高峰期能達到100多G/min的流量。
我們從三個方向進行了最佳化，首先找到熱點所在的 Region 嘗試做切分，會有短暫的效果，但是受 Region 排程影響讀熱點依舊存在。然後嘗試了自動化 Load Base Split，發現效果也不好。最後迴歸 SQL 本身，仔細分析了業務查詢邏輯和索引使用情況，重新調整索引後有了明顯效果，但由於這是一個業務上小於當前時間的範圍查詢，某些 Region 的負載還是會高一些 ，再配合定期掃描 Region 流量超出閾值做切分的指令碼，熱點問題得到完美解決。
此外還碰到了 TiDB 產品本身的bug，我們生產環境使用了v5.3.2版本，在該版本下當 limit offset 值特別大的時候，如果此時碰上 IndexHashJoin 會導致 Session 處於假死狀態，並且持續佔用 TiDB 節點記憶體無法釋放，同時也無法kill。早期因為這個問題出現過幾次 TiDB 節點 OOM 的情況，只能不定期重啟 TiDB Server 解決。經過仔細分析排查後定位到這是產品bug，可以透過 HashJoin 關聯方式繞過，最後用 SQL Binding 的形式臨時處理掉了。不過業務上這樣的 SQL 比較多，目前依然存在這個問題，計劃透過版本升級的方式（v5.4.3）徹底解決。
未來展望
整體來說，此次 WMS 3.0系統遷移非常順利，各方面都能夠滿足預期，我們也期待未來把更多的業務系統接入到 TiDB 中，在更多場景中感受分散式資料庫帶來的魅力，助力業務的高速增長。
作者介紹：hey-hoho，來自神州數碼鈦合金戰隊，是一支致力於為企業提供分散式資料庫TiDB整體解決方案的專業技術團隊。團隊成員擁有豐富的資料庫從業背景，全部擁有TiDB高階資格證照，並活躍於TiDB開源社群，是官方認證合作伙伴。目前已為10+客戶提供了專業的TiDB交付服務，涵蓋金融、證券、物流、電力、政府、零售等重點行業。