歷經(jīng)了近半年的測(cè)試驗(yàn)證和遷移準(zhǔn)備，神州金庫(kù)3.0核心系統(tǒng) WMS 正式從 MySQL 遷移到了分布式 HTAP 數(shù)據(jù)庫(kù) TiDB，上線(xiàn)后不久就經(jīng)歷了第一次雙11的考驗(yàn)，TiDB 的性能和穩(wěn)定性表現(xiàn)遠(yuǎn)超預(yù)期，給后續(xù)的全平臺(tái)遷移計(jì)劃打下了堅(jiān)實(shí)的基礎(chǔ)。
神州數(shù)碼 TiDB 交付團(tuán)隊(duì)與科捷物流技術(shù)、業(yè)務(wù)團(tuán)隊(duì)緊密配合，完全自主化地實(shí)施了整個(gè)遷移過(guò)程，成為團(tuán)隊(duì)在又一新行業(yè)成功交付的典型案例。
下面我們就來(lái)具體看看吧~
一、業(yè)務(wù)背景 科捷物流概況北京科捷物流有限公司于2003年在北京正式成立，是ISO質(zhì)量管理體系認(rèn)證企業(yè)、國(guó)家AAAAA級(jí)物流企業(yè)、海關(guān)AEO高級(jí)認(rèn)證企業(yè)，注冊(cè)資金1億元，是中國(guó)領(lǐng)先的大數(shù)據(jù)科技公司——神州控股的全資子公司。
科捷物流融合B2B和B2C的客戶(hù)需求，基于遍布全國(guó)的物流網(wǎng)絡(luò)與自主知識(shí)產(chǎn)權(quán)的物流管理系統(tǒng)，為客戶(hù)提供定制化的一站式供應(yīng)鏈服務(wù)，在全國(guó)擁有231個(gè)倉(cāng)儲(chǔ)中心，總面積超100萬(wàn)平方米，年運(yùn)送貨值超5000億元，日發(fā)送包裹超40萬(wàn)個(gè)，并在IT、通訊、精密儀器、汽車(chē)配件及電商物流領(lǐng)域處于行業(yè)領(lǐng)先地位。
神州金庫(kù)（KINGKOO）是科捷物流結(jié)合二十年物流運(yùn)營(yíng)經(jīng)驗(yàn)自主研發(fā)，支持云服務(wù)模式、實(shí)時(shí)數(shù)據(jù)接口的專(zhuān)業(yè)物流管理平臺(tái)，包含有四大核心子系統(tǒng)：
訂單管理系統(tǒng)（OMS）
倉(cāng)儲(chǔ)管理系統(tǒng)（WMS）
運(yùn)輸管理系統(tǒng)（TMS）
物流核算系統(tǒng)（BMS）
神州金庫(kù)實(shí)現(xiàn)了物流業(yè)務(wù)體系的數(shù)字化全覆蓋，為客戶(hù)提供了一體化的供應(yīng)鏈系統(tǒng)解決方案。
神州金庫(kù)平臺(tái)經(jīng)過(guò)十幾年的更新迭代，支撐了科捷物流自營(yíng)倉(cāng)儲(chǔ)體系、眾多電商平臺(tái)商家、第三方物流公司的核心業(yè)務(wù)，積累了龐大的數(shù)據(jù)量。
為應(yīng)對(duì)持續(xù)增長(zhǎng)的業(yè)務(wù)規(guī)模，以及每年多次的電商大促活動(dòng)，急需尋找更加高效高性能的數(shù)據(jù)存儲(chǔ)方案。
二、現(xiàn)狀與挑戰(zhàn) 神州金庫(kù)現(xiàn)有技術(shù)體系神州金庫(kù)服務(wù)端采用微服務(wù)架構(gòu)體系設(shè)計(jì)，不同的業(yè)務(wù)模塊采用獨(dú)立的集群部署模式。技術(shù)棧基于Java Spring框架構(gòu)建。數(shù)據(jù)庫(kù)目前主要使用 MySQL 主從集群，多臺(tái)高性能物理機(jī)部署，通過(guò) MyCat 做代理層進(jìn)行讀寫(xiě)請(qǐng)求轉(zhuǎn)發(fā)。前端接入了多種不同的客戶(hù)端形態(tài)，包括Web、APP、IoT設(shè)備、掃描槍、計(jì)重器、機(jī)器人、報(bào)表、第三方API等等。
1、數(shù)據(jù)量激增帶來(lái)一系列影響
隨著數(shù)據(jù)量的持續(xù)快速增長(zhǎng)，MySQL 的存儲(chǔ)容量即將達(dá)到上限，SQL 響應(yīng)時(shí)間開(kāi)始變慢，業(yè)務(wù)受到影響。
如果維持現(xiàn)有的技術(shù)架構(gòu)，下一步勢(shì)必要引入分表機(jī)制，同時(shí)擴(kuò)展容量更大的集群，這其中數(shù)據(jù)遷移就是非常大的工程量，應(yīng)用端還要引入額外的 sharding 中間件進(jìn)行改造，后續(xù)數(shù)據(jù)庫(kù)維護(hù)成本和難度成倍上升。
2、數(shù)據(jù)報(bào)表和分析需求凸顯
其次，大量的數(shù)據(jù)報(bào)表和分析需求凸顯，僅僅依靠 MySQL 從庫(kù)提供分析查詢(xún)能力，效率已經(jīng)達(dá)不到業(yè)務(wù)需求。某些場(chǎng)景下匯總數(shù)據(jù)的時(shí)效性要求非常高，直接影響到下一步的業(yè)務(wù)決策，引入傳統(tǒng)的T+1離線(xiàn)分析方案無(wú)法滿(mǎn)足。
3、高并發(fā)挑戰(zhàn)
除此之外，在應(yīng)對(duì)電商大促場(chǎng)景下需要數(shù)據(jù)庫(kù)提供足夠的并發(fā)能力，響應(yīng)比平時(shí)多出幾十倍的流量高峰，同時(shí)數(shù)據(jù)庫(kù)還可以保證穩(wěn)定的性能。在平時(shí)業(yè)務(wù)量較小的時(shí)候，需要縮減配置控制成本，達(dá)到彈性易于擴(kuò)展的目的。
應(yīng)對(duì)方案基于以上需求，技術(shù)團(tuán)隊(duì)決定引入分布式數(shù)據(jù)庫(kù)代替 MySQL 單機(jī)數(shù)據(jù)庫(kù)。
在充分考慮了應(yīng)用和數(shù)據(jù)雙方面遷移難度，以及一系列 POC 驗(yàn)證后，選擇使用 TiDB 來(lái)替換 MySQL，并用神州金庫(kù)的核心子系統(tǒng) WMS 作為首期試點(diǎn)項(xiàng)目。
選擇使用 TiDB 的主要因素有：
語(yǔ)法層面高度兼容 MySQL，應(yīng)用端代碼中沒(méi)有使用 TiDB 不支持的特性， 最小程度減少應(yīng)用改造成本，更換數(shù)據(jù)庫(kù)連接串即可。
存儲(chǔ)計(jì)算分離架構(gòu)能夠滿(mǎn)足彈性擴(kuò)展需求，針對(duì)不同時(shí)期的業(yè)務(wù)量動(dòng)態(tài)調(diào)整節(jié)點(diǎn)達(dá)到所需的性能和容量，還可以把不同業(yè)務(wù)單元的 MySQL 庫(kù)合并到一個(gè) TiDB 集群中，自帶高可用特性省去了 MySQL 從庫(kù)的硬件成本，數(shù)據(jù)庫(kù)維護(hù)起來(lái)簡(jiǎn)單高效。
一站式 HTAP 體驗(yàn)，同時(shí)滿(mǎn)足交易型和分析性業(yè)務(wù)場(chǎng)景，且對(duì)應(yīng)用端透明。
開(kāi)源產(chǎn)品，技術(shù)社區(qū)活躍，產(chǎn)品迭代快，碰到問(wèn)題容易解決。
三、TiDB解決方案 測(cè)試為趕在雙11之前完成遷移任務(wù)，我們做前期做了充足的測(cè)試工作，包括應(yīng)用兼容性測(cè)試和改造、多輪帶實(shí)際業(yè)務(wù)的壓力測(cè)試、模擬未來(lái)數(shù)十倍數(shù)據(jù)量的性能測(cè)試、穩(wěn)定性測(cè)試、高可用測(cè)試、生產(chǎn)遷移演練等。
在壓測(cè)中選取了倉(cāng)儲(chǔ)業(yè)務(wù)中最核心的出庫(kù)流程，一共包含6個(gè)場(chǎng)景，分別是創(chuàng)建出庫(kù)單、調(diào)度、創(chuàng)建波次、單據(jù)復(fù)核、單據(jù)交接、交接確認(rèn)。
其中穩(wěn)定性測(cè)試過(guò)程中除了使用傳統(tǒng)的長(zhǎng)時(shí)間高壓業(yè)務(wù)負(fù)載，還引入了 Chaos Mesh 混沌測(cè)試，對(duì)CPU、內(nèi)存、網(wǎng)絡(luò)等發(fā)生異常情況進(jìn)行模擬，觀(guān)察 TiDB 在測(cè)試期間的表現(xiàn)。從監(jiān)控顯示，壓測(cè)期間資源使用率和數(shù)據(jù)庫(kù)響應(yīng)時(shí)間都非常穩(wěn)定。
生產(chǎn)環(huán)境TiDB集群部署架構(gòu)和數(shù)據(jù)遷移流程如下圖所示：
在 TiDB 集群部署完成后，使用官方提供的數(shù)據(jù)遷移工具 TiDB Data Migration（DM）開(kāi)始把全量和增量數(shù)據(jù)同步到 TiDB 中。
然后找一個(gè)業(yè)務(wù)低峰期切斷應(yīng)用端到 MySQL 的流量，待 DM 把數(shù)據(jù)追平后使用校驗(yàn)工具 Sync-Diff 對(duì)上下游數(shù)據(jù)做一致性檢查，校驗(yàn)完成開(kāi)啟 TiDB 到 MySQL 的回退鏈路，防止切換出現(xiàn)故障可以隨時(shí)回滾到 MySQL。
驗(yàn)證 TiDB Binlog 同步正常以后把應(yīng)用端數(shù)據(jù)庫(kù)連接切換到 TiDB 代理層的VIP，通過(guò) HAProxy 轉(zhuǎn)發(fā)請(qǐng)求到 TiDB 計(jì)算層。
收益遷移之后經(jīng)過(guò)一個(gè)月的觀(guān)察和調(diào)整，各方面的性能指標(biāo)都很穩(wěn)定，P99 延時(shí)基本在100ms以下，服務(wù)器資源使用率普遍較低，各節(jié)點(diǎn)壓力均衡。
10月31日晚上9點(diǎn)左右，迎來(lái)了雙11的第一輪業(yè)務(wù)高峰期，一直持續(xù)到11月3日，在這期間 P99 延時(shí)沒(méi)有明顯波動(dòng)，但是集群 QPS 較平時(shí)上漲了5-8倍，最高峰值達(dá)到1萬(wàn)多。
在11月1日和11月11日兩輪業(yè)務(wù)高峰期，TiDB 均表現(xiàn)得非常穩(wěn)定，沒(méi)有發(fā)生任何故障和性能問(wèn)題。本次遷移的 WMS 3.0在雙11期間的流量約占整個(gè)金庫(kù)系統(tǒng)的10%，基于目前 TiDB 的優(yōu)秀表現(xiàn)，我們有充足的信心把所有業(yè)務(wù)系統(tǒng)逐步遷移到 TiDB。
短期來(lái)看，TiDB 可能需要投入較高的硬件成本，但是隨著數(shù)據(jù)規(guī)模增長(zhǎng)，TiDB 的性?xún)r(jià)比會(huì)大幅提升。
首先 TiDB 的數(shù)據(jù)壓縮比非常高，三副本所需要的存儲(chǔ)空間遠(yuǎn)低于三臺(tái) MySQL 主從節(jié)點(diǎn)，這意味著三臺(tái) TiKV 可以存儲(chǔ)比 MySQL更多的數(shù)據(jù)。
其次，要提高數(shù)據(jù)庫(kù)整體并發(fā)能力只需要增加 TiDB Server 節(jié)點(diǎn)， 要擴(kuò)展數(shù)據(jù)庫(kù)容量只需要增加 TiKV 節(jié)點(diǎn)，從運(yùn)維成本和硬件成本都要低于 MySQL。
問(wèn)題1、SQL 行為一致性問(wèn)題
從單機(jī)數(shù)據(jù)庫(kù)到分布式數(shù)據(jù)庫(kù)，除了語(yǔ)法層面的兼容性之外，我們還需要關(guān)注相同的 SQL 表現(xiàn)行為是否一致。
例如在早期的測(cè)試中發(fā)現(xiàn)，當(dāng)不顯式指定排序字段時(shí)，MySQL 查詢(xún)結(jié)果能得到固定的順序，但是在 TiDB 中就會(huì)出現(xiàn)結(jié)果集順序不穩(wěn)定的情況。
這主要是分布式特性帶來(lái)的表現(xiàn)差異。TiDB 會(huì)把掃描數(shù)據(jù)的請(qǐng)求并行下發(fā)給多個(gè) TiKV 節(jié)點(diǎn)，如果沒(méi)有強(qiáng)制使用排序字段，受 TiKV 返回?cái)?shù)據(jù)時(shí)間不一致的影響，最終的匯總結(jié)果必然沒(méi)辦法保證順序，這就要求業(yè)務(wù)開(kāi)發(fā)過(guò)程中要保持良好的 SQL 編寫(xiě)規(guī)范。
2、熱點(diǎn)問(wèn)題
再就是使用 TiDB 普遍會(huì)遇到的熱點(diǎn)問(wèn)題，上線(xiàn)初期由于某張表的索引建立不當(dāng)，導(dǎo)致某個(gè)索引讀熱點(diǎn)問(wèn)題非常嚴(yán)重，高峰期能達(dá)到100多G/min的流量。
我們從三個(gè)方向進(jìn)行了優(yōu)化：
首先找到熱點(diǎn)所在的 Region 嘗試做切分，會(huì)有短暫的效果，但是受 Region 調(diào)度影響讀熱點(diǎn)依舊存在。
然后嘗試了自動(dòng)化 Load Base Split，發(fā)現(xiàn)效果也不好。
最后回歸 SQL 本身，仔細(xì)分析了業(yè)務(wù)查詢(xún)邏輯和索引使用情況，重新調(diào)整索引后有了明顯效果，但由于這是一個(gè)業(yè)務(wù)上小于當(dāng)前時(shí)間的范圍查詢(xún)，某些 Region 的負(fù)載還是會(huì)高一些 ，再配合定期掃描 Region 流量超出閾值做切分的腳本，熱點(diǎn)問(wèn)題得到完美解決。
3、TiDB自身問(wèn)題
此外還碰到了 TiDB 產(chǎn)品本身的bug，我們生產(chǎn)環(huán)境使用了v5.3.2版本，在該版本下當(dāng) limit offset 值特別大的時(shí)候，如果此時(shí)碰上 IndexHashJoin 會(huì)導(dǎo)致 Session 處于假死狀態(tài)，并且持續(xù)占用 TiDB 節(jié)點(diǎn)內(nèi)存無(wú)法釋放，同時(shí)也無(wú)法kill。
早期因?yàn)檫@個(gè)問(wèn)題出現(xiàn)過(guò)幾次 TiDB 節(jié)點(diǎn) OOM 的情況，只能不定期重啟 TiDB Server 解決。經(jīng)過(guò)仔細(xì)分析排查后定位到這是產(chǎn)品bug，可以通過(guò) HashJoin 關(guān)聯(lián)方式繞過(guò)，最后用 SQL Binding 的形式臨時(shí)處理掉了。不過(guò)業(yè)務(wù)上這樣的 SQL 比較多，目前依然存在這個(gè)問(wèn)題，計(jì)劃通過(guò)版本升級(jí)的方式（v5.4.3）徹底解決。
四、說(shuō)在最后整體來(lái)說(shuō)，此次 WMS 3.0系統(tǒng)遷移非常順利，各方面都能夠滿(mǎn)足預(yù)期，我們也期待未來(lái)把更多的業(yè)務(wù)系統(tǒng)接入到 TiDB 中，在更多場(chǎng)景中感受分布式數(shù)據(jù)庫(kù)帶來(lái)的魅力，助力業(yè)務(wù)的高速增長(zhǎng)。
我們致力于用數(shù)字技術(shù)重構(gòu)企業(yè)價(jià)值，助力企業(yè)實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型升級(jí)！
更多交流，歡迎聯(lián)系我們~
你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購(gòu)，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧
重慶分公司
重慶分公司
