TiDB | TiDB在5A级物流企业核心系统的应用与实践

末蓝、 2023-10-02 23:55 28阅读 0赞

#### TiDB在5A级物流企业核心系统的应用与实践 ####

*  前言
 *  一、业务背景
 *   *  科捷物流概况
     *  神州金库简介
 *  二、现状与挑战
 *   *  神州金库现有技术体系
     *  业务挑战
     *  应对方案
 *  三、TiDB解决方案
 *   *  测试
     *  迁移
     *  收益
     *  问题
 *  四、说在最后

## 前言 ##

历经了近半年的测试验证和迁移准备，神州金库3.0核心系统 WMS 正式从 MySQL 迁移到了分布式 HTAP 数据库 TiDB，上线后不久就经历了第一次双11的考验，TiDB 的性能和稳定性表现远超预期，给后续的全平台迁移计划打下了坚实的基础。

神州数码 TiDB 交付团队与科捷物流技术、业务团队紧密配合，完全自主化地实施了整个迁移过程，成为团队在又一新行业成功交付的典型案例。

下面我们就来具体看看吧~

## 一、业务背景 ##

### 科捷物流概况 ###

北京科捷物流有限公司于2003年在北京正式成立，是ISO质量管理体系认证企业、国家AAAAA级物流企业、海关AEO高级认证企业，注册资金1亿元，是中国领先的大数据科技公司——神州控股的全资子公司。

科捷物流融合B2B和B2C的客户需求，基于遍布全国的物流网络与自主知识产权的物流管理系统，为客户提供定制化的一站式供应链服务，在全国拥有231个仓储中心，总面积超100万平方米，年运送货值超5000亿元，日发送包裹超40万个，并在IT、通讯、精密仪器、汽车配件及电商物流领域处于行业领先地位。

![在这里插入图片描述][a3aaee3b589043cc8f794f38cc15e407.png]

### 神州金库简介 ###

神州金库（KINGKOO）是科捷物流结合二十年物流运营经验自主研发，支持云服务模式、实时数据接口的专业物流管理平台，包含有四大核心子系统：

订单管理系统（OMS）

仓储管理系统（WMS）

运输管理系统（TMS）

物流核算系统（BMS）

神州金库实现了物流业务体系的数字化全覆盖，为客户提供了一体化的供应链系统解决方案。

![图片][70ead7db7e5742a4a811eeddd0029445.png]  
神州金库平台经过十几年的更新迭代，支撑了科捷物流自营仓储体系、众多电商平台商家、第三方物流公司的核心业务，积累了庞大的数据量。

为应对持续增长的业务规模，以及每年多次的电商大促活动，急需寻找更加高效高性能的数据存储方案。

## 二、现状与挑战 ##

### 神州金库现有技术体系 ###

神州金库服务端采用微服务架构体系设计，不同的业务模块采用独立的集群部署模式。技术栈基于Java Spring框架构建。数据库目前主要使用 MySQL 主从集群，多台高性能物理机部署，通过 MyCat 做代理层进行读写请求转发。前端接入了多种不同的客户端形态，包括Web、APP、IoT设备、扫描枪、计重器、机器人、报表、第三方API等等。

![图片][7cb89a30acf74714847a83da8a8efc94.png]

### 业务挑战 ###

1、数据量激增带来一系列影响

随着数据量的持续快速增长，MySQL 的存储容量即将达到上限，SQL 响应时间开始变慢，业务受到影响。

如果维持现有的技术架构，下一步势必要引入分表机制，同时扩展容量更大的集群，这其中数据迁移就是非常大的工程量，应用端还要引入额外的 sharding 中间件进行改造，后续数据库维护成本和难度成倍上升。

2、数据报表和分析需求凸显

其次，大量的数据报表和分析需求凸显，仅仅依靠 MySQL 从库提供分析查询能力，效率已经达不到业务需求。某些场景下汇总数据的时效性要求非常高，直接影响到下一步的业务决策，引入传统的T+1离线分析方案无法满足。

3、高并发挑战

除此之外，在应对电商大促场景下需要数据库提供足够的并发能力，响应比平时多出几十倍的流量高峰，同时数据库还可以保证稳定的性能。在平时业务量较小的时候，需要缩减配置控制成本，达到弹性易于扩展的目的。

### 应对方案 ###

基于以上需求，技术团队决定引入分布式数据库代替 MySQL 单机数据库。

在充分考虑了应用和数据双方面迁移难度，以及一系列 POC 验证后，选择使用 TiDB 来替换 MySQL，并用神州金库的核心子系统 WMS 作为首期试点项目。

**选择使用 TiDB 的主要因素有：**

语法层面高度兼容 MySQL，应用端代码中没有使用 TiDB 不支持的特性， 最小程度减少应用改造成本，更换数据库连接串即可。

存储计算分离架构能够满足弹性扩展需求，针对不同时期的业务量动态调整节点达到所需的性能和容量，还可以把不同业务单元的 MySQL 库合并到一个 TiDB 集群中，自带高可用特性省去了 MySQL 从库的硬件成本，数据库维护起来简单高效。

一站式 HTAP 体验，同时满足交易型和分析性业务场景，且对应用端透明。

