業務背景

北京科捷物流有限公司于2003年在北京正式成立，是ISO質量管理體系認證企業、國家AAAAA級物流企業、海關AEO高級認證企業，注冊資金1億元，是中國領先的大數據科技公司——神州控股的全資子公司。科捷物流融合B2B和B2C的客戶需求，基于遍布全國的物流網絡與自主知識產權的物流管理系統，為客戶提供定制化的一站式供應鏈服務，在全國擁有231個倉儲中心，總面積超100萬平方米，年運送貨值超5000億元，日發送包裹超40萬個，并在IT、通訊、精密儀器、汽車配件及電商物流領域處于行業領先地位。

?

神州金庫平臺經過十幾年的更新迭代，支撐了科捷物流自營倉儲體系、眾多電商平臺商家、第三方物流公司的核心業務，積累了龐大的數據量。為應對持續增長的業務規模，以及每年多次的電商大促活動，急需尋找更加高效高性能的數據存儲方案。

現狀與挑戰

神州金庫服務端采用微服務架構體系設計，不同的業務模塊采用獨立的集群部署模式，技術棧基于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 中，在更多場景中感受分布式數據庫帶來的魅力，助力業務的高速增長。