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