接上期,到现在为止,我们已经对订单系统核心接口业务流程有了一定的了解,此时我们可以接一些简单的需求做了。
同时这个时候,也会有对应的产品经理来和我们对接需求,一般3个月左右,我们处理单系统的日常需求就轻车熟路了。
可能在刚入职的时候,这家初创型互联网公司累积的**用户量也就10万,每天活跃2万,日订单2万,**如下图:
对于数据库中的订单表而言,如果按照一天2万个订单数据量计算,一年也就七八百万的订单量,还是可以轻松hold住的。
行业风口,用户量突增带来的问题
但是,可能若我们就是这么幸运,刚好遇到了移动互联网快速发展的几年。
这个时候,**外卖APP的用户量迅速增长到了100万,日活用户20万,日订单20万,订单单表也从300万快速达到了2000万,**如下图:
在这3个月的过程中,我们除了做日常的需求外,还要支持解决线上问题,所以经常会去查询订单表。
**在查询订单表数据的时候,我们会发现随着订单数据的增多,订单查询sql相应的也会变得越来越慢,**比如,你刚入职的时候单表可能就300万数据量,查询只需要20ms的样子,但是现在,单表增长到2000万,不过查询一般也都稳定在200ms以下。
某一天,当我们正在沉浸式地写着代码时,leader突然找到我们说:“昨天晚上小猛上了一个需求,然后今天突然发现我们订单sql查询超过了3s,肯定是昨晚上线的sql有问题,现在我们单表才2000万数据,MySQL是可以轻松hold住的,小猛今天不在公司,你帮忙排查下问题,然后优化下sql。”
可以想象一下这样一个场景,当我们打开一个外卖app想点个外卖,想起来上周吃的某个外卖还不错,就想看看自己点的是哪个商家的外卖,然后满心欢喜的想要点开自己的历史订单列表。
结果等了3s订单列表都还没加载出来,也许作为干饭人的我们有着强大的毅力,最后终于等到订单列表加载出来了,心满意足选好菜品下单。
但此时我们的脑海中是不是会出现那个bgm:“完了,芭比Q了”,所以这样的查询速度是万万不能接受的,因为体验极差。
回过神来的我们,听完leader说的话后就接下了这个任务,马上开始着手优化sql了,但是下一秒就遇到一个新的难题,那就是我们根本没优化过sql,就连MySQL的一次查询会经历过哪些过程,你都不是很清楚,更不用提要从哪里开始优化了。
而sql优化的第一步,我们得要先了解一下MySQL一次完整查询会经历哪些过程,然后再针对性的优化,MySQL一次完整的查询的过程呢,我们在下一篇文章会详细的分析,大家不要着急,这里我们继续分析下现状。
偶尔的流量爆发,问题被进一步放大
根据刚才的分析,在上百万规模的一个用户群体下,数据库中一年的订单数据量搞不好都要上亿了,一旦订单表中的数据达到这样的一个量级之后,后续订单sql的性能就开始显著下降了。
但是,容易被我们忽视的一个场景就是,流量可能偶尔会爆发一下,然后sql查询较慢的问题会被进一步的放大,那么哪些场景会导致流量在短时间内爆发呢?
其实这种场景就比较多了,比如某一天,我们的外卖APP做了一些促销活动,或者是某一天竞对的APP不幸挂掉了(作为良性竞争倡导者的我们不应该有这种想法,但是万一呢,是吧?),这些场景下,大量的流量就会在短时间里引爆我们外卖APP。
好的,那我们这里假设就是竞对的外卖APP出了一些故障吧,比如竞对的评价系统挂掉了,导致店铺的评价显示不出来,那这就严重了,因为部分用户的订餐习惯,是在点外卖前都会先看下店铺的评价。
结果由于竞对外卖APP的评价系统挂了,导致店铺的评价显示不出来,那这些用户可能就都会跑到我们的外卖APP来下单,这个时候,我们外卖APP的流量就会瞬间增大好几倍。
本来这个时候,我们订单表一次查询差不多都需要3s了,现在又发生了流量突增的情况,那就会导致已经存在的问题被进一步的放大,比如一次订单查询会直接变为5s,这都是有可能的。
所以,如果我们不对这种场景进行优化,就会失去一些用户,因为我们自己的外卖APP此时也很卡的话,我们就可能会错过一次“天赐良机”。
结束语
不过,对于这种千万级数据的优化大家也不用着急,因为接下来,我们会带着大家一步步分析这些问题背后的原因,并且会将对应的解决方案进行落地,所以大家一定要好好学习,毕竟机会从来都是留给有准备的人的。