编者按
在“看车、买车、用车”的每一个瞬间，背后都有数据库的支撑。随着用户量和业务量的持续飙升，汽车之家如何应对海量数据与高并发的挑战？答案是——分布式数据库 TiDB。
以下内容基于汽车之家 陶会祥老师在 8 月 22 日 DTCC 中国数据库技术大会的分享整理。
一、业务增长带来的数据库挑战
作为国内领先的汽车互联网平台也是目前国内最大的汽车垂直媒体，汽车之家在“看车、买车、用车”全链条上积累了海量的用户、内容与交易数据。伴随业务持续扩张，数据库系统逐渐成为整个业务发展的关键瓶颈：
- 数据规模激增：核心业务实例数据量已经达到 TB 级，单库容量逼近物理极限。论坛、车展、经销商推荐、财务报表等业务每天产生亿级 PV、百万级 DAU，产生的数据体量和访问压力急剧上升。
- 高并发场景常态化：用户访问、内容互动和交易请求均呈指数级增长，数据库需要同时满足高 TPS/QPS 与低延迟响应的严苛要求。
- 存储与架构挑战：传统集中式数据库在扩展性、存储空间、性能和运维成本上已难以为继。原先分库分表方案虽然在一定程度上缓解压力，但却带来复杂的运维负担和潜在的可用性风险。
- 高可用诉求：在主从架构下，主库单点故障风险极高，一旦切换可能导致业务中断，无法满足核心业务“金融级高可用”的需求。
二、数据库架构的演进与行业趋势
在过去十几年里，业务形态和数据规模经历了几轮质的飞跃：从 PC 互联网到移动互联网，再到如今的大数据与智能化时代。用户规模不断扩大，数据体量从 GB、TB 迅速迈向 PB 级，应用对实时性、可用性和扩展性的要求愈发严苛。在这样的背景下，数据库架构大致经历了三个阶段：
- 集中式架构
单机集中式数据库在早期相对简单、易用，能够满足传统企业和中小规模互联网业务的需求。但随着数据量持续上涨，单机存储与计算逐渐逼近极限，扩展困难、单点风险高。
- 中间件分布式架构
在互联网业务高速增长期，行业普遍通过分库分表和中间件来突破瓶颈。虽然一定程度上解决了容量与性能问题，但业务改造侵入性大、架构复杂，维护成本与风险也随之增加。
- 原生分布式数据库架构
进入大数据与云原生时代，原生分布式数据库成为主流选择。它通过多节点天然分布，实现线性扩展、自动容错与高可用，能在高并发、跨地域、多业务融合的场景下保持架构简洁，对应用层几乎透明。
对于汽车之家来说，传统数据架构已经遇到明显瓶颈：单表容量过大、存储空间告急、分库分表导致运维复杂，而业务对高并发和实时性的要求又在持续提升。
结合行业趋势与数据库技术对比，分布式数据库不仅能提供更强的水平扩展和高可用能力，还能在 HTAP 场景下兼顾事务与分析。因此，汽车之家在系统演进中选择使用分布式数据库作为支撑论坛、财务报表、车展等核心业务的下一代数据库底座。
三、为什么选择 TiDB
汽车之家在下一代数据库选型过程中，重点考量了以下八大维度：
- 业务场景：是否具备 HTAP 能力，能一套系统同时满足 TP 与 AP。
- 扩展性：是否能够支持透明的水平扩展，突破单机容量与性能限制。
- 高可用性：能否满足两地三中心、跨机房容灾的建设需求。
- 性能表现：在高并发读写与复杂查询下的稳定性。
- 兼容性：是否对现有 MySQL/SQL Server 应用平滑迁移。
- 运维效率：自动化部署、监控、备份及工单系统的支持。
- 生态活跃度：开源社区是否活跃，问题响应和版本迭代是否及时。
- 成本可控性：避免依赖昂贵的高端存储设备。
在多轮测试与对比中，TiDB 脱颖而出：
- 架构优势：行存（TiKV）与列存（TiFlash）结合，原生支持 HTAP；通过 PD 调度实现全局事务一致性。
- 生态与社区：TiDB 开源社区活跃度高，迭代快速，能持续满足业务新需求。
- 兼容性好：天然兼容 MySQL 协议，降低了迁移难度。
可以说，TiDB 的设计架构不仅帮助汽车之家解决了扩展和稳定性问题，更为未来业务的智能化和实时化奠定了基础。
四、核心应用场景
论坛业务：从 SQL Server 到 TiDB
论坛是汽车之家最早的核心业务，采用 SQL Server + .Net 数据架构，承载了亿级帖子与 20+ 亿回复数据。随着数据规模膨胀，传统架构面临：
- 单表过大导致性能下降；
- 服务器存储空间不足；
- 主从备份风险高；
- 分库分表架构复杂，迁移与扩容风险大。
解决方案：
通过 TiDB 实现透明扩展，替代原有 SQL Server，避免分库分表复杂性。迁移过程中采用 全量同步 + CDC 增量同步（Kafka）+ 双向校验 + 分步切读/切写流量 的方式，保证数据一致性与业务平滑过渡。
最终效果：论坛业务在 TiDB 支撑下实现了高并发场景下的稳定响应，架构更加简洁，扩展更加灵活 。
财务报表与实时分析（HTAP 场景）
汽车之家财务和经营管理部门需要对最新的业务数据进行实时报表分析。传统 T+1 的数据同步方式延迟高，无法满足管理层的实时决策需求。
挑战：在同一系统中既要满足高频交易（OLTP），又要支持实时复杂查询与聚合（OLAP）。
解决方案：行存 TiKV 处理交易，并引入 TiFlash 列存节点，实现行列混合存储：
- OLTP 请求走 TiKV 行存；
- OLAP 查询则由智能调度至 TiFlash 列存，互不干扰。
最终效果：
- 技术栈简化：一套系统支撑 TP+AP，避免了异构 ETL 的数据同步。
- 性能提升：复杂聚合查询速度提升 20~50 倍。
- 代码更简洁：数据统一存储、统一驱动，简化业务逻辑。
财务报表业务因此实现了秒级实时查询，支撑公司管理层进行实时运营决策 。
818 车展狂欢夜（金融级高可用需求）
818 车展是汽车之家年度最重要的活动之一，需要在短时间内支撑峰值访问流量，并提供实时大屏展示。
架构方案：
- 两地三中心部署：基于知名云厂商，部署 10 个 TiDB、10 个 TiKV、5 个 PD 及 2 个 TiFlash 节点；同时配合 MySQL 作为灾备。
- 实时分析：TiFlash 节点处理统计 SQL，用于大屏展示；TiDB 负责核心交易写入。
- 高可用保障：MySQL 作为降级方案，保障极端情况下的业务连续性。
这一架构不仅支撑了车展期间的千万级流量冲击，还确保了数据库系统“金融级高可用”，业务体验顺畅如常。
五、TiDB 在汽车之家的规模化应用与运维实践
自动化建设
汽车之家在 TiDB 应用过程中，自研运维平台并结合原生工具，实现了：
- 自动化部署（安装、拓扑管理、授权、备份）；
- 监控体系（CPU、内存、磁盘、QPS、TPS、响应时间、慢查询监控）；
- 工单化处理（实例创建、修改、库表变更、数据修改授权）；
- 慢 SQL 优化与问题定位。
多机房容灾
汽车之家核心业务对数据库可用性要求极高，需要达到金融级高可用标准。例如车系产品库一旦出现故障，可能导致APP核心功能无法使用，造成巨大经济损失。因此汽车之家使用 TiDB 做了以下部署：
- 实现主备双中心架构，基于 CDC 数据同步，保障数据一致性；
- 建立 巡检机制（同步状态监控、一致性校验）；
- 定期 故障演练，确保突发情况下可快速切换。
版本升级
汽车之家遇到的问题包括：旧版本 OOM 风险、跨机房同步异常、大表加索引缓慢。在 TiDB 版本升级过程中，重点从以下几个角度进行考量：
升级决策的五大维度：
- 稳定性优先：选择 LTS（长期支持版），保证版本成熟度与社区支持度。
- 满足业务需求：功能和性能必须符合业务现状与预期。
- 兼容性评估：确保与现有应用、驱动、生态工具的兼容性。
- 实施风险评估：关注升级成功率、是否存在中断风险、平均升级耗时等。
- 未来发展：预留升级空间，避免“升完就过时”。
升级策略：在充分测试与应急预案下逐步升级。
实际效果：
- 升级后，TP99 延迟由 31ms 降至 20ms，性能显著提升；
- CDC 数据同步更稳定，跨机房同步异常大幅减少；
- Fast DDL 等新特性提升了表结构变更效率；
- 数据库版本统一，降低了后期运维成本。
六、TiDB 应用成效总结
通过 TiDB 的规模化应用，汽车之家取得了显著成果：
- 架构简化：避免复杂的分库分表与异构 ETL。
- 性能提升：在 HTAP 场景下，复杂查询性能提升 20-50 倍。
- 高可用达标：多机房容灾实现“金融级高可用”，核心业务连续稳定运行。
- 运维降本：自动化体系显著降低了人力成本与错误风险。
- 业务赋能：实时报表、车展大屏、推荐系统等业务均实现了“实时化”。
七、未来展望
汽车之家将在 TiDB 之上继续探索：
- 多活冗灾：推动主备双向同步、冗灾切换自动化，进一步提升容灾能力。
- HTAP 深化应用：更多业务场景实现实时分析与在线事务混合处理。
- 新特性探索：尝试引入向量计算等新特性，支撑智能推荐、AI 模型推理等新兴业务。
从论坛到财务，从车展到全业务，TiDB 已经成为汽车之家“看车、买车、用车”背后的核心数据底座。未来，随着智能化和 AI 的发展，TiDB 将在汽车之家承担更多“新基建”角色。