TiDB x 安能物流 | TiDB 在安能结算系统的应用

业务挑战

安能结算系统作为安能物流最核心的业务系统，承载了总部与末端加盟商网点所有费用结算业务，包括：账户管理、充值、开票、交易、调账、对账、代收、代付、税差等全费用结算业务流程处理。目前该套系统承载业务量：日均 450,000 票，出货量 48,000 吨，支持末端 36,000 家网点实时开单算费扣款和定时批处理调账，日均用户数 3,800，调用量 5,000 万以上。

安能在 2017 年对结算系统进行了重构，选择了当时较为主流的 MySQL+ 数据库代理中间件分库分表架构。直到 2023 年切换到 TiDB 之前，这套 MySQL 伪分布式数据库集群已经运行了 6 年。系统数据量的情况为：核心业务表 4 张，单表字段 360+，共分了 8 个库；单表数据 3亿+，2 TB 大小。系统的并发情况为：30,000 多家网点集中在 16:30 -19:30 三小时内完成开单操作，数据库 QPS 均值为每秒 20,000，系统平均响应时间在 80-100ms 内。

由于业务的不断增长、地区产业布局的变化和网点货量的变化导致原结算系统 MySQL 数据库面临越来越大的挑战，主要表现在：

基于网点编码的分库分表路由规则，导致单库单表数据分布不均，存在数据热点问题；
基于网点编码的分库分表路由规则，当数据量不断增长，数据库主库节点扩展复杂度高；
MySQL 5.7 不支持表结构在线变更，系统变更停机时间长，导致业务可用性降低；
Mycat 不完全支持标准 SQL 语法，导致研发侧代码改动较大；
数据同步到下游进行分析时需要解决多库多表数据合并问题。

解决方案

鉴于面临的挑战，安能于 2020 年启动计划，使用真正的分布式数据库替换现有的 MySQL 伪分布式集群。考虑到结算系统复杂的业务处理流程，安能在数据实时性、准确性、高可用等方面进行了深入的考察和评估，最终选择了 TiDB 作为替换结算系统 MySQL 的最佳解决方案。

为什么选择 TiDB？

首先，TiDB 支持一键水平扩容。第二，TiDB 提供金融级高可用。第三，增加了在线数据的生命周期，同时保证系统响应时长。第四，TiDB 高度兼容 MySQL，原来的这套 MySQL 数据库在代码侧不做改动，可以做到平滑迁移。第五，TiDB 支持表结构的在线变更，减少了系统的停机时间，提高了业务可用性。此外，TiDB 内置了丰富的图形监控界面，提供了完整的闭环运维能力，包括故障分析等，降低了运维成本。

TiDB 在安能从测试到切换上线经历了 3 年左右的时间，主要分为测试和数据校验两个阶段。在测试阶段，安能从 TiDB 3.0 版本开始测试，持续到 5.4 版本，在这个过程中充分测试了 TiDB 每一个重要版本的核心特性和重要功能。测试方法是将生产数据通过消息队列 1:1 引流到 TiDB 来模拟真实结算业务数据写入效率，同时针对不同业务场景及多业务场景组合下进行数据新增、删除、修改、查询功能及性能压测。

在数据校验阶段，使用 DM 将结算 MySQL 8 个库的数据实时同步到 TiDB 中，按照生产环境 1:1 搭建了一套完整的结算系统仿真环境，进行了为期将近一年的数据校验工作，最终于 2023 年春节，将原有运行 6 年的 MySQL 集群无缝平滑切换到 TiDB 上。安能是快递物流行业第一个在结算业务 all in TiDB 的用户。

用户收益

TiDB 上线投产后带来的收益主要有几个方面：

第一，结算系统应用代码几乎无改动，平滑迁移至 TiDB，只是做了数据源的替换。
第二，解决了使用 MySQL 数据库时所面临的所有挑战。
第三，原来 MySQL 环境下，在线数据只能保存 6-8 个月的时间，使用 TiDB 的结算系统在线数据的生命周期翻倍，可以保存两年左右。目前，TiDB 单表的数据量大概是 35 亿，5 TB 大小。在业务高峰期，TiDB 数据库平均响应时长比原来 MySQL 降低了一倍。QPS 从原来 20,000 提升到了 45,000。运维成本方面，综合来看整体降低了 30% 左右。

未来规划

基于 TiDB 的应用实践，未来安能将借助 TiDB 分布式、高可用性、弹性伸缩、大规模数据处理和实时 HTAP 等能力来构建新一代一栈式物流数据平台，加速数字化升级。使用 TiDB 作为一栈式物流数据平台的底座，把安能源端业务系统所采集的所有数据，按照业务主题和数据域统一进行存储，降低不同系统之间数据交互的复杂度，解决数据统一的问题。在一栈式物流数据平台的基础上做相应的数据服务，统一对外提供数据服务平台和 API 接口以及更高阶的数据应用产品。