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