开源产品，技术社区活跃，产品迭代快，碰到问题容易解决。

## 三、TiDB解决方案 ##

### 测试 ###

为赶在双11之前完成迁移任务，我们做前期做了充足的测试工作，包括应用兼容性测试和改造、多轮带实际业务的压力测试、模拟未来数十倍数据量的性能测试、稳定性测试、高可用测试、生产迁移演练等。

在压测中选取了仓储业务中最核心的出库流程，一共包含6个场景，分别是创建出库单、调度、创建波次、单据复核、单据交接、交接确认。

其中稳定性测试过程中除了使用传统的长时间高压业务负载，还引入了 Chaos Mesh 混沌测试，对CPU、内存、网络等发生异常情况进行模拟，观察 TiDB 在测试期间的表现。从监控显示，压测期间资源使用率和数据库响应时间都非常稳定。  
![在这里插入图片描述][dab933dbc38f475ca0074506a4f1ae60.png]

### 迁移 ###

生产环境TiDB集群部署架构和数据迁移流程如下图所示：  
![图片][3626bb0fd70a469ba844cf797e663f05.png]  
在 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万多。  
![在这里插入图片描述][aafc87e3b5db426ab271f68ba491939b.png]  
在11月1日和11月11日两轮业务高峰期，TiDB 均表现得非常稳定，没有发生任何故障和性能问题。本次迁移的 WMS 3.0在双11期间的流量约占整个金库系统的10%，基于目前 TiDB 的优秀表现，我们有充足的信心把所有业务系统逐步迁移到 TiDB。

短期来看，TiDB 可能需要投入较高的硬件成本，但是随着数据规模增长，TiDB 的性价比会大幅提升。

首先 TiDB 的数据压缩比非常高，三副本所需要的存储空间远低于三台 MySQL 主从节点，这意味着三台 TiKV 可以存储比 MySQL更多的数据。

其次，要提高数据库整体并发能力只需要增加 TiDB Server 节点， 要扩展数据库容量只需要增加 TiKV 节点，从运维成本和硬件成本都要低于 MySQL。

### 问题 ###

**1、SQL 行为一致性问题**

从单机数据库到分布式数据库，除了语法层面的兼容性之外，我们还需要关注相同的 SQL 表现行为是否一致。

例如在早期的测试中发现，当不显式指定排序字段时，MySQL 查询结果能得到固定的顺序，但是在 TiDB 中就会出现结果集顺序不稳定的情况。

这主要是分布式特性带来的表现差异。TiDB 会把扫描数据的请求并行下发给多个 TiKV 节点，如果没有强制使用排序字段，受 TiKV 返回数据时间不一致的影响，最终的汇总结果必然没办法保证顺序，这就要求业务开发过程中要保持良好的 SQL 编写规范。

**2、热点问题**

再就是使用 TiDB 普遍会遇到的热点问题，上线初期由于某张表的索引建立不当，导致某个索引读热点问题非常严重，高峰期能达到100多G/min的流量。  
![图片][2b5b0b14cc42485aaba45a7febf4e468.png]

我们从三个方向进行了优化：

首先找到热点所在的 Region 尝试做切分，会有短暂的效果，但是受 Region 调度影响读热点依旧存在。

然后尝试了自动化 Load Base Split，发现效果也不好。

最后回归 SQL 本身，仔细分析了业务查询逻辑和索引使用情况，重新调整索引后有了明显效果，但由于这是一个业务上小于当前时间的范围查询，某些 Region 的负载还是会高一些 ，再配合定期扫描 Region 流量超出阈值做切分的脚本，热点问题得到完美解决。  
![图片][d11471bf1aaa4dd3aa98f068558165d1.png]

**3、TiDB自身问题**

此外还碰到了 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 中，在更多场景中感受分布式数据库带来的魅力，助力业务的高速增长。

我们致力于用数字技术重构企业价值，助力企业实现数字化转型升级！

更多交流，欢迎联系我们~

[a3aaee3b589043cc8f794f38cc15e407.png]: https://img-blog.csdnimg.cn/a3aaee3b589043cc8f794f38cc15e407.png
[70ead7db7e5742a4a811eeddd0029445.png]: https://img-blog.csdnimg.cn/70ead7db7e5742a4a811eeddd0029445.png
[7cb89a30acf74714847a83da8a8efc94.png]: https://img-blog.csdnimg.cn/7cb89a30acf74714847a83da8a8efc94.png
[dab933dbc38f475ca0074506a4f1ae60.png]: https://img-blog.csdnimg.cn/dab933dbc38f475ca0074506a4f1ae60.png
[3626bb0fd70a469ba844cf797e663f05.png]: https://img-blog.csdnimg.cn/3626bb0fd70a469ba844cf797e663f05.png
[aafc87e3b5db426ab271f68ba491939b.png]: https://img-blog.csdnimg.cn/aafc87e3b5db426ab271f68ba491939b.png
[2b5b0b14cc42485aaba45a7febf4e468.png]: https://img-blog.csdnimg.cn/2b5b0b14cc42485aaba45a7febf4e468.png
[d11471bf1aaa4dd3aa98f068558165d1.png]: https://img-blog.csdnimg.cn/d11471bf1aaa4dd3aa98f068558165d1.png