请求一下子太多了，数据库危

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

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

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

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

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

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

1. 什么是请求合并

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

如字面意思，就是（把多个）请求合并（成一个请求去处理）。

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

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

2. 业务背景

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

PS：不用在意是 MongoDB 哈，可能有的读者可能没接触过，没关系。反正它也是一个数据库，就算换成 MySQL，优化一样适用哈

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

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

3. 优化实现

现在问题来了，具体怎么实现的呢？

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

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

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

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

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

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

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

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

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

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

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

以上 3 点，给大家整理个流程图：

4. 适用场景

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

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

一开始说含义：（把多个）请求合并（成一个请求去处理）

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

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

5. 文末休息区（求关注）

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

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

如果觉得文章不错，欢迎关注我的公众号：七淅在学Java