Request merging method based on rolling time window

Abstract

The present invention relates to a request merging method based on a rolling time window, which belongs to the field of server-side data interaction and processing, and includes the following steps: S1, the requester sends a resource acquisition request to the object server through the client, and the server-side proxy module receives the request of the requester; S2, the server-side proxy module screens out the network requests to be merged, and extracts the corresponding resource identifiers from the network requests; S3, the proxy module puts the asynchronous results obtained by the requests with the same behavior into the same queue, registers the binding relationship between the asynchronous result queue and the logical processor, and then releases the working thread, etc. The advantages of the present invention are: (1) It can effectively identify and merge requests for the same resources, does not actively trigger the calculation logic when no request is received, and reasonably utilizes the server resources to the greatest extent. (2) It supports the 1:N:M relationship between resources, request types, and user requests, so that the optimization and merging are applicable to a wider range of dimensions.

Description

Technical Field

[0001] The present invention relates to a request merging method based on a rolling time window, and belongs to the field of server-side data interaction and processing. Background Art

[0002] NIO (Non-blocking I / O) is a synchronous non-blocking I / O model and the basis of I / O multiplexing. It has been increasingly applied to large application servers and has become an effective way to solve high concurrency, large number of connections, and I / O processing problems. Compared with traditional methods, NIO introduces buffers and data stream channels for I / O operations, thereby providing faster execution and better performance. In addition to supporting buffer-oriented, channel-based I / O operation methods, NIOAPI also provides selectors, which introduce the ability to listen to multiple I / O event channels in an asynchronous or non-blocking manner. In NIO, the most time-consuming I / O activity is usually filling and refreshing the buffer to the operating system, which further improves the overall performance through asynchronous or non-blocking methods.

[0003] In the most common request-response scenarios of application software, sometimes the server cannot complete the processing of the request quickly. They need to wait for the database connection to be available, wait for the response from the remote service, wait for the message processing to return, wait for the application event, or wait for any type of long-running task. Based on the NIO asynchronous processing mode, the request thread is allowed to exit and return to the container's thread pool to process other requests, while the time-consuming request continues to run in the background thread until the response is returned after the processing is completed.

[0004] In some application service architectures, data changes are required to be reflected to users in real time, which involves the choice of data interaction mode, which is usually divided into push mode and pull mode; server push is generally implemented using WebSocket, but due to its high dependence on the network environment, it is not suitable for all scenarios; the pull mode will initiate multiple identical network requests at the same time, resulting in a waste of network resources and server resources. Using request merging can effectively prevent the server from processing multiple requests for the same data at the same time, reducing resource consumption for repeated calculations. Currently, common request merging components on the market only support merging processing based on fixed duration and fixed number of requests, which cannot meet the scenario of elastic changes in request processing duration.

[0005] In summary, the prior art does not provide good support for high-concurrency request server processing solutions that take a long time and have variable time consumption, and a request merging solution based on a variable time window is needed. Summary of the invention

[0006] In order to overcome the defects of the prior art, the present invention provides a request merging method based on a rolling time window. The technical solution of the present invention is:

[0007] A request merging method based on a rolling time window includes the following steps:

[0008] S1. The requester sends a resource acquisition request to the object server through the client, and the server proxy module receives the requester's request;

[0009] S2, the server proxy module filters out the network requests to be merged and extracts the corresponding resource identifiers from the network requests;

[0010] S3. The proxy module places the asynchronous results obtained by requests with the same behavior in the same queue, registers the binding relationship between the asynchronous result queue and the logical processor, and then releases the working thread;

[0011] S4. After the proxy module registers the binding relationship, it uses the action identifier as a keyword to initialize or reuse the thread pool to execute the resource acquisition processing logic;

[0012] S5. Control the number of core threads and queue length in the thread pool, run the acquisition logic of each resource in a rolling time window mode, and hand over the results to the result distribution thread pool for result distribution after the results are obtained;

[0013] S6. After receiving the execution result, the result dispatching thread pool searches the response result queue according to the action identifier, and then determines the resource receiver range in the queue according to the time information in the result;

