11 系统面临的现实问题：秒杀活动时数据库压力太大，该怎么缓解？
系统面临的现实问题：秒杀活动时数据库压力太大，该怎么缓解？
1、愁眉苦脸的小猛：为啥订单系统有一大堆问题？
小猛今天一早就到了公司，但是在工位上愁眉不展。因为他经过最近几天的学习，觉得自己所在的订单技术团队，这个订单系统面临的技术问题真是太多了。
他一边想，一边在自己的A4白纸上画图。
小猛一边画图，一边自言自语：首先是在一个订单支付之前，用户一旦下了订单，就会锁定对应的商品库存，别人就不能买了。然后万一用户一直没支付，还得一个后台线程不停的扫描数据库里的待支付订单，去自动取消长时间没支付的订单。
但是如果这种订单有几十万甚至几百万之多呢？不停的让后台线程扫描，性能很差，也非常的不方便。
接着小猛又在白纸上画了一个图出来。
这个图就稍微复杂一点了。支付订单之后要经历更新订单状态、扣减库存、发送Push推送、增加积分、派发优惠券和红白、通知仓储系统发货，等等过程。
这一系列的过程要是都执行下来，那性能真是太差了！
而且不光是这样，在这个调用链路中，订单系统还跟仓储系统耦合在了一起，仓储系统是跟第三方物流系统耦合在一起的。
这种耦合，就导致了第三方物流系统如果性能出现抖动，会导致我们的核心链路的性能也会抖动，第三方物流系统的接口如果调用失败，会导致我们的核心链路也出现部分失败。
小猛一阵摇头，又接着画了一个图：
看上图，哪怕是订单支付过后，如果用户要退款，这个时候涉及到自己公司内部系统的一系列回滚，比如更新订单状态、增加库存、收回优惠券和红包、减少积分，通知取消发货，等等。
而且此时还得调用第三方支付系统进行退款，但是万一在这里退款失败了呢？那用户就拿不到自己的钱了，所以还得考虑这个问题。
接着小猛拍拍脑袋，又画了一个图。
真是搞不懂这个大数据团队在搞什么，虽然是刚刚组建，来不及搭建自己的架构。但是就因为老板急着看数据报表，就直接跑几百行的大SQL从我们订单数据库里来拿数据，这个太不靠谱了。
如果有几十个人同时看报表，几十个几百行的大SQL运行在订单数据库里，瞬间会导致我们的CPU和磁盘IO负载过高，导致我们订单系统自己的CRUD操作的性能下降，真是想着都揪心！
小猛看着自己画的这四张图，感觉自己完全理解现在订单系统面临的困境了，但他觉得有心无力，因为问题很多，不知道如何去解决。
而且他觉得，这些还只是明哥给他讲的一些问题，包括数据库压力过高，数据量过大，搜索订单性能太差等很多这类问题，可能明哥都没给他讲，因为毕竟是团队其他兄弟在负责这类事情。
2、明哥的赞赏：知耻而后勇，就成功了
正当小猛出神的时候，明哥来到了他的身后，看着他手里画的4张图，很是欣慰。心想：真是没看错这个小伙子，悟性很高，聪明努力，几天功夫就把订单系统面临的技术问题都理解透彻了。
明哥拍拍小猛的肩膀说：怎么样，是不是感觉自己对这些技术问题有心无力？
小猛点点头：是的，我现在知道有这些问题了，但是不知道怎么去解决他们，明哥你让我来负责这些问题的技术方案的设计，我可能做不到啊。
明哥微笑着说：你不要过于担心了，你是应届生，我怎么会把担子都压在你身上呢。
其实最主要的，是我来一步步指导你去调研一些技术，然后给你一些思路，让你设计出解决这些问题的技术方案来，所以我会全程带着你的，放心。
小猛一听就乐了：原来有明哥这么粗的大腿抱，不是我一个人抗啊，那我就放心了。
明哥说：知耻而后勇，就成功了，现在你意识到了自己能力不足，以后一定要多加努力！
3、双11对一个订单系统到底有多大压力？
明哥接着带小猛到了会议室里，在会议室里明哥说：今天要告诉你这个订单系统未来需要你来解决的最后一个问题，就是抗双11大流量压力！这个也是需要你来搞定的，当然，我会带着你一起做，给你指导思路。
小猛一听就来兴趣了，因为平时常常在网上看到，12306售票网站的压力有多么的大，平时淘宝天猫的双11活动时系统压力有多么大，春晚时候的微信红包压力有多么大，但是自己一直不太理解这里面的问题所在。
明哥看出了小猛的疑惑，开始了讲解。
首先经过之前的讲解，我们已经知道了咱们的电商APP的用户使用习惯以及我们的订单系统面对的压力。
在平时晚上的高峰使用期，最顶峰的时候大概是每秒2000左右的请求压力到订单系统上来。
明哥说着，就在小白板上画了一个图出来。
接着明哥问小猛一个问题：如果用户每秒会发起2000个请求到我们的订单系统的各类接口，包括下单接口、退款接口、查询接口等等，那么你觉得我们的订单系统每秒会执行多少条SQL在订单数据库上？
小猛被这么一问，一下子就呆住了，这个问题还从来没想过。
明哥接着解释，这个其实是一个有经验的工程师一般都会了解的一个估算方法，比如每秒订单系统的各类接口被调用2000次，平均每个接口会执行多少次数据库操作？
一般你可以认为平均每个接口会执行2~3次的数据库操作。
一般一个接口根据业务复杂度的不同，有的接口可能处理一个请求要执行五六次数据库操作，有的接口可能是1次数据库操作+两三个其他系统的接口调用（比如库存系统、营销系统）。
总之，一般来说，业务系统的接口处理逻辑，基本都集中在对自己的数据库的操作以及对其他系统的调用上。
所以大致在我们这里，结合线上数据库的可视化监控界面，基本可以知道，平均每次订单系统的接口调用，会执行2次数据库操作，我们观察数据库的监控界面，在最高峰的时候，每秒大概是有4000左右的请求。
说到这里，明哥继续在上图中补充了一点东西。
之前讲过，线上数据库是部署了一台服务器的，用的是高配置的16核32G以及SSD固态硬盘的机器，因此观察线上数据库的情况，在每秒4000请求的时候，虽然CPU、磁盘、IO等负载较高，但是基本还在承受范围内。
那么接着问题来了，如果在双11之类的超级大促活动中，我们的订单系统可能会面临多大的压力？以及订单数据库可能面临多大的压力？
4、双11之类的大促活动有多恐怖
明哥接着解释，双11之类的大促活动你知道有多恐怖吗？
明哥举了一个最直接的例子，明哥他媳妇儿。
明哥他媳妇儿每年最盼望的就是一年一度的双11，因为这个时候往往所有人购物成风，她也可以疯狂的购物，不用顾虑明哥痛苦的眼神。
为什么呢？因为明哥那个时候一定是坚守在公司里值班，保证公司的系统稳定性，不会在家里。当然只是个玩笑！
但是实际情况也差不多如此，在类似双11之类的活动时，基本上很多电商都会在双11零点之后突然开启一个特别大的折扣优惠，比如来一个全场3折大甩卖。
很多少男少女，中年妇女，都会等在手机前。
明哥的媳妇就会在双11之前几天，在购物车里加入大量的商品，然后在双11零点来临前盯着手机等待，等零点一过，双11全场大甩卖正式开始，此时大量的人在这个时候突然下单，抢购商品，仿佛商品都不要钱一样。
所以此时很多顶级大电商公司的系统，可能会在双11购物最高潮的时候，系统QPS达到百万级别，也就是每秒百万请求！
当然，明哥所在的公司还没那么恐怖，毕竟是一个创业型电商公司。
但情况也好不到哪儿去，明哥回忆道：去年双11的时候，公司也搞了一场活动，当时公司用户量很少，那年双11就几十万用户参与了，但是就这样，在双11购物最高峰的时候，也达到了每秒几千的QPS！
明哥说，当时我们那台16核32G的高配置机器部署的数据库，短时间内CPU、磁盘、IO的负载飙升到了最高，但是这种购物高潮往往不会持续太久，所以很短时间过后，负载就慢慢下来了，基本还能抗住！
5、今年的双11活动对系统压力会有多大？
明哥接着说，那么今年的双11活动对系统压力会有多大你知道吗？公司现在积累的注册用户已经千万级了，平时的日活用户都百万级，今年的双11参与活动的用户预计有可能会达到两三百万。
假设是这个量级的话，基本可以做一个设想，如果有200万用户参与双11活动，在双11购物最高峰的时候，肯定会比往年的高峰QPS高好几倍，预计有可能今年双11最高峰的时候，会达到每秒至少1万的QPS。
也就是说，光是系统被请求的QPS就会达到1万以上，那么系统请求数据库的QPS就会达到2万以上。仅仅凭借我们目前的数据库性能，是无论如何扛不住每秒2万请求的。
小猛听到这样的一番分析，从系统面临的实际场景，一直到系统的压力挑战，目瞪口呆。
他很惊讶，在一些大促活动的时候，数据库的访问压力完全有可能会超出他能承受的极限，那这个时候该怎么办呢？
明哥笑笑说：别着急，其实这个每秒2万QPS也不算太高，跟BAT比起来，就是小巫见大巫了，我们只要合理设计系统架构和技术方案，其实也是可以轻易的抗住这个压力的。
小猛听明哥如此的淡定，顿时像个小迷弟，一脸崇拜之情。通过技术解决现实生活中的挑战，真是太有意思了！
End
专栏版权归公众号儒猿技术窝所有
未经许可不得传播，如有侵权将追究法律责任
