Explain in detail the request merging of hystrix in spring cloud

In the microservice architecture, we split a project into many independent modules. These independent modules work together through remote calls. However, in the case of high concurrency, the increase of communication times will increase the total communication time. At the same time, the resources of thread pool are also limited. In the high concurrency environment, a large number of threads will be waiting, In order to solve these problems, we need to understand the request merging of hystrix.

Request merging in hystrix is to use a merge processor to merge continuous requests initiated by the same service into one request for processing (the time window of these continuous requests is 10ms by default). A core class involved in this process is hystrixcollapser. OK, let's see how to realize the request merging of hystrix.

Service provider interface

I need to provide two interfaces in the service provider for service consumers to call, as follows:

The first interface is a batch interface, and the second interface is an interface that processes a single request. In the batch processing interface, the format of the IDS parameter sent by the service consumer is 1,2,3,4... In this format, under normal circumstances, we need to query the corresponding data according to the IDS, and then assemble it into a set for return. Here, for processing convenience, all requests return the same data set; The interface for processing a single request is relatively simple and will not be repeated.

Service consumers

OK, after the service provider handles it, let's take a look at how the service consumer handles it.

BookService

First, add two methods in bookservice to call the interface provided by the service provider, as follows:

Test8 is used to call the interface providing a single ID, and Test9 is used to call the batch interface. In Test9, I print out the thread in which Test9 executes, so that we can observe the execution results. In addition, in resttemplate, if the return value is a collection, we must first receive it with an array, Then turn to gathering (there may be other ways, and the partners have better suggestions to put forward).

BookBatchCommand

OK, after the methods in bookservice are ready, we can create a bookbatchcommand, which is a batch command, as follows:

This class is similar to the class we introduced in the last blog. It is inherited from HystrixCommand, which is used to handle requests after merging. In the run method, the Test9 method in BookService is called.

BookCollapseCommand

Next, we need to create bookcollapsecommand inherited from hystrixcollapser to implement request merging. As follows:

About this class, I say the following:

1. Firstly, in the construction method, we set the request time window to 100ms, that is, requests with a request time interval of 100ms will be merged into one request.

2. The createcommand method is mainly used to merge requests, obtain the IDs of individual requests here, put these individual IDS into a collection, and then create a bookbatchcommand object to initiate a batch request.

3. Mapresponsetorequests method is mainly used to set request results for each request. The first parameter of the method, batchresponse, represents the results of batch requests, and the second parameter, collapsedrequests, represents each merged request. Then we set the request results for collapsedrequests by traversing the batchresponse.

OK, after all these operations are completed, we can test it.

test

We create an access interface at the service consumer to test the merge request. The test interface is as follows:

About this test interface, I say the following two points:

1. First initialize the hystrixrequestcontext

2. Create an instance of bookcollapsecommand class to initiate a request. First send three requests, then sleep for 3 seconds, and then initiate one request. In this way, the first three requests will be merged into one request. The fourth request will not be merged because the interval is long, but will be processed by creating a separate thread. OK, let's take a look at the execution results, as follows:

Request merging through annotations

OK, the above request merging method is a little troublesome. We can use annotations to implement this function more gracefully. First, add two methods in bookservice, as follows:

Add @ hystrixcollapser annotation on Test10 method to realize request merging, indicate the processing method after request merging with batchmethod property, and specify other properties with collapserproperties property.

OK, after writing it in bookservice, you can call it directly, as follows:

As before, the first three requests will be merged, and the fourth request will be executed separately. OK, the execution results are as follows:

summary

We have seen the advantages of request merging. Multiple requests are merged into one request for one-time processing, which can effectively save network bandwidth and thread pool resources. However, there are advantages and disadvantages. After setting request merging, a request may be completed in 5ms, but now we must wait 10ms to see if there are other requests together, The time-consuming of such a request increases from 5ms to 15ms. However, if the command to be initiated is a command with high delay, request merging can be used at this time, because the time consumption of the time window is insignificant. In addition, high concurrency is also a very important scenario of request merging.

OK, that's all for our request for merger. If you have any questions, please leave a message for discussion. I hope it will help you in your study, and I also hope you can support programming tips.