TiDB在5A級物流企業(yè)核心系統(tǒng)的應用與實踐

• 前言
• 一、業(yè)務背景
• • 科捷物流概況
  • 神州金庫簡介
• 二、現(xiàn)狀與挑戰(zhàn)
• • 神州金庫現(xiàn)有技術體系
  • 業(yè)務挑戰(zhàn)
  • 應對方案
• 三、TiDB解決方案
• • 測試
  • 遷移
  • 收益
  • 問題
• 四、說在最后

昔陽ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！前言

歷經(jīng)了近半年的測試驗證和遷移準備，神州金庫3.0核心系統(tǒng) WMS 正式從 MySQL 遷移到了分布式 HTAP 數(shù)據(jù)庫 TiDB，上線后不久就經(jīng)歷了第一次雙11的考驗，TiDB 的性能和穩(wěn)定性表現(xiàn)遠超預期，給后續(xù)的全平臺遷移計劃打下了堅實的基礎。

神州數(shù)碼 TiDB 交付團隊與科捷物流技術、業(yè)務團隊緊密配合，完全自主化地實施了整個遷移過程，成為團隊在又一新行業(yè)成功交付的典型案例。

下面我們就來具體看看吧~

一、業(yè)務背景 科捷物流概況

北京科捷物流有限公司于2003年在北京正式成立，是ISO質量管理體系認證企業(yè)、國家AAAAA級物流企業(yè)、海關AEO高級認證企業(yè)，注冊資金1億元，是中國領先的大數(shù)據(jù)科技公司——神州控股的全資子公司。

科捷物流融合B2B和B2C的客戶需求，基于遍布全國的物流網(wǎng)絡與自主知識產(chǎn)權的物流管理系統(tǒng)，為客戶提供定制化的一站式供應鏈服務，在全國擁有231個倉儲中心，總面積超100萬平方米，年運送貨值超5000億元，日發(fā)送包裹超40萬個，并在IT、通訊、精密儀器、汽車配件及電商物流領域處于行業(yè)領先地位。

神州金庫簡介

神州金庫（KINGKOO）是科捷物流結合二十年物流運營經(jīng)驗自主研發(fā)，支持云服務模式、實時數(shù)據(jù)接口的專業(yè)物流管理平臺，包含有四大核心子系統(tǒng)：

訂單管理系統(tǒng)（OMS）

倉儲管理系統(tǒng)（WMS）

運輸管理系統(tǒng)（TMS）

物流核算系統(tǒng)（BMS）

神州金庫實現(xiàn)了物流業(yè)務體系的數(shù)字化全覆蓋，為客戶提供了一體化的供應鏈系統(tǒng)解決方案。

神州金庫平臺經(jīng)過十幾年的更新迭代，支撐了科捷物流自營倉儲體系、眾多電商平臺商家、第三方物流公司的核心業(yè)務，積累了龐大的數(shù)據(jù)量。

為應對持續(xù)增長的業(yè)務規(guī)模，以及每年多次的電商大促活動，急需尋找更加高效高性能的數(shù)據(jù)存儲方案。

二、現(xiàn)狀與挑戰(zhàn) 神州金庫現(xiàn)有技術體系

神州金庫服務端采用微服務架構體系設計，不同的業(yè)務模塊采用獨立的集群部署模式。技術棧基于Java Spring框架構建。數(shù)據(jù)庫目前主要使用 MySQL 主從集群，多臺高性能物理機部署，通過 MyCat 做代理層進行讀寫請求轉發(fā)。前端接入了多種不同的客戶端形態(tài)，包括Web、APP、IoT設備、掃描槍、計重器、機器人、報表、第三方API等等。

業(yè)務挑戰(zhàn)

1、數(shù)據(jù)量激增帶來一系列影響

隨著數(shù)據(jù)量的持續(xù)快速增長，MySQL 的存儲容量即將達到上限，SQL 響應時間開始變慢，業(yè)務受到影響。

如果維持現(xiàn)有的技術架構，下一步勢必要引入分表機制，同時擴展容量更大的集群，這其中數(shù)據(jù)遷移就是非常大的工程量，應用端還要引入額外的 sharding 中間件進行改造，后續(xù)數(shù)據(jù)庫維護成本和難度成倍上升。

2、數(shù)據(jù)報表和分析需求凸顯

其次，大量的數(shù)據(jù)報表和分析需求凸顯，僅僅依靠 MySQL 從庫提供分析查詢能力，效率已經(jīng)達不到業(yè)務需求。某些場景下匯總數(shù)據(jù)的時效性要求非常高，直接影響到下一步的業(yè)務決策，引入傳統(tǒng)的T+1離線分析方案無法滿足。

