分库分表实战之流量激增带来的技术挑战

前 言

​​接上期​​，到现在为止，我们已经对订单系统核心接口业务流程有了一定的了解，此时我们可以接一些简单的需求做了。

同时这个时候，也会有对应的产品经理来和我们对接需求，一般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此时也很卡的话，我们就可能会错过一次“天赐良机”。

结束语

不过，对于这种千万级数据的优化大家也不用着急，因为接下来，我们会带着大家一步步分析这些问题背后的原因，并且会将对应的解决方案进行落地，所以大家一定要好好学习，毕竟机会从来都是留给有准备的人的。