导读

在数字化转型的浪潮中，安能物流通过技术创新不断提升物流效率，迈出了全链路 All in TiDB 的重要一步。本文将深入探讨安能物流如何选择 TiDB 作为核心数据库，以应对高并发、数据处理能力和系统可扩展性等挑战。通过 TiDB 的弹性扩展能力、金融级高可用性和实时 HTAP 特性，安能物流不仅解决了过去的技术瓶颈，还为未来的数字化发展奠定了坚实基础。

本文将从业务系统重构到全链路应用，讲述 TiDB 的技术优势如何助力安能物流在激烈的市场竞争中保持领先地位。

在数字化转型的大潮中，物流行业作为国民经济的重要组成部分，其信息化建设的重要性日益凸显。安能物流，作为国内领先的综合型物流集团，一直致力于通过技术创新提升物流效率。在本技术分享中，我将与大家一起探讨安能物流为何选择全链路 All in TiDB，以及 TiDB 如何助力于安能物流的数字化升级。

安能物流成立于 2010 年，经过 14 年的发展，已经成为国内领先的综合型、创新服务型物流集团。公司以成为中国物流领域高效率的连接者为愿景，为企业组织及消费者提供安全、便捷、优质、高效的物流服务。安能物流在全国拥有 20000 名员工，82 个分拨中心，覆盖全国 99.2% 的乡镇，并在 2021 年 11 月 11 日在香港联合交易所上市，成为“港股快运第一股”。

在业务模式上，我们采用了货运合作商平台模式，即中心直营+网点加盟的方式。通过加盟网络，我们迅速整合了本地现有资源，实现了快速扩张。同时，本地网点通过加盟安能，不仅丰富了产品线，提升了品牌知名度，还能实现快速盈利。我们的产品线非常丰富，包括高端产品如定时达、安心达，重量产品如 3300 产品（3-300kg）和精准零担（300kg 以上），以及增值服务如保价理赔、送货上楼、代收货款和安全包装。此外，我们还提供特色业务，如整车业务和物流金融，以满足不同客户的需求。

1 业务对系统的挑战

2018 年之前，安能主要使用 Oracle 作为数据存储和处理的数据库，随着业务高速发展，业务系统对数据库的并发处理能力和性能提出了越来越高的要求。尤其是每天 16:00-20:00 网点开单业务高峰时段，核心系统 Oracle 数据库的并发处理能力开始捉襟见肘，导致每天需要专职 DBA 值班处理系统遇到的突发问题。再加上这套业务系统逻辑复杂，涉及到从开单、交易、结算、扫描操作最后到签收都是一个单体大集合，并且在数据库中使用了大量的储过程和定时任务来进行业务逻辑和数据的处理，所以每当系统出现异常，影响业务正常操作时，无论是研发还是运维，都很难快速定位和解决问题，系统故障时常发生，研发和运维也常互相推诿扯皮。

2 去 O 已刻不容缓

自 2018 年开始，IT 决定对这套基于 Oracle 数据库的大单体垂直架构核心业务系统进行重构，首先选择将交易算费业务从这套系统中独立拆分出来。因为在原来这套老的系统中，总部和网点的交易算费是使用 Oracle 存储过程和定时任务跑批来完成，当时这套核心的 Oracle 数据库已经出现性能瓶颈，无法在计划内的时间完成交易算费，而纯靠升级服务器存储硬件已无法明显提升数据库性能（就差上 Exadata，成本太高）。

3 去 O 无奈的选择

选择将交易结算业务从原来老系统中拆分独立进行重构，首先要考虑的问题就是使用什么数据库，在 18 年时，业界最主流的数据库除了 Oracle 外，主流开源的也就 MySQL。在系统重构之初，我们就考虑到 MySQL 的单库数据处理能力问题，因为在当时业界还没有一款真正的 MySQL 分布式数据，大部分都是基于中间件代理的方式实现 MySQL 的分库分表，因此我们也采用了比较保守的方案：MySQL+MyCat 中间件数据库架构。

为了避免同一个网点查询或处理数据时出现跨库问题，我们采用了以网点编码作为分库分表的路由规则，除此以外，为了保证单库单表数据量的均衡，我们还将产粮区如华东华南和非产粮区如东北西北区域的网点进行相互组合后放在同一个库同一个表中。即便如此，由于业务的不断增长，地区产业布局的变化，网点货量的变化，导致原结算系统 MySQL 数据库在上线运行一年左右时间后，面临越来越大的挑战，主要表现在：

1. 基于网点编码的分表路由规则，导致单库单表数据分布不均，存在数据热点问题；

