TiDB 与京东云数据库联手，打造极速秒杀新体验

导语：一年一度的 11.11 又双叒叕来了，给技术人最好的礼物就是技术指南！ 而经过这些年的发展，购物节早已不仅仅局限于电商行业，现在各行各业其实都会采用类似方式做运营活动，汽车界有 818，小米有米粉节等等，这对包括数据库在内的基础软件提出了很多新挑战，同时也积累了诸多最佳实践。

在 11.11 到来前，PingCAP 与汽车之家、易车网、京东、中通等用户展开一系列深入探讨，希望为大家揭秘逐年飙涨的销量背后隐藏着什么样的技术难题？用什么技术架构才能平稳地扛住流量洪峰？ 京东 11.11 的技术挑战

每年的 618、11.11 对于京东而言都是一次大考，而京东云作为京东集团技术保障的基石，在此期间需要扛住京东零售核心业务和京东物流系统 PB 级别的数据增长压力面对每年京东 11.11 订单量和成交额迅猛的增速，京东云数据库作为大部分京东背后业务系统的核心，压力自然不小。

京东云资深产品经理杨牧对此深有感触：许多和京东 11.11 有关的业务系统都需要数据库的支持，如分析看板、报表数据、运单数据等等受商品活动和优惠时间的影响，用户下单高峰往往在固定时间段，这些数据库的访问量会急速上升。

他所在的数据库团队，从后台监控可以很明显地看到一个个峰值当京东 11.11 全面开启的瞬间，海量消费者和订单涌入，大量品牌和商家迅速创造了新的纪录，CPU、QPS 等也开始飙升，有时候持续若干分钟，有时候则会持续数小时不等。

如何做好保障？京东云数据库需要在京东 11.11 期间平稳支撑京东集团已经上云的上千个核心业务系统，前期的预案准备和压测、预案演练和实时监控都是必不可少的环节而京东云数据库团队对此已经积累起丰富的经验，他们将备战分为 8 个步骤：。

（1）识别保障范围； （2）业务量预估及预检查； （3）预案整理； （4）监控及报警梳理； （5）业务压测； （6）预案演练； （7）11.11值班； （8）技术复盘根据以往经验，杨牧认为京东 11.11 时的业务量会达到平时的 10 倍之多。

这个数据量的峰值增长必须准备额外的资源来满足，但由于京东云的数据库已经跑在云上，他们只需根据预先估计好的数据量做好资源规划和分配，并做足压力测试，确保后面数据库的存储容纳量和性能就可以满足要求到流量洪峰真正到来时，往往只需要静静等待就会平稳度过，并不会出现什么极端情况。

特别像京东物流大部分业务已经上云，保障和准备其实是无时无刻都在进行中云数据库通过高可用架构、自动故障切换、弹性扩容机制等一系列数据库级别的技术手段，保证数据可备份，故障可切换，增量可扩容，从容应对京东 11.11 期间海量数据压力。

而在应用 TiDB 后，这些工作变得更加简单TiDB 采用的分布式架构支撑海量数据扩展，可以有效地解决单机 MySQL 容量和性能的瓶颈问题杨牧形容，在扩容时只需根据业务方需要提前对 TiDB、TiKV 进行扩容。

而扩容的工作也仅需在控制台上点一点鼠标，然后安心地喝着茶等待就行了，大大提高了 DBA 的工作效率同时，TiDB 是开源的，不存在技术锁定问题，也更容易在云上使用，甚至跨云部署为了降低集团内部各团队使用 TiDB 的技术门槛，京东云与 PingCAP 联合推出了云上的分布式数据库 —— Cloud-TiDB，在京东云上提供 TiDB 服务。

这样一来，业务方所有和数据库服务有关的事情不再需要设置自己的 DBA，完全委托给京东云即可今年的京东 618 和 11.11 中，Cloud-TiDB 就已成功应用于京东物流内的物流某业务系统、物流大件分拣系统、运单计提明细系统等多个业务中，应用规模总体接近 6000 核，达到 30 个 TiDB 集群，在成本、效率和体验三大方面带来了大幅提升。

