T3 出行：网约车全栈分布式数据库升级实践

数据库稳，则系统稳。如果没有一个稳定的数据库系统，就不可能有一个稳定的交易系统。为了保障系统高可用，T3 出行采用双云双地图战略，但云上系统如何快速切换，数据如何流转是 T3 出行数据库团队不得不面对的课题。

OceanBase数据库官方博客

1205人浏览 · 2025-03-20 14:55:50

OceanBase数据库官方博客 · 2025-03-20 14:55:50 发布

现今，网约车已成为民众日常出行不可或缺的选择。伴随“互联网+出行”模式的快速推进，庞大的出行数据应运而生，如同构建了城市交通系统的数字神经脉络。与此同时，对高效数据存储与深入数据分析的需求也在持续攀升。

T3 出行于2019年应运而生，是由一汽集团、东风汽车和长安汽车这三大中央企业联手创建的智能出行服务平台。历经五年的蓬勃发展，T3 出行的日订单峰值已跃升至300万以上。随着T3 出行业务的急剧扩张，一个稳定可靠、高性能且安全的数据库系统变得至关重要。在全面评估性能、成本等各项因素后，T3 出行决定采用OB Cloud 作为数据库技术的坚强后盾。

1、T3出行的数据库挑战：海量数据下的性能瓶颈

T3 出行研发总监高建丰经常对团队成员强调：“数据库稳，则系统稳。如果没有一个稳定的数据库系统，就不可能有一个稳定的交易系统。”

T3 出行最初将其数据库部署在 MySQL 上。然而，随着订单量的快速增长，传统集中式数据库面临的挑战逐渐显现。高建丰分享道，尽管 MySQL 能够支持很高的 KPS（每秒查询次数），但其存储的数据量却非常有限。当数据量达到几百万条时，系统便接近其上限，从而导致性能下降和内存消耗增加等问题。

为了扩容，最常见的方式就是分库分表，但分库分表也存在技术局限性。首先，查询性能、灵活性不强。通常只能按照订单、司机或乘客等单个特定维度查询数据，不能进行多维度的查询。其次，数据库的水平扩展困难，且容易造成资源浪费。根据 T3 出行的业务画像，波峰波谷明显，非早晚高峰时段，大量的 MySQL 资源日常闲置；而早晚高峰时段，MySQL 连接数与规格绑定，数量有限，容易出现资源碎片化，导致数据库使用成本不断增加。

为了解决扩容问题，T3 出行的研发团队采用了分库分表策略，但这一方法的技术局限性也很快显现。

首先，分库分表后的查询性能和灵活性较差，通常只能按照订单、司机或乘客等单一特定维度进行查询，难以支持多维度的复杂查询。
其次，数据库的水平扩展变得更加困难。早晚高峰时段，MySQL连接数与规格绑定，容易出现资源碎片化，导致数据库使用成本不断增加，而在非高峰时段，大量 MySQL 资源处于闲置状态，造成资源浪费。
另外，即便分了八库八表，海量数据存储困难的问题依然存在，三四年前的历史数据如何存储？有人提出使用 MySQL+HBase+MongoDB 等解决方案支撑数据存储与查询。但一方案也带了来新的问题：技术栈众多。目前，T3 出行系统运行着的 TP 和 AP 类数据库近 20 个。

“大部分运维同学是很崩溃的。”高建丰说到：“近 20 个数据库需要耗费大量的资源和人力去维护，而且也没有哪个运维同学对这 20 个技术栈都非常熟悉。”

而更大问题在于，数据从 TP 数据库同步到 AP 数据库，涉及数据复制、提取、清洗等环节，每一次数据同步都有可能引起数据延迟或丢失，难以实现 100% 的完美迁移。

为了保障系统高可用，T3 出行采用双云双地图战略，交易系统部署在阿里云上，大数据系统部署在腾讯云上，利用多云架构分散风险。但云上系统如何快速切换，数据如何流转是 T3 出行数据库团队不得不面对的课题。

2、海量数据最优解：一体化云数据库OB Cloud

基于上述问题，T3 出行开始寻求新的数据解决方案。

高建丰认为，满足 T3 出行海量数据的数据库，应该满足四大条件：

MySQL 数据库可以快速、平滑地迁移，不需要投入太多人力资源，也无需修改代码，要对业务层无感知。
替换之后，性能需要有所提升。
成本上，需要通过数据压缩、CPU 资源利用等多种角度降低数据库成本。
运维层面，要减轻运维团队的工作量。

2023 年 6 月，T3 出行开始接触 OB Cloud，并进行了大量测试。在性能、成本、迁移难度、运维等多个层面的测试结果都远超预期，最终，T3 出行选择 OB Cloud 作为数据库底座。

一开始，T3 出行将司机任务、订单监控、虚拟号、开放平台等部分非核心业务放在作为试点，将数据量较大的单库单表场景迁移至 OB Cloud 上。切换过程非常顺利，且运行稳定，在兼容性、成本与性能等方面表现良好。高建丰对试点运行的结果做了以下几点总结：

OB Cloud 完善的周边生态，让迁移过程十分顺利，无代码适配成本。
OB Cloud 与阿里云、腾讯云等多种云平台灵活对接，云上数据流转自由，有效支撑 T3 出行的双云双地图战略。
基于 LSM-Tree 存储引擎，OB Cloud 可以极大压缩数据存储空间，解决了 T3 出行未来几年的数据存储难题。
OB Cloud 原生分布式能力可平滑扩展，在早晚高峰的高并发场景下自动扩容，且在司机端、乘客端无感知。
OB Cloud 采用多副本多活策略，能有效提高资源计算密度，业务高峰时段也保证系统性能。
通过 HTAP+多模一体化，统一管理 20 多种技术栈，不但提升了系统性能，运维同学的压力也大大减轻。

2024 年年初，T3 出行开始将订单、结算、支付、风控、营销等核心业务系统逐步都迁移至 OB Cloud。截至目前，T3 出行超过 50% 的业务平稳运行在 OB Cloud 之上，预计在 2025 年年初，实现所有系统的切换。

在降本层面，以会员业务为例，一开始，T3 出行对会员业务进行八库八表的拆分，后来迁移至 OB Cloud 采用三副本方式，以单库单表的形式支撑业务。切换之后，会员业务的成本降低超过 50%。全部业务切换至 OB Cloud 后，预计 RDS for MySQL 共 400+ 个实例，缩减至 25 个 OceanBase 集群，大幅度降低业务系统的数据存储规模，存储空间减少 80% 以上。得益于存储压缩技术和 CPU 资源利用率提升，整体数据库成本缩减 30%。

“因为我们使用 OB Cloud 的时间并不长，在一开始设计时也做了特别多的冗余。待业务平稳运行之后，降本会更加明显。”高建丰介绍说。

使用 OB Cloud 后，在早晚高峰的高并发场景下，T3 出行的数据库性能提升 75%，大表查询性能提升 12%，写入性能提升 90%，终端的司机和乘客在使用时可明显感知到业务的响应速度提升，整体的使用体验也有了质的提升。

此外，OB Cloud 稳定性非常高，T3 核心交易系统搭载 OB Cloud 平稳运行，OceanBase 驻场人员运维和响应的速度非常快，一年来无任何生产事故。得益于 OceanBase 原生金融级高可用，T3 出行所有业务均实现机房级故障 RPO=0 的能力。