共计 2839 个字符，预计需要花费 8 分钟才能阅读完成。
导语 ：一年一度的 11.11 又双叒叕来了，给技术人最好的礼物就是 技术指南！而通过这些年的倒退，购物节早已不仅仅局限于电商行业，当初各行各业其实都会采纳相似形式做经营流动，汽车界有 818，小米有米粉节等等，这对包含数据库在内的根底软件提出了很多新挑战，同时也积攒了诸多最佳实际。
在 11.11 到来前，PingCAP 与汽车之家、易车网、京东、中通等用户开展一系列深入探讨，心愿为大家揭秘逐年飙涨的销量背地暗藏着什么样的技术难题？用什么技术架构能力安稳地抗住流量洪峰？
京东 11.11 的技术挑战
每年的 618、11.11 对于京东而言都是一次大考，而京东云作为京东团体技术保障的基石，在此期间 须要扛住京东批发外围业务和京东物流零碎 PB 级别的数据增长压力。面对每年京东 11.11 订单量和成交额迅猛的增速，京东云数据库作为大部分京东背地业务零碎的外围，压力天然不小。
京东云资深产品经理杨牧对此深有感触：许多和京东 11.11 无关的业务零碎都须要数据库的反对，如剖析看板、报表数据、运单数据等等。受商品流动和优惠工夫的影响，用户下单顶峰往往在固定时间段，这些数据库的访问量会急速回升。
他所在的数据库团队，从后盾监控能够很显著地看到一个个峰值。当京东 11.11 全面开启的霎时，海量消费者和订单涌入，大量品牌和商家迅速发明了新的纪录，CPU、QPS 等也开始飙升，有时候继续若干分钟，有时候则会继续数小时不等。
如何做好保障？
京东云数据库须要在京东 11.11 期间安稳撑持京东团体曾经上云的上千个外围业务零碎，后期的预案筹备和压测、预案演练和实时监控都是必不可少的环节。而京东云数据库团队对此曾经积攒起丰盛的教训，他们将备战分为 8 个步骤：
- 辨认保障范畴；
- 业务量预估及预查看；
- 预案整顿；
- 监控及报警梳理；
- 业务压测；
- 预案演练；
- 11.11 值班；
- 技术复盘。
依据以往教训，杨牧认为京东 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 核规模。
大促对于企业而言，除了反对业务翻新，也是一次对本身技术架构的大练兵和全链路演练。通过大促的极致考验，企业的 IT 架构、组织流程、人才技能都取得了大幅晋升。而在大促中的教训和思考，也会减速企业日常的业务翻新节奏，晋升技术驱动的翻新效率，打造增长新引擎。
