0
0
0
1
专栏/.../

TiDB + 京东云数据库打造极速秒杀体验

 TiDBer_yPhgr1QV  发表于  2022-02-17

一年一度的 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 不支持、跨分片统计报表难于实现等问题。

image.jpg1080×461 114 KB

image

系统迁移到 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 比较复杂,报表和看板的性能比较低,用户体验不佳。分库分表的方式对代码侵入性比较大,架构需要大幅调整,风险较高。

image.jpg1080×416 92.5 KB

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

运单计提明细系统

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

image.jpg1080×512 69.6 KB

业务系统迁移到 TiDB 之后解决了海量数据的问题,TiDB 可以毫无压力地支撑百亿级的数据量。TiDB 成本比起以前使用的 MySQL + ElasticSearch 方案降低了 30%。TiDB 性能满足业务的要求,从百亿的单表里面查询出业务数据的 TP99 大概在 500 毫秒左右。此外,TiDB 整个表结构的调整修改操作非常简单,带来了运维敏捷和成本下降。

经过 618 、11.11 的严酷考验,TiDB 在京东集团的多个 0 级系统中应用稳定,没有出现任何事故,各业务方反馈都比较好,已经成为集团内部的标杆案例。这也给了杨牧他们充足的信心,在接下来的时间中可以继续在集团内部推动使用 TiDB ,以技术的进步推动业务发展,预计 2021年底规模还将再翻一倍,达到 10000 核规模。

image.jpg1080×2160 399 KB

618、11.11 对于企业而言,除了支持业务创新,也是一次对自身技术架构的大练兵和全链路演练。通过极致考验,企业的 IT 架构、组织流程、人才技能都获得了大幅提升。而在此过程中的经验和思考,也会加速企业日常的业务创新节奏,提升技术驱动的创新效率,打造增长新引擎。

0
0
0
1

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论