[0014] S7. Before returning the result, call the custom result processor in a responsibility chain manner, use CopyOnWrite combined with a shallow copy method to filter and modify the result set to obtain personalized information;

[0015] S8. The result dispatching thread sets the return content according to the obtained result and returns the result to the request initiator.

[0016] In step S2, the proxy module is configured with the rule name and processing method for each resource, and adds the information of the initiation time, resource name and execution action on the basis of the original request.

[0017] In the step S3, the specific steps are:

[0018] 3-1. The proxy module has built-in dependent processing methods, request parameters, and return result view codes;

[0019] 3-2. According to the view code and request parameters, refer to the configured binding relationship template. The binding relationship template is the relationship between the action and the view. The mapping uses the HASHMAP data structure and supports one-to-many. That is, the result of one behavior is reused by multiple views. If not configured, it is bound by one-to-one relationship by default to obtain the action code.

[0020] In the step S4, the resource identifier and the asynchronous result queue, the resource identifier and the action identifier, and the action identifier and the action to be executed are configured, wherein the action identifier and the resource identifier are configured in a one-to-many relationship.

[0021] In step S5, the thread pool is set to have a core thread number of 1, a queue length of 2, and a rejection strategy of discarding the most recent request; in this way, the asynchronous processing logic is implemented in the form of a rolling window.

[0022] The advantages of the present invention are:

[0023] (1) It can effectively identify and merge requests for the same type of resources, and does not actively trigger the calculation logic when no request is received, so as to maximize the rational use of server resources.

[0024] (2) Supports the 1:N:M relationship between resources, request types, and user requests, making the optimization and merging applicable to a wider range of dimensions.

[0025] (3) Provide personalized filtering and expanded processing capabilities for response results to apply to more business scenarios.

[0026] Utilizing the asynchronous programming capability of the framework, the proxy module receives the designated request and quickly releases the working thread of the web container; merges and optimizes the request, extracts the resource identifier from the request to be merged, puts the asynchronous result of the request with the same resource identifier into a blocking queue with time as the priority, and binds the resource identifier to the asynchronous result queue; obtains the action identifier corresponding to the resource identifier according to the configuration, binds the action identifier to the request processing method; and associates the action identifier with the resource identifier; uses the thread pool technology to entrust the processing method to the thread pool for execution, and realizes the operation of the request processing logic in a rolling time window manner; after the processing logic is completed, obtains the priority blocking queue of the result to be responded to through the resource binding relationship, determines the response result range according to the starting time point of the processing logic, sets the result, and returns it asynchronously to the request initiator. The management method described in the present invention effectively avoids the repeated execution of the same resource acquisition logic, reduces the consumption of server-side memory and IO, saves a large amount of network resources and server resources, and improves the scalability and throughput of cluster services. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a schematic diagram of the rolling window processing flow of the present invention.

[0028] Figure 2 It is a workflow diagram of the request merging agent module of the present invention. DETAILED DESCRIPTION

[0029] The present invention will be further described below in conjunction with specific embodiments, and the advantages and features of the present invention will become clearer as the description proceeds. However, these embodiments are exemplary only and do not constitute any limitation to the scope of the present invention. It should be understood by those skilled in the art that the details and forms of the technical solution of the present invention may be modified or replaced without departing from the spirit and scope of the present invention, but these modifications and replacements all fall within the scope of protection of the present invention.

[0030] See also Figure 1 and Figure 2 The present invention relates to a request merging method based on a rolling time window, comprising the following steps:

[0031] S1. The requester sends a resource acquisition request to the object server through the client, and the server proxy module receives the requester's request;

[0032] S2, the server-side proxy module relies on the asynchronous programming support of the framework and web container, such as using the SpringWeb framework of the servlet3.0 specification to filter out the network requests to be merged and extract the corresponding resource identifiers from the network requests;

[0033] S3, the proxy module places the asynchronous results obtained by the requests with the same behavior in the same queue, registers the binding relationship between the asynchronous result queue and the logical processor, and then releases the working thread; in the step S3, the specific steps are:

[0034] 3-1. The proxy module has built-in dependent processing methods, request parameters, and return result view codes;

[0035] 3-2. According to the view code and request parameters, refer to the configured binding relationship template. The binding relationship template is the relationship between the action and the view. The mapping uses the HASHMAP data structure and supports one-to-many. That is, the result of one behavior is reused by multiple views. If not configured, it is bound by one-to-one relationship by default to obtain the action code.

[0036] In step S3, the resource identifier obtained needs to execute the rule configuration in step S1 in advance, otherwise each resource corresponds to a unique action identifier according to the default rule. Requests with the same rule are maintained in a queue according to the time priority of the request arriving at the server. Concurrent containers are used to ensure that the elements in the queue strictly follow the time order, and the head of the queue is the earliest request.

[0037] S4. After the proxy module registers the binding relationship, it uses the action identifier as a keyword to initialize or reuse the thread pool to execute the resource acquisition processing logic;

[0038] S5. Control the number of core threads and queue length in the thread pool, run the acquisition logic of each resource in a rolling time window mode, and hand over the results to the result distribution thread pool for result distribution after the results are obtained;

[0039] S6. After receiving the execution result, the result dispatching thread pool searches the response result queue according to the action identifier, and then determines the scope of resource recipients in the queue according to the time information in the result; the search program is implemented through the binding relationship; when determining the scope, the asynchronous result of the request started before the start time of the action execution is searched.

[0040] S7. Before returning the result, call the custom result processor in a responsibility chain manner, use CopyOnWrite combined with shallow copy to filter and modify the result set to obtain personalized information; consider the personalized processing support for requests, and because the returned result set is shared by multiple responses, use the copy-on-write technology and shallow copy priority principle to avoid memory expansion.

[0041] S8. The result dispatching thread sets the return content according to the obtained result and returns the result to the request initiator. The result setting depends on the framework layer to return the response, and the one implemented by the setResult method of DeferredResult of the Spring framework is used.

[0042] like Figure 1 As shown, after the server receives the first request to be merged at time point T1, it starts to create an asynchronous return result, hands it over to the proxy module requesting the merge for processing, and then returns the asynchronous result. At this time, the time is between T1 and T2.

[0043] The proxy module creates a binding relationship and registers it in the context; then it starts to execute the processing logic, starting at time T2.

[0044] After the processing logic is executed, the queue is checked to find that there is something to be done, and the next execution begins, corresponding to time point T3 (the time spent checking the queue can be ignored). Repeat according to this logic, and each time window corresponds to the processing time of a single logic. S1~E1 corresponds to the first logic processing from the beginning to the return result, and so on. S2~E2 and S3~E3 are the processing time of the second and third times.

[0045] To ensure that the query result returned is the latest result after the query starts for the requester, it is necessary to ensure that the processing time window corresponding to the returned result starts after the request enters the service, that is, the returned results corresponding to requests 1 to 10 are provided by the returned results corresponding to window 1, requests 11 to 100 are provided by the returned results of window 2, and requests 101 to 240 are provided by the returned results of window 3.

[0046] like Figure 2 As shown, the proxy module is based on the support of the framework and container for asynchronous programming. The internal design and implementation fully refers to the NIO processing mode, making each execution link asynchronous, reusing thread resources, and avoiding blocking to the greatest extent.

[0047] The registrar is responsible for receiving pending requests and registering binding information into the request record context. The request thread is then released and the request processor is called. The request processor executes the processing logic in a thread pool according to the input information and puts the results into the processing result queue. The daemon thread blocks the acquisition of the result queue content and transfers the content to the distributor for processing the result distribution logic. The distributor finds the list of requesters to be responded to according to the request registration information context and submits the result distribution logic through the thread pool. Before the result is distributed, the custom processor responsibility chain is called to filter and expand the returned results to achieve personalized processing, and then the callback method provided by the framework and container is called to distribute the results.

[0048] When the present invention is used to display a dynamic flight information list on a flight information page, the system administrator can configure the visible flight range of system users according to the user department rules to achieve flight visibility control. When the flight information changes, the interface will pop up a window to prompt the change event and trigger the page data refresh operation.

