一年一度的 11.11 又双叒叕来了，给技术人最好的礼物就是技术指南！而经过这些年的发展，购物节早已不仅仅局限于电商行业，现在各行各业其实都会采用类似方式做运营活动，汽车界有 818，小米有米粉节等等，这对包括数据库在内的基础软件提出了很多新挑战，同时也积累了诸多最佳实践。
在 11.11 到来前，PingCAP 与汽车之家、易车网、京东、中通等用户展开一系列深入探讨，希望为大家揭秘逐年飙涨的销量背后隐藏着什么样的技术难题？用什么技术架构才能平稳地扛住流量洪峰？本篇为「大促背后的数据库」系列专题第一篇，介绍了 TiDB 在京东云 618、11.11 的应用实践。
京东 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 的 37%。这主要是因为 TiDB 对数据的压缩率非常好。比如在 MySQL 里数据占到 10.8 TB，迁移到 TiDB 之后只有 3.2TB，而且这还是三副本的总数据量， TiDB 实实在在地帮助整个业务部分极大降低了 IT 的投入成本 。
物流大件分拣系统
京东物流大件分拣系统的一些实时看板和核心报表跑在 MySQL 上。随着数据量增加，而且 SQL 比较复杂，报表和看板的性能比较低，用户体验不佳。分库分表的方式对代码侵入性比较大，架构需要大幅调整，风险较高。
在 618 期间，京东物流采用 TiDB 支撑业务的实时看板和核心报表，在 MySQL 和 TiDB 之间，用自研的蜂巢系统进行数据的准实时同步。从 MySQL 迁移到 TiDB 后， 总共数百个指标，整体性能实现了 8 倍提升 。
运单计提明细系统
运单计提明细系统用来记录部分运单的明细数据，每天的数据增长在千万级别，单表最大记录接近 200 亿条。从数据量看用 MySQL 难以支撑，京东物流尝试过使用 Presto，但使用成本比较高，后来使用 ElasticSearch 做查询，但也存在着不稳定的情况，维护工作量很大。
业务系统迁移到 TiDB 之后解决了海量数据的问题，TiDB 可以毫无压力地支撑百亿级的数据量。TiDB 成本比起以前使用的 MySQL + ElasticSearch 方案降低了 30%。TiDB 性能满足业务的要求，从百亿的单表里面查询出业务数据的 TP99 大概在 500 毫秒左右。此外，TiDB 整个表结构的调整修改操作非常简单，带来了运维敏捷和成本下降。
经过 618 、11.11 的严酷考验，TiDB 在京东集团的多个 0 级系统中应用稳定，没有出现任何事故，各业务方反馈都比较好，已经成为集团内部的标杆案例。这也给了杨牧他们充足的信心，在接下来的时间中可以继续在集团内部推动使用 TiDB ，以技术的进步推动业务发展，预计 2021年底规模还将再翻一倍，达到 10000 核规模。
618、11.11 对于企业而言，除了支持业务创新，也是一次对自身技术架构的大练兵和全链路演练。通过极致考验，企业的 IT 架构、组织流程、人才技能都获得了大幅提升。而在此过程中的经验和思考，也会加速企业日常的业务创新节奏，提升技术驱动的创新效率，打造增长新引擎。