Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to use message middleware to achieve distributed transactions in rest micro-services. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Let's use the previous example, the booking logic of a booking system:

The source code for this tutorial is available on github.

Message middleware is used to implement distributed transactions, that is, event-driven implementation. In this way, the Order service will not call the User service directly, but will send a message to MQ indicating that a new order needs to be deducted; the User service will respond to this message and process it, and then send a message after processing, indicating that a new order needs to be transferred; and then the Ticket service will process it. Each service deals with reading messages, processing business, and writing messages in a single transaction. The general process is as follows:

In this way, the processing of the order is asynchronous, when the user initiates an order, it only generates an order that is being processed, and then carries on the logic of deducting the fee, handing in the ticket, completing the order step by step through the message middleware. And the corresponding operations in each service are basically:

Read messages from a queue

Operate the corresponding database operation

Send a message to the next queue

That is, you need to manipulate both the database and MQ resources in this method, which is exactly the scenario in the example used in the previous article to introduce Spring internal and external transactions. Here is the rough code:

12345678@JmsListener (destination = "order:new", containerFactory = "orderFactory") @ Transactionalpublic void create (OrderDTO orderDTO) {Order order = new Order (orderDTO); order.setStatus ("PENDING"); orderRepository.save (order); jmsTemplate.convertAndSend ("order:need_to_pay", order);}

It listens to MQ's "order:new" queue, processes orders, and sends a message to "order:need_to_pay". The user service then receives the message, triggering the debit process.

In this place, we can use JTA transactions to use two-phase commit to achieve the common commit of two resources, but this will affect the performance of the system. Moreover, the message middleware that needs to be used implements the specification of XA and provides the function of two-phase commit.

Local transactions can also be used here, where everything has a Session of JMS and uses transactions. In this way, there is a database transaction and a JMS transaction, which are independent of each other and committed in turn. In this way, it is possible to make mistakes in very few cases, but some mistakes can be taken to solve them as much as possible. Let's expand the above transaction (pseudocode, just to illustrate the process) to see what went wrong and how to handle it:

1234567891011jmsTransaction.begin (); / / get transactions from jms sessiondbTransaction.begin (); / / get transactions from JDBC connectiontry {orderRepository.save (order); jmsTemplate.convertAndSend ("order:need_to_pay", order); dbTransaction.commit (); jmsTransaction.commit ();} catch (Exception e) {dbTransaction.rollback (); jmsTransaction.rollback ();}

In the above method, whenever an error occurs, even if the consumption of the MQ message fails, the MQ listener will trigger the method again.

At this point, if the error occurs in:

On or before the data is submitted. At this point, the operation of the entire database will be reset (or it may not have been updated at all), and there is no need to consider repeated commits when retrying, because previous commits have been rolled back.

Database commit succeeded, but JMS commit failed. At this point, you need to prevent repeated commits to avoid repeated operations in the database.

We can use the token method mentioned earlier to generate a unique token before calling this method. Here you use Java's UUID to generate an ID as token. If the repeated invocation here is only re-triggered within the service, there is no need to consider the global consistency of the distributed system ID. This needs to determine which UUID generation method is used according to the actual situation.) therefore, the ticket purchase request is accepted in the Controller as follows:

1234567@PostMapping (value = "/") @ Transactionalpublic void create (@ RequestBody OrderDTO orderDTO) {String uid = UUID.randomUUID () .toString (); orderDTO.setToken (uid); jmsTemplate.convertAndSend ("order:new", orderDTO);}

Then monitor the queue in Service to process ticket purchase:

123456789101112131415@JmsListener (destination = "order:new", containerFactory = "orderFactory") @ Transactionalpublic void create (OrderDTO orderDTO) {if (! this.processedUIDs.contains (orderDTO.getToken () {Order order = new Order (orderDTO); order.setStatus ("PENDING"); orderRepository.save (order); orderDTO.setStatus (order.getStatus ()); orderDTO.setId (order.getId ()); else {LOG.info ("Duplicate jms message: {}", orderDTO);} jmsTemplate.convertAndSend ("order:need_to_pay", orderDTO) ProcessedUIDs.add (orderDTO.getToken ());}

Simply put, the solution is to skip database-related processing and send the required data directly to the target queue of MQ if it is triggered repeatedly. So that the whole process can go down.

What I just said is an error within a service, and another error is that the order service and user service have finished the order creation and deduction operations, and then when it comes to the Ticket service, they find that there are no tickets left. Although we can avoid this problem by reasonably designing business logic, for example, check the user balance before the operation, check and lock the ticket, and then manipulate the data. However, in some cases, it is difficult to avoid this problem completely through the design of business processes. If this problem occurs, we can also implement it through the undo process, which is as follows:

In the above solution, the UUID class of JDK is used to generate an ID, which is actually guaranteed to be unique only within the current JVM. Secondly, in the JMS standard, there is no provision for a message's Listener to re-read a message after it fails to read a message. In a microservice environment, if an application deploys multiple instances, the message may be read by another instance. So in the above scenario, using the only ID within the JVM to put in the content of the message, it may be processed by any instance, and if the processing fails, it may be processed by another instance. That's going to go wrong. So we need a solution to generate a unique ID in a distributed environment. For example, first obtain the unique ID of JVM, and then add information such as IP+ port. Also, caching of ID that has been processed needs to be stored in a distributed environment.

Therefore, we can implement distributed transactions under the micro-service architecture without using two-phase commit. In this way, its advantages are:

It is easy to implement. Combined with Spring transactions, it can be implemented without writing additional transaction-related code. We just need better services to split and design business processes.

The system has high throughput. Because the database or MQ will not be locked for a long time, more transactions can be processed concurrently.

Good fault tolerance. Coordination between services is triggered by MQ, and even if a service stops while processing a task, the message remains until the service starts listening, and then continues to trigger the task.

Of course, this approach also has some disadvantages, the biggest problem is the problem of asynchronous processing. After the user makes a request, the service that handles the business is simply processed, sends a message to MQ to start the processing process, and then returns. At this time, the task is still being dealt with. Although sometimes we can wait for the finished message to be processed and then return it to the user. But then you have to consider the response time, timeout, various errors, and so on.

Some people will think that this approach complicates both development and debugging, but in my opinion, on the contrary, it makes development and debugging easier. First of all, according to the design principle of micro-service architecture, each service is responsible for only one functional module; secondly, according to the principle of object-oriented design, a method only does one thing. If we can split the service reasonably, and deal with each step, this is a good design. During maintenance, every method and step is clear about what to do.

When it comes to debugging, my principle is that you should find and resolve problems through unit tests, not debugging. Take the above ticketing process as an example. When each service triggers a method through MQ, its parameters and status should be clear. After the method is executed, what new data will be generated and what status will be updated should be clear. All of these can be well tested by unit testing. If each of your complex processes can be well tested by unit testing, then these methods can be concatenated together, not only to work well, but also to cope with a variety of abnormal situations.

The above is how to use message middleware to achieve distributed transactions in the rest micro-service shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.