Welcome to follow our wechat official account: Shishan100
My new course ** “C2C e-commerce System Micro-service Architecture 120-day Practical Training Camp” is online in the public account ruxihu Technology Nest **, interested students, you can click the link below for details:
120-Day Training Camp of C2C E-commerce System Micro-Service Architecture
Previously on
Why did you introduce message-oriented middleware into your system architecture? , to tell you about the role of message-oriented middleware in system architecture, mainly to solve what problems.
Its more common practice scenarios are:
- Decoupling of complex systems
- Asynchronous invocation of complex links
- Instantaneous peak cutting processing
Two, official start
In this article, what are the disadvantages if you introduce message-oriented middleware into your system architecture?
1) Decreased system availability
The first is that the overall usability of your system will definitely decrease. To give you an example, let’s use the previous picture.
For example, in A core link, system A -> system B -> System C, and then system C calls system D asynchronously via MQ.
It looks good that you have solved a core link execution problem with this MQ asynchrony approach.
But have you considered the possibility that the MQ middleware you rely on suddenly dies? MQ, Redis, MySQL are all likely to fail.
Once your MQ fails, the core business process of your system is interrupted. If you didn’t introduce MQ middleware, it would have been a call between systems, but now that you have introduced MQ, you have one more dependency. Once you have one more dependency, it makes you less available.
Therefore, once MQ middleware is introduced, you must consider how this MQ will be deployed and how to ensure high availability.
Even in complex high-availability scenarios, you need to consider whether your system has a back-up technical solution to keep it going if MQ fails.
I wrote two previous articles on high availability guarantees after MQ fails.
If you are interested, please refer to:
- How do final consistent distributed transactions ensure 99.99% high availability in real production?
- How to design a full link 99.99% high availability Architecture
In these two articles, take a detailed look at the high availability downscaling scenarios that we take when MQ fails.
2) The system stability decreases
That’s the same picture. Let’s see it again.
I don’t know if you have noticed a problem, but this link may have some other technical problems besides the potential pitfalls of MQ middleware failure.
For example, for no apparent reason, system C sends a message to MQ, and the message is lost due to network failure, etc. This results in system D not receiving the message.
This will lead to system D not complete its own tasks, at this time the whole system may appear business confusion, data loss, serious bugs, poor user experience and other problems.
This is just one of them. If system C sends a message to MQ and accidentally sends a duplicate message, what can be done?
System D may insert the same data twice at a time, resulting in data errors, dirty data, and finally various problems.
Or what if system D suddenly goes down for a few hours, making it impossible to consume messages and resulting in a huge backlog of messages in the MQ middleware?
Even if system D recovers, it will slowly consume data for processing.
So this is the second big problem with the introduction of MQ middleware, system stability can degrade, failures can increase, and all sorts of messy things can happen.
And once a problem occurs, it can lead to problems with the system as a whole. A number of technical solutions are required to address the various technical issues raised by MQ.
In this regard, we will devote a later article to addressing these issues with MQ middleware, including:
- High reliable message delivery (0 missing)
- Message idempotent delivery (never repeated)
- Millions of messages backlogged online troubleshooting
3) Distributed consistency problem
Introducing message-oriented middleware, there is also the issue of distributed consistency.
For example, if system C now successfully processes its own local database and sends a message to MQ, system D does consume it.
Unfortunately, system D fails to operate on its own local database.
If system C succeeds, and system D fails, the overall system data will be inconsistent.
Therefore, it is necessary to use the distributed transaction scheme of reliable message final consistency.
For this, refer to a previous article:
How do final consistent distributed transactions ensure 99.99% high availability in real production?
We elaborate how to use distributed transaction scheme to ensure data consistency in asynchronous call scenario between systems.
Third, summary
Finally, let’s make a simple summary.
To answer this question in an interview, be familiar with the pros and cons of MQ technology. Find out what problems you brought him into the system to solve, but what problems he himself might cause.
In addition, is there any solution design for the problems that MQ can cause when it is introduced to ensure that your system is highly available and reliable, and that data is consistent? This is also prepared accordingly.
END
If there is any harvest, please help to forward, your encouragement is the biggest power of the author, thank you!
A large wave of micro services, distributed, high concurrency, high availability of original series of articles is on the way
Please scan the qr code belowContinue to pay attention to:
Architecture Notes for Hugesia (ID: Shishan100)
More than ten years of EXPERIENCE in BAT architecture