大家好,我是七淅(xī)。
如标题所说,和大家分享一个我曾优化过的业务场景。
当然,具体业务细节不重要,重要的是优化的思路。如果大家以后有遇到类似特点的场景,能够想到七淅这篇优化文章,那我就觉得很值了。
接下来我就直接进入主题,要分享得优化思路就是请求合并。
弱弱说一句,由于优化效果特别明显,这一优化我直接写到简历上了。
之前面试有不少面试官都会来问我是怎么做的,你看这不就给我机会发挥了吗?所以大家懂的,有合适场景记得用起来,以后面试也和面试官谈笑风生。
1. 什么是请求合并
首先说明一下,这并不是什么高级的优化方式,不难,朴实无华,但有用。
如字面意思,就是(把多个)请求合并(成一个请求去处理)。
现在含义你知道了,现在我们看下文章标题:「请求一下子太多了,数据库危」
聪明的你是不是已经猜到七淅要怎么优化了?
2. 业务背景
我有一个推送业务,会把每次推送记录都存到 MongoDB 中。
PS:不用在意是 MongoDB 哈,可能有的读者可能没接触过,没关系。反正它也是一个数据库,就算换成 MySQL,优化一样适用哈
而推送业务一个非常常见的场景就是定时发送消息给用户,所以到点之后对应的每秒写请求就特别高。
当初我这边是有 8000 的每秒写入量,后面通过请求合并优化到每秒写 500。
3. 优化实现
现在问题来了,具体怎么实现的呢?
理清有 3 个小点就好了,我们顺着思路理一下:
1、首先,既然我们需要把多个请求合成一个,是不是需要有一个地方把这多个请求给存起来?
存数据的话,是不是就可以用数据库、缓存、队列了。如下图:
好了,现在数据存起来了,不可能一直存着吧,一直存着不处理,岂不是就是不处理请求了,那这肯定不对。
2、所以我们是不是就需要知道,什么时候要处理存起来的数据?
「什么时候」—— 用定时任务每隔多久取出来处理是不是就可以,或者当存够多少数据量的时候,我们就集中处理。
我这里的业务是用的定时任务来做的,那关于定时任务的实现也有多种方式。
我这里是用的定时线程池,每隔 xx 秒,取 500 个请求进行处理。这里你发现没有,优化后的效果就是每秒写 500,这个 500 就是这里每次取得请求量来的。
所以说,优化效果要多少的处理量都是我们自己决定的。当然了,因为请求总量是不变得,所以每秒处理量越少,对应处理时间就越长。具体是什么数字,这个就看具体业务啦
3、最后一点,多个请求存起来了,也知道什么时机去处理,那这个「处理」是怎么处理呢?
答案很简单,把多个单次操作换成批量操作。比如数据库批量插入,redis 的 mset。
以上 3 点,给大家整理个流程图:
4. 适用场景
最后,上面得优化姿势学废后,那什么业务场景可以用呢?
其实这个你想想,请求合并后的效果是怎样的,差不多也就知道了。
一开始说含义:(把多个)请求合并(成一个请求去处理)
这样的效果说明业务允许请求可以不用马上处理,高级用语就是数据实时性要求不高 —— 这是第一个业务场景特点
第二个特点:「请求合并」,业务得有一定的并发场景才有机会给你合并呀。不然你说每分钟才几个请求,那这不是合了个寂寞吗?(狗头)
5. 文末休息区(求关注)
其实很多优化方式都是朴实无华的,第一次听说时候可能会觉得牛蛙牛蛙,但实际接触了解后,会发现其实也没多高级。
不过,高级的优化方式肯定也是有的。就像我也很好奇,阿里京东这种亿级秒杀,微博的粉丝关系,抖音的推荐等等是怎么实现的。
倘若哪天真的有实际参与的大佬和我说,无非就是堆机器,没什么特别的,那我真的会尬住,哈哈哈哈。
如果觉得文章不错,欢迎关注我的公众号:七淅在学Java
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。