在 DTC（Direct to Customer） 趨勢下，零售企業(yè)紛紛建設面向最終消費者的大前臺，例如自營電商、微信小程序等，使得產品和服務加速迭代。業(yè)務需求對 IT 基礎設施的要求就是“快”和“準”，云盛海宏不斷夯實數據底座來應對外部環(huán)境的變化。

云盛海宏是一家零售業(yè)科技公司，以科技的力量為門店和線上客戶打造 360 度的優(yōu)秀體驗，目前服務中國近萬家的線下門店和千萬級別的線上會員。

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

(相關資料圖)

云海零售系統(tǒng)是支撐著全渠道、全品類運動鞋服零售服務平臺的關鍵系統(tǒng)。最初，云盛海宏采用微服務和 MySQL 分庫分表的方式支撐云海零售系統(tǒng)。隨著業(yè)務的快速發(fā)展，MySQL 集群在復雜報表分析方面的支持不足。為了解決實時報表的問題，云盛海宏引入了 Oracle 作為報表需求的分擔，并通過 Otter 進行數據的實時同步。然而，隨著數據爆發(fā)式增長和需求難度的增加，基于 MyCAT 的分庫分表架構面臨新的挑戰(zhàn)，需要增加或者調整表結構，從維護層面增加了大量人力成本。此外，Oracle 也遇到了單點性能無法擴展、聚合庫分析時效差等問題，云盛海宏開始積極尋求替代方案。

經過詳細的對比測試，包括大數據量的查詢以及復雜 SQL 的查詢性能等方面的細致比較，TiDB 在解決 Oracle 存在的問題方面表現得非常出色且高效。在小規(guī)模試用取得效果之后，云盛海宏最終決定正式引入 TiDB。

解決方案

云海零售系統(tǒng)使用 TiDB 支撐面向最終用戶的營促銷業(yè)務，橫向擴展能力支持海量數據高并發(fā)，通過實時的行為數據分析洞察用戶需求，實現對用戶生命周期的全程追蹤，在 360° 畫像的基礎上進行產品和服務創(chuàng)新。利用 TiDB HTAP 能力，實時獲取跨業(yè)務的聚合數據，支撐企業(yè)運營管理對實時、復雜數據查詢的需求，幾千行的業(yè)務報表 SQL 也能高效執(zhí)行。目前，云盛海宏已部署兩個 TiDB 集群分別承擔前端和后臺的業(yè)務負載，集群總規(guī)模已達百臺，數據量將近 15 TB，業(yè)務高峰期 QPS 達到兩萬多，最大業(yè)務單表達到了 600 GB。

圖：云海零售系統(tǒng)架構示意圖

業(yè)務價值

高度兼容 MySQL 的分布式數據庫

TiDB 原生分布式架構提供靈活的在線擴容和縮容能力，快速響應業(yè)務需求的變化。TiDB 高度兼容 MySQL 協議，應用程序可實現從 MySQL 到 TiDB 的無縫遷移，無需考慮分庫分表以及分布式事務的實現，降低了業(yè)務開發(fā)人員的開發(fā)與學習等隱性成本。

簡化數據棧，節(jié)省硬件資源

TiDB HTAP 混合負載能力為企業(yè)多個業(yè)務提供一棧式數據服務，既能支撐前端業(yè)務的在線事務處理，又能支撐多源數據的實時分析。新架構降低了 80% 的 otter 數據同步通道， 與 MyCAT 分庫分表架構相比，部分庫表冗余度從 10 份降低到 2 份，再加上 TiDB 自帶的壓縮能力，硬件資源可節(jié)省約 50% 左右。

運維工作大幅提效

與管理 MySQL 集群相比，TiDB 可以做到輕量級維護。原先 DBA 以月或者季度為周期需要一次性完成十幾個實例的數據遷移，維護工作量巨大且數據遷移風險極高。引入 TiDB 之后，DBA 不用再為 MySQL 日常巡檢、歸檔和備份這些動作耗費時間，大幅提升了運維工作的效率。

“疫情對我們的業(yè)務帶來了很大沖擊，我們開始發(fā)力做線上業(yè)務，技術側最直接的壓力來自于庫存管理模塊的變化。原本，從接到需要對接淘寶、京東、唯品會、抖音等平臺的需求到最終落地需要三個月甚至半年的時間，但因為我們前期已經切換到了 TiDB，技術棧層面做好了充足的準備，最終只用了兩周時間就完成了單平臺庫存管理模塊的調整”，云盛海宏首席架構師洪亮如是說道。

關鍵詞：