2. 基于网点编码的分表路由规则，当数据量不断增长，数据库主库节点扩展复杂度高；

3. MySQL 5.7 不支持表结构在线变更，系统变更停机时间长，导致业务可用性降低；

4. MyCat 不完全支持标准 SQL 语法，导致研发侧代码改动较大；

5. 数据同步到下游进行分析时需要解决多库多表数据合并问题。

4 与 TiDB 的起缘

基于结算系统面临的诸多挑战，我们大概在 20 年开始考虑，要对这套结算系统 MySQL 数据库进行换代升级，除了要考虑到结算系统复杂的业务处理流程外，还要考虑业务快速发展所面临的大规模数据处理的巨大挑战，我们需要一个能够处理大规模数据、既能保证高可用性、又支持实时分析的分布式数据库系统。最终我们选择了 TiDB 作为替换结算 MySQL 的最佳产品，那为什么会选择 TiDB？一切的开始，只因为我们偶然看到了 TiDB 的那句产品介绍：一款真正的可弹性一键扩缩容、金融级高可用、99% 兼容 MySQL 的 HTAP 数据库。

在业务痛点急需寻求一款产品来解决的时候，TiDB 正好能够完全满足，在经过深入的技术调研和测评后，我们选择了 TiDB 作为我们业务系统新一代的数据库产品解决方案。TiDB 在安能首次被应用落地的场景就是“钱”交易结算业务，并且成为该场景下的唯一“候选人”。

1. 弹性扩展能力：TiDB 提供了一键水平扩容或者缩容的功能，可以按需对计算、存储分别进行在线扩容或者缩容。这对于业务量波动较大的物流行业来说，是非常重要的特性，可以有效地应对高峰期的业务需求。

2. 金融高级可用性：TiDB 采用计算与存储分离的多副本存储架构，确保了数据的高可用性和准确性。这对于需要处理大量交易结算数据来说，是保证业务连续性的关键。

3. 大规模数据处理和实时 HTAP特性：TiDB 具备大规模数据处理能力和实时 HTAP（混合事务/分析处理）特性，这使得我们能够增加在线数据的生命周期，同时保证系统的快速响应。

4. 高度兼容 MySQL：TiDB 高度兼容 MySQL，使得应用代码几乎无需改动即可迁移到 TiDB 上，这种兼容性大大降低了技术迁移的成本和风险。

5. 支持表结构的在线变更：TiDB 支持表结构的在线变更，减少了系统变更时的停机时间，提高了业务的可用性。这对于需要频繁更新以适应业务发展来说，是一个重要的优势。

6. 内置图形化监控系统：TiDB 内置了图形化监控系统，提供了完整的闭环监控能力和故障分析能力，降低了运维成本和门槛。这对于 IT 人员相对较少的我们来说，是一个非常有价值的特性。

TiDB 在安能从测试到切换上线经历了 3 年的时间，主要分为 TiDB 测试和数据校验两个阶段。

经验一：TiDB 测试与性能优化

在测试阶段，我们从 3.0 版本开始持续到 5.4 版本，在这个过程中我们充分测试了 TiDB 每一个重要版本的核心特性和重要功能，也测试了 TiDB 推出的诸多工具，见证了 TiDB 产品成长。具体测试方法，我们将生产数据通过消息队列 1:1 引流到 TiDB 来模拟真实结算业务数据写入效率，同时针对不同业务场景及多业务场景组合下进行数据新增、删除、修改、查询功能及性能压测。

在 2020 年 3 月，我们首次安装了 TiDB 集群 v3.0.11，并开始了一系列的性能测试。初期，我们遇到了压测性能问题，特别是在高并发场景下，TiDB 的 TPS（每秒事务处理量）表现不尽如人意。为了解决这一问题，我们采取了多种措施：

1. 增加 TiDB/TiKV 节点：我们通过增加节点来提升集群的处理能力。

2. 配置优化：我们对 TiDB 节点进行了配置优化，包括使用 Haproxy 来平衡负载。

3. 硬件升级：我们对 TiKV 主机进行了压测，并更换了磁盘 SSD 以提升 I/O 性能。

4. 软件升级：我们升级了 TiDB 集群到 v5.0.1，以利用新版本中的性能改进。

通过这些措施，我们成功地将 TPS 提升到了 10000+，满足了我们的业务需求。此外，我们还发现，在相同业务场景下，使用分区表与普通表相比，分区表的性能要差 20-30%。这促使我们进一步优化了数据模型和查询策略。

