Simply talk about the transaction compensation mechanism for Message Queuing

https://my.oschina.net/u/1589819/blog/1503241

Because always learn and try to be responsible for the company's push-related business, including the implementation of the entire application, which uses the message queue-based asynchronous event-driven model to do the decoupling asynchronous processing, so we have to do some knowledge of the relevant points, this side to summarize, and tidy up the message compensation mechanism of a simple implementation of the code design diagram.

When using the asynchronous event-driven model based on Message Queuing to solve the problem, a tricky problem is the consistency of the transaction.

Case: Now the user initiates a request to create an order, if we are a single system architecture, then modify the order table, modify the inventory table may be done in the same transaction, so it is easy to achieve the principle of consistency of things, but this is not what we want to discuss, so we took. Now the micro-service architecture in the internet company Fire Special Fire, the heat is not reduced, distributed is a matter of urgency to solve the problem, Alibaba Cloud GTS advertised how to make distributed transactions easier.

For example, a user initiates a request to create an order, first generates a new order on the order service, and then subtracts inventory from the inventory service, because it is a distributed architecture, so the inventory deduction and order creation may be on two remote machines, and if you want to solve it through local transactions it is almost impossible, Guaranteed state consistency between two transactions-order creation succeeded, inventory deduction failed, and how the order was rolled back. has always been a challenge in a distributed architecture that cannot be bypassed.

How to solve the transaction problem in the distributed architecture is discussed in many technical groups, such as Dubbo, Spring cloud and so on. There is no contact with the relevant knowledge, follow-up if you are fortunate to participate in, can do to share, this time want to talk about is false based on the message queue asynchronous event driver is how to solve the distributed problem, and how to ensure transactional consistency.

Transactional consistency principle (ACID):

Atomicity-atomicity, changing the state of the data is either done together or failed together

Consistency-consistency, the state of the data is intact and consistent

Isolation-isolation lines, even if there are concurrent transactions, do not affect each other

Durability-persistent, irrevocable once a transaction is committed

After the order is created, a createorderevent is sent to the message queue, which is forwarded by the message queue to the consumer who subscribes to the message.

Okay, this time. If the message is consumed successfully, but the inventory is insufficient, the inventory deduction fails, the order creation is not successful, this time is very good processing, by the inventory service pushes a subinventoryfail to the order service, the order service according to the message the order to the failure status.

1, from the user experience point of view, the entire process is asynchronous, so for the user's experience, can not be "immediate success or failure immediately" effect.

2, from a technical point of view, the whole process you no longer focus on the same thing, but the final order of the status of the consistency. Note: Transactional eventual consistency is guaranteed from distributed transactions <--> eventual consistency, but the successful implementation of decoupled transactions depends on several factors, based on the eventual convergence of this event-driven operation.

A, the delivery of the message is reliable.

b, the reliability of the message, such as the order service has successfully created the order, but not enough time to send the message on the outage or various reasons, resulting in inconsistent status of the order.

Based on the above two points, we used a scheme based on local transaction to guarantee the final consistency of the message.

Create orders and create message events both in the local transaction and in the same transaction, you can guarantee the data consistency between the order table and the Message event table. Sends a message to the message middleware, which is sent after the transaction commits. At the time of the inventory service, start a timed task to scan the message event table and consume the undelivered failed/consumed messages, that is, to compensate for transactional consistency.

Scheduled tasks may not be optimal and can be revised slightly, such as Alibaba's open source canal.

The company is also using this structure to solve orders and inventory issues. A Netizen's practice is to ensure the reliability of message delivery, we are to ensure the consistency of consumption, the specific article point I >>

Message Queuing can be encapsulated, made into a starter, the code is designed roughly as follows: