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
First, write first
How did message-oriented middleware work in your project? , we use a simple and easy to understand the market scene to introduce you to illustrate the use of a message middleware scenario.
We also showed examples of how the order service and warehouse service can send and receive messages based on MQ middleware, based on RabbitMQ’s HelloWorld level code.
Ii. Review of business scenarios
In this article, we delve a little deeper into some of the basic technical issues in the use of MQ middleware.
First, review an architecture diagram from the previous article to see how the order service and the messaging service send and receive messages based on MQ.
Let’s break this down a little bit. In simple terms, multiple order service instances push messages to queue, and multiple warehouse services each consume a portion of the message. As shown below:
Three, unexpected downtime, problems protruding
If your online use of MQ technology ends there, you can basically kiss the offer goodbye…
Because if it were me, I wouldn’t be able to follow up as an interviewer. If that’s the end of your depth of use and understanding of MQ, it’s basically a beginner level of MQ technology.
If the interviewer is going to follow up, it’s a good idea to ask the following questions:
- What happens if the warehouse service, as a consumer service, just receives an order message, but before completing the processing of the message, that is, before completing the warehouse dispatch for the order, the warehouse service suddenly goes down?
So, it’s important to know a little bit more about the technology, or you’ll be damned if you get asked a few questions.
Take a look at the picture below to get a feel for the crash site.
The default behavior of RabbitMQ middleware is to mark an order for deletion as soon as it is received by the storage service. This behavior is called automatic ack, where the delivery of a message automatically confirms that it has been processed.
But then if the warehouse service receives an order message, but does not have time to complete the dispatch of goods to the warehouse system, the result is directly down.
At this point, the order message is obviously lost, because RabbitMQ is no longer there…
What kind of awkward experience does that lead to? A user paid 8,999 yuan to place an order for an iphone8, only to wait several days for the website to show that his iphone8 was being shipped.
After a long time, the reason is that his order of iphone8 was in the storage service, and it directly broke down before dispatching the shipment. As a result, the order message has been lost, and the warehouse system has not been notified to the user for shipment.
Is that an awkward question? Therefore, technical problems can seriously affect the core business process of the enterprise!
Dear friends, remember the code of our warehouse service consumption message last time, there is a key code:
This line of code passes in the second argument to the channel.basicConsume()** method, true, which is actually the key argument.
This true represents a core meaning, which means that RabbitMQ will mark a message as deleted as soon as it is delivered to the storage service.
However, under this default configuration, if the warehouse service receives an order message and suddenly crashes before it has time to complete the business logic that takes tens of seconds to dispatch the goods, then the order message is permanently lost!
Looking for along while, the crux of the original problem is here ah! You see why I said at the end of the last article that this code has a lot of problems so far.
So at this point, if we want to avoid the loss of an order message due to the sudden outage of the warehouse service, we need to change the code of the warehouse service consumption message.
First, we need to change that parameter from true to false, as shown in the following code:
Once set to false, RabbitMQ will not blindly send messages to the repository and delete them immediately, in other words, turning off autoAck and assuming that the message was successfully processed.
Next, we need to modify the code that handles the order message, as shown below.
This code, in plain English, is a manual ACK in the finally block after dispatching the order, saying that I have finished processing the ten-second business logic myself and can now manually ack RabbitMQ that the message has been processed.
At this point, the entire architecture flow should look roughly like the figure below.
This means that the warehouse service will not manually send an ACK message to RabbitMQ in the code until it has completed the code business logic to ensure that the warehouse system has been notified.
RabbitMQ will receive the ACK message and mark the order message as deleted.
RabbitMQ will not receive an ACK for an order message if the warehouse service receives an order message but has not completed the business logic to dispatch the order.
Once RabbitMQ discovers that an instance of a warehouse service on behalf of a consumer has suddenly gone down, the warehouse service has received some order messages before it has had time to process them and has not ack itself for those messages.
RabbitMQ will automatically resend the order message to other running warehouse service instances to process it.
In this way, it is guaranteed that the order message will not be lost due to the outage of one of the warehouse service instances, and it will ensure that the dispatch processing of the order message must be completed by one of the warehouse service instances before the order message is deleted.
4. Summary tips
Here’s one last picture, just to give you an intuition:
Ok, everyone, is this article a little bit more in-depth to give you some considerations when using MQ technology?
In fact, RocketMQ, Kafka, and RabbitMQ all have similar mechanisms for autoAck or manual ack.
When running in an online production environment, you must consider the possibility that consumer services will go down.
If the consumer service itself goes down before processing the message, it is certain that some of the messages will be lost, which in turn affects the functioning of the core business process.
Therefore, when using MQ online, it is important to take full account of these potential problems, and to set up the API and parameters provided by MQ to ensure that messages are not lost at random.
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