[0049] The flight information list displays all flight information without paging. For medium and large airports, there are many flights, a single request returns a lot of data, and the query takes a long time. After the flight change notification is pushed to the web end based on the message broadcast method, it will trigger a data refresh request, so a large number of concurrent requests will be generated at the same time.

[0050] For scenarios with frequent reading and writing, relying solely on cache cannot take into account both consistency and availability. Using request merging in conjunction with cache implementation can effectively reduce system pressure and improve system throughput.

[0051] Assuming that there are 200 users on the web using the flight information management interface, and the daily number of flights in and out of the airport is about 500, during the peak hours of flight takeoff and landing, the server will carry a large number of concurrent query requests with QPS=100. Due to the large amount of related information, the query cache or database overhead is large. Only through the service's own concurrent processing capabilities, it is usually necessary to consume multiple service nodes to run in a cluster to jointly support the corresponding traffic. This solution is a huge waste of service resources. Using the request merging processing method based on the rolling time window, multiple requests can be processed as a single request, which greatly saves computing resources, reasonably improves the system load capacity, and can meet the request merging processing when the interface query time is uncertain due to the adjustment of the flight volume. At the same time, the request merging post-processor responsibility chain can also meet the requirements of the flight visibility rule filtering function.

[0052] With the ability of actions and resource views to support one-to-many configuration, for scenarios where processing logic is reused, such as the query interfaces of the three interfaces of arrival, departure, and associated flights, the same intermediate results can be used to further improve the reuse rate of service resources.

[0053] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A request merging method based on a rolling time window, characterized in that: The following steps are involved: S1. The requester sends a resource acquisition request to the object server through the client, and the server proxy module receives the requester's request; S2, the server proxy module filters out the network requests to be merged and extracts the corresponding resource identifiers from the network requests; S3, the proxy module places the asynchronous results obtained by the requests with the same behavior in the same queue, registers the binding relationship between the asynchronous result queue and the logical processor, and then releases the working thread; In the step S3, the specific steps are: 3-1, the proxy module has built-in dependent processing methods, request parameters and return result view codes; 3-2, according to the view code and request parameters, refer to the configured binding relationship template, the binding relationship template is the relationship between the action and the view, the mapping adopts the HASHMAP data structure, supports one-to-many, that is, the result generated by one behavior is reused by multiple views, if not configured, it is bound by one-to-one relationship by default, and the action identifier is obtained; S4. After the proxy module registers the binding relationship, it uses the action identifier as a keyword to initialize or reuse the thread pool to execute the resource acquisition processing logic; S5. Control the number of core threads and queue length in the thread pool, run each resource acquisition processing logic in a rolling time window mode, and hand over the results to the result distribution thread pool for result distribution after the results are obtained; S6. After receiving the execution result, the result dispatching thread pool searches the response result queue according to the action identifier, and then determines the resource receiver range in the queue according to the time information in the result; S7. Before returning the result, call the custom result processor in a responsibility chain manner, use CopyOnWrite combined with a shallow copy method to filter and modify the result set to obtain personalized information; S8. The result dispatching thread sets the return content according to the obtained result and returns the result to the request initiator.

2. The method for request merging based on a rolling time window according to claim 1, characterized in that: In step S2, the proxy module is configured with the rule name and processing method for each resource, and adds the information of the initiation time, resource name and execution action on the basis of the original request.

3. The request merging method based on a rolling time window according to claim 1 or 2, characterized in that: In the step S4, the resource identifier and the asynchronous result queue, the resource identifier and the action identifier, and the action identifier and the action to be executed are configured, wherein the action identifier and the resource identifier are configured in a one-to-many relationship.

4. The request merging method based on a rolling time window according to claim 1 or 2, characterized in that: In step S5, the thread pool is set to have a core thread number of 1, a queue length of 2, and a rejection strategy of discarding the most recent request; in this way, the asynchronous processing logic is implemented in the form of a rolling window.

Images