大家好,我是七淅(xī)。

如标题所说,和大家分享一个我曾优化过的业务场景。

当然,具体业务细节不重要,重要的是优化的思路。如果大家以后有遇到类似特点的场景,能够想到七淅这篇优化文章,那我就觉得很值了。

接下来我就直接进入主题,要分享得优化思路就是请求合并

弱弱说一句,由于优化效果特别明显,这一优化我直接写到简历上了。

之前面试有不少面试官都会来问我是怎么做的,你看这不就给我机会发挥了吗?所以大家懂的,有合适场景记得用起来,以后面试也和面试官谈笑风生。

1. 什么是请求合并

首先说明一下,这并不是什么高级的优化方式,不难,朴实无华,但有用。

如字面意思,就是(把多个)请求合并(成一个请求去处理)。

现在含义你知道了,现在我们看下文章标题:「请求一下子太多了,数据库危」

聪明的你是不是已经猜到七淅要怎么优化了?

2. 业务背景

我有一个推送业务,会把每次推送记录都存到 MongoDB 中。

而推送业务一个非常常见的场景就是定时发送消息给用户,所以到点之后对应的每秒写请求就特别高。

当初我这边是有 8000 的每秒写入量,后面通过请求合并优化到每秒写 500。

3. 优化实现

现在问题来了,具体怎么实现的呢?

理清有 3 个小点就好了,我们顺着思路理一下:

1、首先,既然我们需要把多个请求合成一个,是不是需要有一个地方把这多个请求给存起来?

存数据的话,是不是就可以用数据库、缓存、队列了。如下图:

请求一下子太多了,数据库危-LMLPHP

好了,现在数据存起来了,不可能一直存着吧,一直存着不处理,岂不是就是不处理请求了,那这肯定不对。

2、所以我们是不是就需要知道,什么时候要处理存起来的数据?

「什么时候」—— 用定时任务每隔多久取出来处理是不是就可以,或者当存够多少数据量的时候,我们就集中处理。

我这里的业务是用的定时任务来做的,那关于定时任务的实现也有多种方式。

我这里是用的定时线程池,每隔 xx 秒,取 500 个请求进行处理。这里你发现没有,优化后的效果就是每秒写 500,这个 500 就是这里每次取得请求量来的。

所以说,优化效果要多少的处理量都是我们自己决定的。当然了,因为请求总量是不变得,所以每秒处理量越少,对应处理时间就越长。具体是什么数字,这个就看具体业务啦

3、最后一点,多个请求存起来了,也知道什么时机去处理,那这个「处理」是怎么处理呢?

答案很简单,把多个单次操作换成批量操作。比如数据库批量插入,redis 的 mset。

以上 3 点,给大家整理个流程图:

请求一下子太多了,数据库危-LMLPHP

4. 适用场景

最后,上面得优化姿势学废后,那什么业务场景可以用呢?

其实这个你想想,请求合并后的效果是怎样的,差不多也就知道了。

一开始说含义:(把多个)请求合并(成一个请求去处理)

这样的效果说明业务允许请求可以不用马上处理,高级用语就是数据实时性要求不高 —— 这是第一个业务场景特点

第二个特点:「请求合并」,业务得有一定的并发场景才有机会给你合并呀。不然你说每分钟才几个请求,那这不是合了个寂寞吗?(狗头)

5. 文末休息区(求关注)

其实很多优化方式都是朴实无华的,第一次听说时候可能会觉得牛蛙牛蛙,但实际接触了解后,会发现其实也没多高级。

不过,高级的优化方式肯定也是有的。就像我也很好奇,阿里京东这种亿级秒杀,微博的粉丝关系,抖音的推荐等等是怎么实现的。
倘若哪天真的有实际参与的大佬和我说,无非就是堆机器,没什么特别的,那我真的会尬住,哈哈哈哈。

请求一下子太多了,数据库危-LMLPHP

06-27 18:19