3、高并發(fā)挑戰(zhàn)

除此之外，在應對電商大促場景下需要數(shù)據(jù)庫提供足夠的并發(fā)能力，響應比平時多出幾十倍的流量高峰，同時數(shù)據(jù)庫還可以保證穩(wěn)定的性能。在平時業(yè)務量較小的時候，需要縮減配置控制成本，達到彈性易于擴展的目的。

應對方案

基于以上需求，技術團隊決定引入分布式數(shù)據(jù)庫代替 MySQL 單機數(shù)據(jù)庫。

在充分考慮了應用和數(shù)據(jù)雙方面遷移難度，以及一系列 POC 驗證后，選擇使用 TiDB 來替換 MySQL，并用神州金庫的核心子系統(tǒng) WMS 作為首期試點項目。

選擇使用 TiDB 的主要因素有：

語法層面高度兼容 MySQL，應用端代碼中沒有使用 TiDB 不支持的特性， 最小程度減少應用改造成本，更換數(shù)據(jù)庫連接串即可。

存儲計算分離架構能夠滿足彈性擴展需求，針對不同時期的業(yè)務量動態(tài)調(diào)整節(jié)點達到所需的性能和容量，還可以把不同業(yè)務單元的 MySQL 庫合并到一個 TiDB 集群中，自帶高可用特性省去了 MySQL 從庫的硬件成本，數(shù)據(jù)庫維護起來簡單高效。

一站式 HTAP 體驗，同時滿足交易型和分析性業(yè)務場景，且對應用端透明。

開源產(chǎn)品，技術社區(qū)活躍，產(chǎn)品迭代快，碰到問題容易解決。

三、TiDB解決方案 測試

為趕在雙11之前完成遷移任務，我們做前期做了充足的測試工作，包括應用兼容性測試和改造、多輪帶實際業(yè)務的壓力測試、模擬未來數(shù)十倍數(shù)據(jù)量的性能測試、穩(wěn)定性測試、高可用測試、生產(chǎn)遷移演練等。

在壓測中選取了倉儲業(yè)務中最核心的出庫流程，一共包含6個場景，分別是創(chuàng)建出庫單、調(diào)度、創(chuàng)建波次、單據(jù)復核、單據(jù)交接、交接確認。

其中穩(wěn)定性測試過程中除了使用傳統(tǒng)的長時間高壓業(yè)務負載，還引入了 Chaos Mesh 混沌測試，對CPU、內(nèi)存、網(wǎng)絡等發(fā)生異常情況進行模擬，觀察 TiDB 在測試期間的表現(xiàn)。從監(jiān)控顯示，壓測期間資源使用率和數(shù)據(jù)庫響應時間都非常穩(wěn)定。

遷移

生產(chǎn)環(huán)境TiDB集群部署架構和數(shù)據(jù)遷移流程如下圖所示：

在 TiDB 集群部署完成后，使用官方提供的數(shù)據(jù)遷移工具 TiDB Data Migration（DM）開始把全量和增量數(shù)據(jù)同步到 TiDB 中。

然后找一個業(yè)務低峰期切斷應用端到 MySQL 的流量，待 DM 把數(shù)據(jù)追平后使用校驗工具 Sync-Diff 對上下游數(shù)據(jù)做一致性檢查，校驗完成開啟 TiDB 到 MySQL 的回退鏈路，防止切換出現(xiàn)故障可以隨時回滾到 MySQL。

驗證 TiDB Binlog 同步正常以后把應用端數(shù)據(jù)庫連接切換到 TiDB 代理層的VIP，通過 HAProxy 轉發(fā)請求到 TiDB 計算層。

收益

遷移之后經(jīng)過一個月的觀察和調(diào)整，各方面的性能指標都很穩(wěn)定，P99 延時基本在100ms以下，服務器資源使用率普遍較低，各節(jié)點壓力均衡。

10月31日晚上9點左右，迎來了雙11的第一輪業(yè)務高峰期，一直持續(xù)到11月3日，在這期間 P99 延時沒有明顯波動，但是集群 QPS 較平時上漲了5-8倍，最高峰值達到1萬多。

在11月1日和11月11日兩輪業(yè)務高峰期，TiDB 均表現(xiàn)得非常穩(wěn)定，沒有發(fā)生任何故障和性能問題。本次遷移的 WMS 3.0在雙11期間的流量約占整個金庫系統(tǒng)的10%，基于目前 TiDB 的優(yōu)秀表現(xiàn)，我們有充足的信心把所有業(yè)務系統(tǒng)逐步遷移到 TiDB。

