编者按
作为中国领先的电商与零售基础设施服务商，京东集团 2024 年营业收入达 1.1588 万亿元，在 2024 年世界 500 强企业中排名第 47 位，并连续九年位居国内行业首位。其业务覆盖零售、物流、科技、健康、金融、保险等多板块，拥有近 6 亿年度活跃用户和 800 万家企业客户，而这一切的背后离不开强大稳定的数据基础设施支撑。面对高并发交易、海量数据存储与实时分析需求，京东集团自 2020 年起正式采用 TiDB 分布式数据库，逐步构建起适应互联网业务特性的分布式数据架构，围绕供应链持续完善业务布局。
作者：向安杰｜京东集团研发工程师
京东云 TiDB 应用概况
京东云作为集团的数据底座，承载着内部核心业务与公有云客户的数据服务。目前，京东集团内部运行着数百套集群，总数据量达 PB 级，而 TiDB 已广泛应用于零售广告推荐、物流财务结算、科技金融等多个场景。
在技术架构选择方面，京东云没有采用物理机部署方式，而是选择完全基于 Kubernetes （k8s）容器化部署 TiDB，通过 TiDB Operator 实现自动化管理。这种方案适配了互联网业务集群数量多、变动频繁的特点，高效支持快速扩缩容与资源调度。
TiDB 在京东的三大核心应用场景
（一）替代分库分表：解决数据规模与运维痛点
早期，京东云主要采用 MySQL。随着业务数据量越来越大，MySQL 分库分表需频繁扩库，人力成本激增，管理运维工作也更加繁琐复杂。面对这些痛点，京东开始进一步接触 TiDB。2020 年，TiDB 4.0 版本上线后解决了诸如乐观锁等一系列问题，实现了高冲突场景下的性能优化，让京东集团决定正式采用 TiDB。
这一阶段，TiDB 主要作为分库分表集群中的实时从库，负责部分复杂度较高且偏分析型的流量。在一年多的使用中，TiDB 的稳定性、安全性以及数据一致性经受住了业务的真正检验，京东集团开始将读写流量、分析型流量通过业务灰度方式，一步步迁移并最终完全交给 TiDB。实践证明，TiDB 凭借先进的系统架构，长期稳定支撑 PB 级业务数据，其支持分布式事务、强一致高可用及在线扩容等能力，让业务方不再害怕开展改造，成为京东集团替代分库分表的理想解决方案。
（二）实时分析场景：TiFlash 赋能 HTAP 能力
应用的发展是一条曲线，从轻量级发展至超大规模后，那些依赖单机数据库的应用将面临严峻的流量承接和数据分析问题。传统方案需同步数据至 Hadoop、Clickhouse 或 Doris 这些系统，存在延迟且运维复杂。TiDB 则可以一个数据库就解决这些问题。
TiFlash 是 TiDB 数据库生态系统中的关键组件，作为一个列式存储引擎和分析处理组件，TiFlash 提供了良好的隔离级别和强一致性保证，同时显著提升了分析查询的性能。这使得 TiDB 能够同时高效处理 OLTP 和 OLAP 工作负载，为用户提供统一的数据平台，简化架构，降低复杂性和系统维护成本，业务方接受度也更高。尤其在一些数据量不大但又对数据实效性具有一定需求的场景中，业务无需复杂改造，仅创建一个 TiFlash，一个列存储引擎数据副本就能够实现实时分析。相比于传统系统（如基于 MySQL 分库分表或单机数据库）受限于架构，数据同步或分析常采用 T+1 批量处理模式，延迟较高，TiDB 可以做到低延迟实时数据查询处理，且业务无感知。
（三）高扩展性及高性能 OLTP：告别海量数据的成本压力
随着 TiDB 商业知名度不断提升，以及稳定性、高可用等优势日益凸显，越来越多的业务方对 TiDB 充满信心与信任。对一些从零开始的业务而言，直接上手使用 TiDB 可节省数据规划成本。在数据量规模从小到大的过程中，TiDB 可通过面向业务透明无感知的数据分布调度，解决传统集中式系统的扩展性瓶颈，使集群能够弹性应对数据增长和业务负载变化，满足稳定读写，同时业务无感。对于单表数据量达千万级以上甚至亿级的业务，一些业务方不能也不愿采用 MySQL 分库分表的方式，会选择低成本迁移到 TiDB。有的业务方可能使用过 TiDB 并对 TiDB 有深度了解，在数据量不多的情况下，直接复用部门集群，应用便捷且几乎零成本。 同时，京东集团向安杰老师也提到，TiDB 是具备优秀分布式数据库并发吞吐处理能力，可在开发阶段通过并发的方式提前规避多网络交互下的简单 SQL 延迟问题。
京东云选择 TiDB 的核心逻辑
- MySQL 生态兼容
京东内部业务多数基于 MySQL 开发，TiDB 完全兼容 MySQL 协议与生态工具（如 ORM 框架、监控组件），业务可平滑迁移且成本极低，应用无需或者只需修改少量代码。
- 扩展性 & 可靠性
TiDB 具备弹性扩缩容能力，通过 Multi-Raft 协议实现数据多副本强一致，支持跨地域容灾部署，满足核心业务对数据安全的要求。
- 易运维
迁移至 TiDB 前，京东内部过去踩过很多坑。在使用 MySQL 的主从库时，数据库管理部门常常需要担忧数据一致性、数据备份、恢复与容灾等问题，但在 TiDB 应用过程中，这些问题都得到妥善解决。基于显著的技术收益，京东集团也主动将 TiDB 推广至更多内部业务线及外部业务方。
实战案例：从物流到零售的性能验证
（一）京东物流某应用
- 业务量级：该应用主要涉及财务领域，包含三张主要业务表，单表数据量级分别达 20 亿、50 亿、100 亿。
- 迁移成本：业务从 MySQL 迁移至 TiDB 时，仅需修改连接的用户名和密码，代码零改造。
- 性能提升：迁移至 TiDB 后，压测场景中，单写和更新延迟均稳定控制在 100 ms 以内；复杂分析查询延时可以降至几十毫秒以内，完全契合业务指标要求。业务方无需再为分库分表的频繁扩容与管理投入精力，显著降低了运维成本与复杂度。
（二）京东零售某应用
- 业务量级：单表超 100 亿行数据，数据量超 100 TB。由于数据量极大，每天需要跑几小时任务来产出分析报表。
- 性能提升：业务从 OceanBase 迁移至 TiDB 后，各项压测指标均符合预期。在任务期间，集群容量可动态调整，日常 QPS 可达 25 w，延时能够控制在 15 ms；压测时可达 40-50w 量级，延时依旧能够控制在 20 ms 以内。
- 期待 TiCDC 新架构：由于单库单表量级较大，每秒可能要写十几万数据，未来计划配合业务方验证 TiCDC 新架构的实时同步性能。
运维经验：从磁盘替换到版本升级
TiKV 节点磁盘寿命管理
- 问题：TiKV 节点所在 Nvme 盘寿命批量到期。某集群 15 个 TiKV 节点中 7 个节点所在 Nvme 磁盘接近寿命上限，数据迁移过程中出现性能波动。
- 解决方案：通过强制下线 POD，登录至物理机执行 pvmove 操作，快速将 TiKV 节点数据迁移至新的 Nvme 盘，恢复集群可用。
- 启示：需加强集群级硬件寿命监控，结合 TiDB 的分布式特性提前规划容灾策略。
TiKV 节点批量重启故障
- 问题：线上某集群 TiKV 节点依次重启。该集群总计 36 个 TiKV 节点，其中 12 个 TiKV 节点在当天半小内，依次 Crash 重启。期间，TP99 轻微上升，未造成实际业务影响。
- 应对：扫描全集群版本，主动重启集群，推动业务主动升级。
- 经验：通过版本升级，延迟变低了，资源负载及 CPU 使用率降低，这意味着业务进一步优化，业务体验更好，旧版本 bug 全部修复。
京东云 TiDB 未来应用规划
- 持续推广使用：随着业务方对 TiDB 的接受度和认可度越来越高，以及基于 TiDB 在业务场景中的能力表现，京东集团计划配合内部的业务方以及外部的公有云用户更大范围地使用 TiDB。
- 版本升级驱动性能优化：在做好完备的功能测试、性能测试后，有规划地开展内部集群升级工作。
- 探索敏捷模式：针对中小规模国产化场景，云舰平台计划结合平凯数据库敏捷模式，解决私有小规模交付的成本问题及延时问题。
结语
京东云在选择和应用 TiDB 的过程中展现出技术布局的前瞻性与决策魄力。实践证明，TiDB 凭借云原生架构、HTAP 能力、 MySQL 生态兼容等特性，不仅解决了分库分表的历史难题，更成为互联网企业应对 PB 级数据挑战的核心基础设施。未来，TiDB 将持续助力京东集团夯实供应链底层架构，推动业务布局向更全面、更协同的方向深化发展。