经验二：TiDB 切换与持续优化

在数据校验阶段，我们使用 DM 将结算 MySQL8 个库的数据实时同步到 TiDB 中，按照生产环境 1:1 搭建了一套完整的仿真结算系统，进行了为期快一年的数据校验工作，最终于 23 年春节，将原结算 MySQL 无缝平滑切换到 TiDB 上。虽然我们不是行业内第一个使用 TiDB 的用户，但在行业内将所有结算业务 all in TiDB 我们是第一个。

在 2023 年 2 月，我们将结算系统迁移到 TiDB v6.5。整个迁移过程非常平滑，结算系统的应用代码无需改动，这得益于 TiDB 对 MySQL 的高度兼容性。迁移后，我们解决了之前使用 MySQL 数据库时面临的所有挑战，包括在线数据库生命周期及数据倾斜、扩容等限制。然而，迁移后我们也遇到了一些问题，例如 SQL 优化器执行计划的不稳定，以及子查询性能较差。为了解决这些问题，我们采取了以下措施：

1. 持续优化 SQL：我们对 SQL 语句进行了持续的优化，以提高执行效率。

2. 切换至 TiDB 后表索引调整：我们对表索引进行了调整，以改善查询性能。

通过这些持续的优化措施，我们不仅提高了系统的性能，还降低了运维成本，提升了业务的可持续使用时长。

快运行业的业务流程相对复杂，涉及从客户下单、网点收发件、干线运输中转、末端派送和签收，总部与一级结算、一级与二级调账、工单、仲裁、理赔、问题件、查件和时效等全链路流程。安能在以往系统建设的过程中，每个业务环节按照项目制独立进行系统设计开发，底层也就使用了不同的数据库技术栈来实现数据的存储和处理，导致业务全链路数据流转交互困难，甚至形成数据孤岛，运维成本极高。

遇到 TiDB 之前的问题

在遇到 TiDB 之前，我们系统所使用的数据库技术栈包括但不限于 Oracle、MySQL、PG、MongoDB 等。重要核心系统都有面临着独特的挑战：

• Oracle：我们使用了 Oracle 的 RAC+ADG+OGG 架构来实现全链路业务的大集中。然而，这种垂直大集中的架构在业务操作和算费交易方面存在瓶颈，尤其是在数据库 Job 数量庞大时，研发和运维团队之间的协作变得非常困难。

• MySQL：为了解决 Oracle 的问题，我们尝试了 MySQL 分库分表的方案，并结合 MyCat 进行重构结算业务。但是，这种伪分布式集群不但在性能上出现了瓶颈，而且还发生了严重的数据倾斜且无法灵活扩展，无法满足我们对真正分布式数据库的需求。

• PG+Citus：为了寻求一款真的分布式数据库产品，我们开始测试 PG+Citus 数据库架构，希望能够找到这种解决方案。然而，经过 4 个月的全场景测试，我们发现它在性能上无法满足我们的要求，并不是一个真正的分布式数据库集群。

全链路采用 TiDB 的决策

TiDB 的出现正好解决了我们这些问题。它以其真正的分布式架构、金融级高可用性、与 MySQL 的高度兼容性以及弹性扩缩容能力，满足了我们对性能、可靠性和未来发展的需求。TiDB 不仅提高了我们的系统性能，还简化了运维工作，使我们能够更灵活地应对业务增长。

基于 TiDB 的这些优势，我们将业务全链路场景都使用了 TiDB。从交易结算到运营操作，从下单签收到干线运输，TiDB 覆盖了我们 90%以上的业务场景。这不仅解决了我们之前使用 Oracle、MySQL 和 PG 时遇到的问题，还加速了 TiDB 在安能更多业务场景的落地。

因此，基于 TiDB 的这些优势和不断下潜全链路业务场景，安能物流 All in TiDB，以支持其业务的持续增长和数字化转型。我们相信，随着 TiDB 技术的不断进步，它将为我们带来更多的业务价值，帮助我们在激烈的市场竞争中保持领先地位。

安能之所以作为物流行业领先公司，我们在信息化建设方面投入了大量的精力和资源，开发了多套

系统来支撑公司的业务运营和管理决策。

安能数字化建设所面临的挑战

随着物流行业信息化水平的不断提升，以及管理赋能动作的前移和下沉，我们的数字化升级转型面临着新的挑战。主要表现在如下几个方面：

1. 数据分散：我们的业务系统众多，每个系统都承载了业务全链路环节中的重要一环，这导致了数据的分散，数据分散在不同的系统中，使得数据整合和分析变得复杂。

