*本文根据 T3 出行研发总监高建丰在 2024 OceanBase 年度发布会上的演讲整理而成。
如今，网约车已成为人们日常出行的重要选择。随着“互联网+出行”模式的迅猛发展，海量出行数据应运而生，构成了城市交通系统的数字神经网络。与此同时，对于高效数据存储与数据分析的需求也随之日益增长。
T3 出行成立于 2019 年，是由一汽集团、东风汽车和长安汽车三大央企联合打造的智慧出行平台。经过五年的快速发展，T3 出行的日峰值订单数已突破 300 万。随着 T3 出行业务迅猛增长，一套稳定、高性能且安全的数据库系统显得尤为重要。综合考量性能、成本等多方面因素后，T3 出行最终选择了 OB Cloud 为其提供数据库技术支撑。
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 出行数据库团队不得不面对的课题。
基于上述问题，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 的能力。
目前，T3 出行主要用 OB Cloud 替换了 MySQL 的场景，未来考虑替换 HBase、Redis 等场景，用 OB Cloud 统一管理，更大程度简化技术栈，减轻运维压力。
TP 与 AP 割裂的两个系统，对人力资源和机器资源造成了极大的浪费，借助 OB Cloud 的 HTAP 能力，分析不分数据报表，进一步扩展了业务的边界。
另外，T3 出行还考虑基于 OB Cloud 进一步探索多云部署，T3 目前面临的双活问题主要是网络问题、应用问题和数据问题。网络和应用双活容易实现，底层的数据双活可以借助 OB Cloud 来支持，屏蔽不同云厂商之间的底层差异，实现跨云主备库、双活能力，探索业务跨云灾备能力的实践。