杨牧笑言，研发再也不用整天忙着优化系统了，可以早点回家运维同学也不用再熬夜支持系统运维，头发都可以少掉几根物流某业务系统11.11 中，大家买买买后最期盼的事情就是收到快递而在京东中，京东物流就承担了将下单物品送到买家手中的职责。

可想而知，京东物流业务系统的数据量肯定非常大，几个主表的数量分别是 20 亿、50 亿和 100 亿，系统上线半年后数据翻倍到了 220 亿原先 MySQL 分库分表的架构就遇到了一些复杂的 SQL 不支持、跨分片统计报表难于实现等问题。

系统迁移到 TiDB 之后，整体的性能表现优秀，写入和更新的效率在 100 毫秒左右，查询和 Sum 查询只有二三十毫秒一个几百亿数据量的系统从 MySQL 迁移到 TiDB，实际业务代码零修改，系统只是更换了 JDBC 连接的用户名和密码，真正地实现了从 MySQL 到 TiDB 的零代码修改和无缝迁移。

TiDB 和 MySQL 良好的兼容性，降低了用户的试错、测试和迁移的成本，且收益周期短，见效快此外，杨牧特别指出，迁移到 TiDB 还给业务方带来一个意外的惊喜如果按两年的周期计算，TiDB 的使用成本只有 MySQL 的三分之一。

这主要是因为 TiDB 对数据的压缩率非常好比如在 MySQL 里数据占到 10.8 TB，迁移到 TiDB 之后只有 3.2 TB，而且这还是三副本的总数据量，TiDB 实实在在地帮助整个业务部分极大降低了 IT 的投入成本。

物流大件分拣系统京东物流大件分拣系统的一些实时看板和核心报表跑在 MySQL 上随着数据量增加，而且 SQL 比较复杂，报表和看板的性能比较低，用户体验不佳分库分表的方式对代码侵入性比较大，架构需要大幅调整，风险较高。

在 618 期间，京东物流采用 TiDB 支撑业务的实时看板和核心报表，在 MySQL 和 TiDB 之间，用自研的蜂巢系统进行数据的准实时同步从 MySQL 迁移到 TiDB 后，总共数百个指标，整体性能实现了 8 倍提升。

运单计提明细系统运单计提明细系统用来记录部分运单的明细数据，每天的数据增长在千万级别，单表最大记录接近 200 亿条从数据量看用 MySQL 难以支撑，京东物流尝试过使用 Presto，但使用成本比较高，后来使用 *** 做查询，但也存在着不稳定的情况，维护工作量很大。

业务系统迁移到 TiDB 之后解决了海量数据的问题，TiDB 可以毫无压力地支撑百亿级的数据量TiDB 成本比起以前使用的 MySQL + *** 方案降低了 30%TiDB 性能满足业务的要求，从百亿的单表里面查询出业务数据的 TP99 大概在 500 毫秒左右。

此外，TiDB 整个表结构的调整修改操作非常简单，带来了运维敏捷和成本下降经过 618 、11.11 的严酷考验，TiDB 在京东集团的多个 0 级系统中应用稳定，没有出现任何事故，各业务方反馈都比较好，已经成为集团内部的标杆案例。

这也给了杨牧他们充足的信心，在接下来的时间中可以继续在集团内部推动使用 TiDB ，以技术的进步推动业务发展，预计 2021 年底规模还将再翻一倍，达到 10000 核规模编后语：618、11.11 对于企业而言，除了支持业务创新，也是一次对自身技术架构的大练兵和全链路演练。

通过极致考验，企业的 IT 架构、组织流程、人才技能都获得了大幅提升而在此过程中的经验和思考，也会加速企业日常的业务创新节奏，提升技术驱动的创新效率，打造增长新引擎更多“大促背后的数据库”内容介绍：大促背后的数据库——Infra Talk 丨视频访谈专题

； HTAP分布式数据库大促背后的数据库

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。