Welcome article series, pay attention to my the promotion ability, pay rise to stay in the knowledge of the interview, work can be “the practice, refused to 996 also welcome attention WeChat number public blog 】 【 Ccww technology, original technical articles to launch the first time If this article helpful to you, like, that point a bai, a focus on bai!

“Power up, Pay Up” – Why use MQ messaging middleware

Scenario 1: System decoupling

Suppose you have system A, and system A produces A core data, and now downstream systems B and C need to use this data.

The easiest thing to think about is that system A just calls the interfaces of system B and system C and sends data to them

But what if there’s system D, system E, system F, system G, and so on, and a dozen other systems need this core data?

Is this the most awkward question that can arise for a developer?

First, someone comes to him and asks him to send data to A new system H, and the student in system A has to modify the code and put in that code the flow of calling the new system H. Later, system B is an old system and will go offline. Tell the students of System A: Don’t send me the data, and then system A will modify the code again and no longer send it to system B.

So what do we do now? The coupling of the system is so high, which is really affecting the whole body, small needs need big changes, why? 2

Now that we have the protagonists, we can use MQ messaging middleware to decoupler our systems.

This can achieve a compilation need not change, who love who to change, anyway I do not change.

Conclusion: Through the use of MQ messaging middleware, refactoring the coupling between systems to make the system highly scalable.

Scenario 2: Asynchronous invocation

Suppose you have A system call link. System A calls system B, which usually takes 20ms. System B calls system C, which usually takes 200ms. System C calls system D, which usually takes 2s

20ms + 200ms + 2000ms (2s) = 2220ms,

That’s more than two seconds. But in reality, system A on the link calls system B, and system B calls system C, and these two steps add up to 220ms.

At this time the leading role and slowly come over, this can not handle, is not very simple?

The realization idea is system A -> system B -> system C, directly cost 220ms directly successful.

System C then sends a message to the MQ middleware, which is consumed by system D and then slowly asynchronously performs the 2s business process. In this way, the execution performance of the core link is improved by 10 times.

Conclusion:

  • 1) For users, it is faster than synchronization, and the user experience is very good. (Make users think they have it, deceive ING)
  • 2) For the system access pressure, asynchronous because it is not really implemented, will not cause a sharp increase in the system access pressure at a certain moment, but put into a queue, slowly to consume!

Scenario 3: Peak traffic Clipping

Suppose you have a system that normally receives hundreds of requests per second. The system is deployed on an 8-core 16GB machine, and the normal processing is OK. Hundreds of requests per second can be easily resisted. Such as seckill

In the second kill activity at the peak of a sudden to thousands of requests per second, a snap of a wave of traffic peak.

If the machine goes down, the company can lose a lot of money. M: You should be prepared to get yelled at by your boss, maybe even say goodbye

May think of a solution, online deployment of many machines, a more than one winning method:

However, if you deploy a lot of machines online just for this particular activity, it’s a bit of a waste of machine resources.

So at this time, MQ big brother appeared again, not afraid, this is not me?

Bottom line: Peak peaking is essentially more deferring user requests and filtering user access requirements to minimize the number of requests that end up in the database.

conclusion

Decoupling and reuse

System to send A message to A multiple system, if the increase A system, each system A need by modifying the source code to increase the interface, the coupling is very high, but if using the message queue, the system needs to be sent only to the message queue, the other system can reuse this information, when the add or delete the system call interface, No additional update code is required.

asynchronous

When a user calls an interface, the interface may call another method. For example: user registration, the background may need to call: query database, insert database, send mail, send user guide and so on…

However, the user may not need to complete all the tasks in the background, and then join the MQ queue after the initial data entry, the user can quickly get a successful registration response and do something else. The MQ mechanism guarantees ultimate consistency, so it is safe and stable to use.

Peak clipping

What is peak clipping, is when the system pressure is too large, let the system pressure reduce. How to do?

For example, at normal times, database reads and writes may be several hundred per second, while at peak times, system accesses reach 10,000 per second. At this point, the system will not crash due to a surge of access because it is enqueued.

Peak clipping does not reduce the user’s wait time, so it is usually used with asynchron

Finally, MQ has other scenarios, such as notifications, data distribution, and so on, that demonstrate the benefits of using MQ middleware.

Is everyone still ok? If you like, move your hands to show 💗, point a concern!! Thanks for your support!

Welcome to pay attention to the public number [Ccww technology blog], original technical articles launched at the first time