preface
In the last article, The prince analyzed how the information was lost through a small case with his friends, but did not propose specific solutions.
We already know that there are three main reasons for message loss:
1. The message is lost when the producer sends a message to MQ
2.MQ is faulty and messages are lost
3. After consumers get the message, the message is lost due to improper operation
In the first case, let’s talk about how to solve the problem of message loss when a producer sends a message.
First send the half message to MQ
RocketMQ comes with a solution to this problem, transactional messages. Today we will look at the implementation flow of transaction messages.
Again, when a user places an order payment through the order system, a message is sent to MQ after the order payment is successful, but this process is not guaranteed to be transactional.
When we introduce transaction messages, the order system does not perform CRUD operations first, but sends a half message to MQ. This half message is the order payment completion message, which you can interpret as being in the half state.
The points system cannot consume half state messages.
After sending the half message, the order system waits for A successful response from MQ, as shown below:
Some of you may be wondering, why send the half message?
Actually you can think about it, if we don’t send half, to operate the database directly, the payment business through, and then to send a message to MQ, results in the process of sending exception happens, this leads to the integral system can’t consumption to the message, will cause the payment is successful, and the integral without issue.
So we send a half message first to verify that the message can be sent properly, or that MQ is still alive, and to tell MQ that the next message is too important to lose.
What if the half message fails to write
The delivery of the half message can also fail, either because of an error, MQ itself hung up, or because of network problems.
The order system will get this feedback, and then it should roll back, such as order closure, refund, etc.
The half message was written successfully and the response was received
So what should the order system do if the half message is sent successfully and a successful response is received?
At this time, the order system should operate the database to complete their own business functions.
Since the half message was sent successfully, MQ can receive messages normally.
The half message was written successfully without a response
So what if the half message is sent successfully, but there is no successful response from MQ?
At this point, the half message is normally stored in MQ, but the order system does not get a response and may report some network timeout error, and the order system will perform the rollback operation.
So what do you do with the half message?
This brings us to RocketMQ’s compensation mechanism, which scans for the half message. If the half message has not been rolled back or committed, it will call back to one of the compensation interfaces in the order system after a certain amount of time to determine whether the operation succeeded or failed.
If successful, resend the COMMIT message to MQ, and if failed, resend the ROLLBACK message to MQ. The ROLLBACK and COMMIT messages are covered later.
The database operation is abnormal. Procedure
So what happens next if an exception occurs when the order system executes the database?
At this point, the database itself has a transaction mechanism, and we can send a ROLLBACK message to MQ.
When MQ receives the ROLLBACK message, it invalidates the previous half message.
After the order business is completed
So what does the order system do after its own business has successfully completed?
At this point, a COMMIT message is sent to MQ to commit the previous half message, which can then be seen by the points system.
Rollback or commit What if messages fail to be sent
Rollback or COMMIT messages can also fail, which is easy.
We’ve already talked about RocketMQ’s compensation mechanism, so whether the order system itself is sending a ROLLBACK message or a COMMIT message, if it fails, MQ’s compensation mechanism scans the half message and after some time calls back to the compensation interface of the order system to determine whether the execution was successful. Then resend the message to MQ
conclusion
Today we looked at the various scenarios of RocketMQ sending messages and found that the message reliability of the producer sending messages to MQ can be guaranteed when the transactional messaging process is turned on.
If you feel there are some things you haven’t considered, please leave a comment in the comments section.
In the next article, we will delve into the underlying implementation of transaction messaging.
Previous articles recommended:
RocketMQ’s sending mode and consumption mode
Discuss the technical difficulties and solutions of seckill system
Second kill system in inventory reduction and flow peak peaking
Delve into the underlying mechanics of sending messages by RocketMQ producers
Delve into how brokers are persisted
How does Dledger implement automatic master/slave switchover
Dig deeper into how RocketMQ consumers get their messages
How did the RocketMQ message get lost