In actual services, the following scenarios often occur

After data is updated, an asynchronous message is sent to inform other services of subsequent processing

For example, after the user is activated, a message is sent to notify the third-party service to synchronize the user status

Then there will be the following code

@transactional public void enabled() {// updateUser status updateUser(); // Send the message sendMsg(); }Copy the code

This can be a problem if you write it this way

The transaction failed to commit and the message was sent successfully

So let me write it another way

The sendMsg (); Put it outside the transaction and wait for the transaction to commit successfully before sending the message

There is also a problem with this: the transaction commits successfully but the message fails to be sent

In both cases, business data can become abnormal

Transaction messages using RocketMQ solve this problem.

First we send a half-message in @Transactional. This half-message cannot be consumed at this time.

At the end of the database transaction, confirm the database transaction status and confirm that the execution is successful before sending a confirmation message to RocketMQ. Only then can the message be counted as complete and be consumed by the Consumer. In addition, the Broker periodically scans messages that have not been confirmed twice for a long time and proactively checks messages back to the Producer.

Achieve final consistency

Please comment on any fallacies