2. 数据不准：由于不同业务系统的数据采集和统计分析存在口径差异，即便是相同的数据点，在不同系统或同一时间点上，数据也可能出现不一致的情况。这种数据的不准确性对于决策支持来说是一个巨大的障碍。

3. 架构复杂：我们的技术架构非常复杂。不同的业务场景使用了不同的技术栈，如 A 场景使用 A 技术栈，B 场景使用 B 技术栈，C 场景使用 C 技术栈，这种多样性导致了技术栈的过度使用和管理上的复杂性。

4. 成本与资源的挑战：在公司降本增效的背景下，未来可能会减少对 IT 人员和资源的投入。这给我们提出了一个问题：在资源受限的情况下，IT 如何高效地保障业务的发展和系统的稳定运行？

5. 系统承载能力的挑战：随着业务的增长，现有的系统可能无法承载高峰期的负载并发。这不仅影响用户体验，也对系统的稳定性和可靠性提出了挑战。我们需要找到解决方案，确保系统能够在高负载下稳定运行。

6. 数据处理能力的挑战：结构化和非结构化数据的快速增长，对我们的数据查询和处理能力提出了更高的要求。如果系统无法及时响应数据查询和处理请求，将直接影响到我们的业务决策和客户服务。

TiDB 加速安能数字化建设

TiDB 作为一款分布式数据库，为安能物流提供了强大的数据处理能力和实时 HTAP 特性，帮助我们构建了新一代的一栈式物流数据平台的“地基”。以下是 TiDB 对安能数字化建设的几个关键帮助：

1. 数据整合与实时分析：TiDB 的分布式架构和弹性伸缩能力，使得我们能够整合分散在不同系统的数据，实现数据的集中管理和实时分析。这对于物流行业来说，意味着可以更快速地响应市场变化，优化运营效率。

2. 高可用性和数据一致性：TiDB 的金融级高可用性和数据一致性，保证了我们的业务连续性和数据的准确性。这对于处理大量的交易结算数据至关重要，尤其是在业务高峰期，确保了服务的稳定性。

3. 简化技术栈：TiDB 的高度兼容性和易用性，帮助我们简化了技术栈。我们不再需要维护多种数据库技术，从而降低了运维成本和复杂性。

4. 支持业务创新：TiDB 的实时 HTAP 特性，支持我们在业务运营的同时进行数据分析，为业务创新提供了数据支持。例如，通过分析客户行为和市场趋势，我们可以开发新的服务产品，提升客户体验。

5. 降低成本，提高效率：TiDB 的开源特性和社区支持，帮助我们降低了数据库软件的许可成本。同时，其自动化运维特性减少了对专业 DBA 的依赖，提高了整体的运维效率。

基于 TiDB 的一栈式物流数据平台“地基”

我们的一栈式物流数据平台，是建立在 TiDB 基础之上的。这个平台整合了多个数据主题，包括品效主题、财务主题、运营主题和网点主题等，每个主题都围绕着物流业务的关键方面进行数据的收集、处理和分析。

• 品效主题：关注服务质量和路由时效，帮助我们监控和提升客户满意度。

• 财务主题：管理车线成本和人力成本，优化我们的财务结构。

• 运营主题：涉及货物操作和车辆运力，确保我们的运营效率。

• 网点主题：关注开单收入和签收罚款，帮助我们管理网点的业绩。

在数据平台支撑下，我们建立数据模型及标准，强化数据应用与服务分层，完善数据治理体系。这包括数据集市、业务量分析、品效分析、车辆运力分析、财务成本分析等多个方面。通过这样的架构和产品体系，安能物流能够实现数据的集中管理、高效治理和深度应用，从而推动其数字化转型，提升业务决策的效率和准确性。这不仅体现了 TiDB 在处理大规模、高并发场景下的优势，也展示了我们对于未来物流数据平台发展的前瞻性思考。

我们从社区用户转变成了商业用户，表达了我们对 TiDB 产品的尊重和支持。TiDB 在交易结算业务场景中的表现，证明了它是一款真正能够满足我们需求的数据库产品。我们相信，随着 TiDB 技术的不断进步，它将为我们带来更多的业务价值，帮助我们在激烈的市场竞争中保持领先地位。

通过全链路 All in TiDB，我们不仅解决了现有的技术挑战，还能为未来的数字化转型打下了坚实的基础。TiDB 的高性能、高可用性和易用性，使其成为安能物流技术栈中不可或缺的一部分。随着 TiDB 的不断迭代和优化，我们相信，安能物流将在数字化的道路上越走越远。