TiDB在科捷物流神州金库核心系统的应用与实践

业务背景

北京科捷物流有限公司于2003年在北京正式成立，是ISO质量管理体系认证企业、国家AAAAA级物流企业、海关AEO高级认证企业，注册资金1亿元，是中国领先的大数据科技公司——神州控股的全资子公司。科捷物流融合B2B和B2C的客户需求，基于遍布全国的物流网络与自主知识产权的物流管理系统，为客户提供定制化的一站式供应链服务，在全国拥有231个仓储中心，总面积超100万平方米，年运送货值超5000亿元，日发送包裹超40万个，并在IT、通讯、精密仪器、汽车配件及电商物流领域处于行业领先地位。

企业微信截图_20221121174426.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20221121174426-1669633959040.png" />

神州金库平台经过十几年的更新迭代，支撑了科捷物流自营仓储体系、众多电商平台商家、第三方物流公司的核心业务，积累了庞大的数据量。为应对持续增长的业务规模，以及每年多次的电商大促活动，急需寻找更加高效高性能的数据存储方案。

现状与挑战

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

企业微信截图_20221123154720.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20221123154720-1669633988762.png" />

随着数据量的持续快速增长，MySQL 的存储容量即将达到上限，SQL 响应时间开始变慢，业务受到影响。如果维持现有的技术架构，下一步势必要引入分表机制，同时扩展容量更大的集群，这其中数据迁移就是非常大的工程量，应用端还要引入额外的 sharding 中间件进行改造，后续数据库维护成本和难度成倍上升。

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

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

基于以上需求，技术团队决定引入分布式数据库代替 MySQL 单机数据库，在充分考虑了应用和数据双方面迁移难度，以及一系列 POC 验证后，选择了使 TiDB 来替换 MySQL，并用神州金库的核心子系统 WMS 作为首期试点项目。

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

1、语法层面高度兼容 MySQL，应用端代码中没有使用 TiDB 不支持的特性，最小程度减少应用改造成本，更换数据库连接串即可。
2、存储计算分离架构能够满足弹性扩展需求，针对不同时期的业务量动态调整节点达到所需的性能和容量，还可以把不同业务单元的 MySQL 库合并到一个 TiDB 集群中，自带高可用特性省去了 MySQL 从库的硬件成本，数据库维护起来简单高效。
3、一站式 HTAP 体验，同时满足交易型和分析性业务场景，且对应用端透明。
4、开源产品，技术社区活跃，产品迭代快，碰到问题容易解决。

tidb-解决方案">TiDB 解决方案

测试

为赶在双11之前完成迁移任务，我们做前期做了充足的测试工作，包括应用兼容性测试和改造、多轮带实际业务的压力测试、模拟未来数十倍数据量的性能测试、稳定性测试、高可用测试、生产迁移演练等。在压测中选取了仓储业务中最核心的出库流程，一共包含6个场景，分别是创建出库单、调度、创建波次、单据复核、单据交接、交接确认。

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

图片1.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E5%9B%BE%E7%89%871-1669634041495.png" />

图片2.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E5%9B%BE%E7%89%872-1669634054466.png" />

迁移

生产环境 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万多。

企业微信截图_20221124183156.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20221124183156-1669634146011.png" />

在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的流量。

企业微信截图_20221125154234.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20221125154234-1669634172555.png" />

我们从三个方向进行了优化，首先找到热点所在的 Region 尝试做切分，会有短暂的效果，但是受 Region 调度影响读热点依旧存在。然后尝试了自动化 Load Base Split，发现效果也不好。最后回归 SQL 本身，仔细分析了业务查询逻辑和索引使用情况，重新调整索引后有了明显效果，但由于这是一个业务上小于当前时间的范围查询，某些 Region 的负载还是会高一些，再配合定期扫描 Region 流量超出阈值做切分的脚本，热点问题得到完美解决。企业微信截图_20221125154108.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20221125154108-1669634204385.png" />

企业微信截图_20221125154108.png tidb-blog.oss-cn-beijing.aliyuncs.com/media/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20221125154108-1669634204385.png" />

此外还碰到了 TiDB 产品本身的bug，我们生产环境使用了v5.3.2版本，在该版本下当 limit offset 值特别大的时候，如果此时碰上 IndexHashJoin 会导致 Session 处于假死状态，并且持续占用 TiDB 节点内存无法释放，同时也无法kill。早期因为这个问题出现过几次 TiDB 节点 OOM 的情况，只能不定期重启 TiDB Server 解决。经过仔细分析排查后定位到这是产品bug，可以通过 HashJoin 关联方式绕过，最后用 SQL Binding 的形式临时处理掉了。不过业务上这样的 SQL 比较多，目前依然存在这个问题，计划通过版本升级的方式（v5.4.3）彻底解决。