Too many requests all at once, the database is in danger

Hello everyone, my name is Qixi (xī).

As the title says, I will share with you a business scenario that I have optimized.

Of course, the specific business details are not important, what is important is the idea of optimization. If you encounter a scenario with similar characteristics in the future, you can think of Qixi's optimization article, then I think it's worth it.

Next, I will go directly to the topic, and the optimization idea to share is to request a merge .

Weakly speaking, because the optimization effect is particularly obvious, I wrote this optimization directly on the resume.

In the previous interview, many interviewers would come to ask me how I did it. Don't you think this will give me a chance to play? So everyone knows, remember to use it when there is a suitable scene, and chat with the interviewer in the future interview.

1. What is pull request

First of all, this is not an advanced optimization method, it is not difficult, unpretentious, but useful.

Literally, it is to combine (multiple) requests (to process them into one request).

Now you know the meaning, now let's look at the title of the article: "Too many requests all at once, the database is in danger"

Smart, have you guessed how Qixi is going to be optimized?

2. Business Background

I have a push business that will store each push record in MongoDB.

PS: Don't worry about MongoDB, maybe some readers may not have been exposed to it, it doesn't matter. Anyway, it is also a database, even if it is replaced with MySQL, the optimization is still applicable.

A very common scenario in the push business is to send messages to users at regular intervals, so the corresponding write requests per second after reaching the point are particularly high.

At first, I had 8,000 writes per second on my side, and then it was optimized to 500 writes per second through request merging.

3. Optimization implementation

Now the question is, how to achieve it?

It's good to have 3 small points to sort out, let's sort it out along the way:

1. First of all, since we need to combine multiple requests into one, is there a place to store these multiple requests?

If you store data, can you use databases, caches, and queues? As shown below:

Well, now that the data is stored, it is impossible to keep it forever.

2. So do we need to know when to process the stored data?

"When" - Is it okay to use the timed task to process it every how often, or when there is enough data, we will process it centrally.

My business here is done with timed tasks, and there are many ways to implement timed tasks.

I am using the timing thread pool here, and every xx seconds, 500 requests are taken for processing. Here you find no, the effect of optimization is to write 500 per second, and this 500 is the amount of requests obtained each time here.

Therefore, it is up to us to decide how much processing volume the optimization effect requires. Of course, because the total number of requests does not change, the less processing per second, the longer the corresponding processing time. The exact number depends on the specific business.

3. The last point, multiple requests have been saved, and we know when to process them. How to deal with this "processing"?

The answer is simple, replace multiple single operations with batch operations. Such as database batch insertion, redis mset.

For the above 3 points, we will sort out a flowchart for you:

4. Applicable scenarios

Finally, after the above has to optimize the posture, what business scenarios can be used?

In fact, if you think about it, you can almost know what the effect of the merge request will be.

At the beginning, the meaning: (multiple) requests are merged (to be processed into one request)

This effect shows that the business permission request does not need to be processed immediately, and the advanced term is that the real-time data requirements are not high - this is the first feature of the business scenario

The second feature: "request to merge", the business has to have a certain concurrent scenario to have the opportunity to merge for you. Otherwise, if you say that there are only a few requests per minute, isn't this a loneliness? (dog head)

5. Rest area at the end of the article (please pay attention)

In fact, many optimization methods are simple and unpretentious. When you hear it for the first time, you may think that the bullfrog is a bullfrog, but after the actual contact and understanding, you will find that it is not very advanced.

However, there are certainly advanced optimizations. Just like I am also curious, how Ali Jingdong’s billion-level instant kill, Weibo’s fan relationship, Douyin’s recommendation, etc. are achieved.
If one day a big guy who actually participated told me that it was nothing more than a pile of machines, nothing special, then I would really be embarrassed, hahahaha.

If you think the article is good, please pay attention to my public account: Qixi is learning Java