短期來看，TiDB 可能需要投入較高的硬件成本，但是隨著數(shù)據(jù)規(guī)模增長，TiDB 的性價比會大幅提升。

首先 TiDB 的數(shù)據(jù)壓縮比非常高，三副本所需要的存儲空間遠低于三臺 MySQL 主從節(jié)點，這意味著三臺 TiKV 可以存儲比 MySQL更多的數(shù)據(jù)。

其次，要提高數(shù)據(jù)庫整體并發(fā)能力只需要增加 TiDB Server 節(jié)點， 要擴展數(shù)據(jù)庫容量只需要增加 TiKV 節(jié)點，從運維成本和硬件成本都要低于 MySQL。

問題

1、SQL 行為一致性問題

從單機數(shù)據(jù)庫到分布式數(shù)據(jù)庫，除了語法層面的兼容性之外，我們還需要關注相同的 SQL 表現(xiàn)行為是否一致。

例如在早期的測試中發(fā)現(xiàn)，當不顯式指定排序字段時，MySQL 查詢結果能得到固定的順序，但是在 TiDB 中就會出現(xiàn)結果集順序不穩(wěn)定的情況。

這主要是分布式特性帶來的表現(xiàn)差異。TiDB 會把掃描數(shù)據(jù)的請求并行下發(fā)給多個 TiKV 節(jié)點，如果沒有強制使用排序字段，受 TiKV 返回數(shù)據(jù)時間不一致的影響，最終的匯總結果必然沒辦法保證順序，這就要求業(yè)務開發(fā)過程中要保持良好的 SQL 編寫規(guī)范。

2、熱點問題

再就是使用 TiDB 普遍會遇到的熱點問題，上線初期由于某張表的索引建立不當，導致某個索引讀熱點問題非常嚴重，高峰期能達到100多G/min的流量。

我們從三個方向進行了優(yōu)化：

首先找到熱點所在的 Region 嘗試做切分，會有短暫的效果，但是受 Region 調(diào)度影響讀熱點依舊存在。

然后嘗試了自動化 Load Base Split，發(fā)現(xiàn)效果也不好。

最后回歸 SQL 本身，仔細分析了業(yè)務查詢邏輯和索引使用情況，重新調(diào)整索引后有了明顯效果，但由于這是一個業(yè)務上小于當前時間的范圍查詢，某些 Region 的負載還是會高一些 ，再配合定期掃描 Region 流量超出閾值做切分的腳本，熱點問題得到完美解決。

3、TiDB自身問題

此外還碰到了 TiDB 產(chǎn)品本身的bug，我們生產(chǎn)環(huán)境使用了v5.3.2版本，在該版本下當 limit offset 值特別大的時候，如果此時碰上 IndexHashJoin 會導致 Session 處于假死狀態(tài)，并且持續(xù)占用 TiDB 節(jié)點內(nèi)存無法釋放，同時也無法kill。

早期因為這個問題出現(xiàn)過幾次 TiDB 節(jié)點 OOM 的情況，只能不定期重啟 TiDB Server 解決。經(jīng)過仔細分析排查后定位到這是產(chǎn)品bug，可以通過 HashJoin 關聯(lián)方式繞過，最后用 SQL Binding 的形式臨時處理掉了。不過業(yè)務上這樣的 SQL 比較多，目前依然存在這個問題，計劃通過版本升級的方式（v5.4.3）徹底解決。

四、說在最后

整體來說，此次 WMS 3.0系統(tǒng)遷移非常順利，各方面都能夠滿足預期，我們也期待未來把更多的業(yè)務系統(tǒng)接入到 TiDB 中，在更多場景中感受分布式數(shù)據(jù)庫帶來的魅力，助力業(yè)務的高速增長。

我們致力于用數(shù)字技術重構企業(yè)價值，助力企業(yè)實現(xiàn)數(shù)字化轉型升級！

更多交流，歡迎聯(lián)系我們~

你是否還在尋找穩(wěn)定的海外服務器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準確流量調(diào)度確保服務器高可用性，企業(yè)級服務器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

分享題目：TiDB|TiDB在5A級物流企業(yè)核心系統(tǒng)的應用與實踐-創(chuàng)新互聯(lián)
分享地址：http://aaarwkj.com/article10/dohpdo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設、商城網(wǎng)站、定制網(wǎng)站、面包屑導航、云服務器、服務器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)