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