Request processing method, device, electronic device and storage medium
By setting the waiting response time and the remaining response monitoring time for requests of different queue priorities, the problem of high-priority requests being blocked by low-priority requests in the Shuffle Service is solved, and hierarchical services for requests of different priorities are implemented, optimizing resource utilization.
Patent Information
- Application Number
- CN202111219048.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-10-20
- Publication Date
- 2025-09-19
- Estimated Expiration
- 2041-10-20
AI Technical Summary
In a public cluster environment, the Shuffle Service cannot perceive the priorities of different applications, causing high-priority Shuffle read requests to be blocked by low-priority requests, resulting in a waste of node resources.
By setting the waiting response time for requests of different queue priorities, monitoring the remaining response time, determining the requests to be responded to, and caching them in the request response queue for processing, hierarchical services for requests of different priorities can be achieved.
Under the premise of making full use of cluster resources, high-priority requests are processed first, while low-priority requests are avoided from being neglected, thus avoiding the waste of node resources caused by physical isolation of resources.
Smart Images

Figure CN113918301B_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of data processing technology, and in particular to a request processing method, device, electronic device, and storage medium. Background Art
[0002] On a public cluster consisting of thousands to tens of thousands of nodes, thousands of big data analytics applications are running simultaneously. Specifically, the Shuffle Service on each node may receive shuffle read requests from dozens of applications simultaneously. Furthermore, the nodes are often deployed with distributed file systems storing petabytes (Peta Bytes) of data. This results in the disk I / O (Input / Output) resources shared by multiple applications on each node being strained or even scarce in public cluster environments.
[0003] The current Shuffle Service provides shuffle data based on a simple First Come First Serve (FCFS) mechanism. However, different shuffle read requests come from different applications, and the applications themselves have different priorities and service levels. The Shuffle Service is unaware of priority, and as a result, late-arriving high-priority shuffle read requests may be blocked by a large number of early-arriving low-priority shuffle read requests. Summary of the Invention
[0004] The present disclosure provides a request processing method, apparatus, electronic device, and storage medium to at least address the problem of node resource waste caused by physical isolation of resources when processing requests of different priorities in related technologies. The technical solutions of the present disclosure are as follows:
[0005] According to a first aspect of an embodiment of the present disclosure, a request processing method is provided, including:
[0006] Determine a plurality of request waiting queues having different queue priorities; wherein the queue priority of each request waiting queue matches the priority of the requests in the request waiting queue, and a waiting response time of a high priority request is less than a waiting response time of a low priority request;
[0007] Monitor the remaining response time of each request; the remaining response time is the difference between the waiting response time of the request and the time the request enters the request waiting queue;
[0008] Determining pending requests based on the remaining response time of each request;
[0009] Cache the pending response request in a request response queue;
[0010] The requests in the request response queue are processed.
[0011] In an exemplary embodiment, the method further comprises:
[0012] receiving a pending request and determining a priority of the pending request;
[0013] Determining a first request waiting queue corresponding to the pending request; wherein the queue priority of the first request waiting queue matches the priority of the pending request;
[0014] The pending request is cached in the first request waiting queue.
[0015] In an exemplary embodiment, each request carries a request source identifier and a requested target file identifier;
[0016] The determining of the pending response requests based on the remaining response time of each request includes:
[0017] Determine the request with the remaining response time of zero as the target request, and the second request waiting queue where the target request is located;
[0018] Searching the second request waiting queue for at least one associated request that entered the second request waiting queue after the target request; wherein the associated request and the target request carry the same request source identifier and requested target file identifier;
[0019] The target request and the at least one associated request are determined as the requests to be responded to.
[0020] In an exemplary embodiment, each request also carries a target file offset;
[0021] The step of searching the second request waiting queue for at least one associated request whose time of entering the second request waiting queue is later than the target request comprises:
[0022] Searching the second request waiting queue for a preset number of candidate requests that entered the second request waiting queue after the target request; wherein each candidate request has the same request source identifier and requested target file identifier as the target request;
[0023] Sort the preset number of candidate requests based on the target file offset carried by each candidate request;
[0024] The at least one associated request is determined from the preset number of candidate requests based on the sorting result.
[0025] In an exemplary embodiment, the method further comprises:
[0026] Determining the preset number of candidate requests corresponding to the second request waiting queue based on the queue priority of the second request waiting queue and a preset correspondence between the queue priority and the number of requests to be responded to;
[0027] Among them, in the correspondence relationship between the preset queue priority and the number of requests to be responded to, the number of requests to be responded to corresponding to the high queue priority is greater than the number of requests to be responded to corresponding to the low queue priority.
[0028] In an exemplary embodiment, the method further comprises:
[0029] When caching the pending request in the first request waiting queue, setting a timer for the pending request, the duration of the timer being the waiting response duration of the pending request;
[0030] Determining the request with the remaining response time being zero as the target request includes:
[0031] A request for resetting the timer to zero is determined as the target request.
[0032] In an exemplary embodiment, the method further comprises:
[0033] When the request response queue is empty, determining a plurality of non-empty queues among the plurality of request waiting queues;
[0034] The pending requests are selected from the multiple non-empty queues in descending order of queue priorities of the multiple non-empty queues.
[0035] In an exemplary embodiment, the method further comprises:
[0036] When the number of requests in the request response queue is less than the no-load threshold, increasing the number of the pending requests cached in the request response queue each time, and reducing the waiting response time of each request in the multiple request waiting queues;
[0037] When the number of requests in the request response queue is greater than or equal to the no-load threshold and less than or equal to the full-load threshold, the number of pending requests cached in the request response queue each time and the waiting response time of each request in the multiple request waiting queues remain unchanged;
[0038] When the number of requests in the request response queue is greater than the full load threshold, the number of the pending requests cached in the request response queue each time is reduced, and the waiting response time of each request in the multiple request waiting queues is increased.
[0039] According to a second aspect of an embodiment of the present disclosure, there is provided a request processing device, including:
[0040] a request waiting queue determining unit configured to determine a plurality of request waiting queues having different queue priorities; wherein the queue priority of each request waiting queue matches the priority of requests in the request waiting queue, and a waiting response time of a high-priority request is less than a waiting response time of a low-priority request;
[0041] The monitoring unit is configured to monitor the remaining response time of each request; the remaining response time is the difference between the waiting response time of the request and the time the request enters the request waiting queue;
[0042] a pending response request determining unit, configured to determine pending response requests based on the remaining response time of each request;
[0043] a pending response request caching unit, configured to cache the pending response request into a request response queue;
[0044] The request processing unit is configured to process the requests in the request response queue.
[0045] In an exemplary embodiment, the apparatus comprises:
[0046] a pending request receiving unit, configured to receive pending requests and determine the priority of the pending requests;
[0047] A first determining unit is configured to determine a first request waiting queue corresponding to the pending request; the queue priority of the first request waiting queue matches the priority of the pending request;
[0048] The pending request caching unit is configured to cache the pending request into the first request waiting queue.
[0049] In an exemplary embodiment, each request carries a request source identifier and a requested target file identifier;
[0050] The pending response request determining unit includes:
[0051] A second determining unit is configured to determine that the request with a remaining response time of zero is a target request and a second request waiting queue where the target request is located;
[0052] an association request determining unit configured to search the second request waiting queue for at least one association request that entered the second request waiting queue after the target request; wherein the association request and the target request carry the same request source identifier and requested target file identifier;
[0053] The pending response request determining unit is configured to determine the target request and the at least one associated request as the pending response requests.
[0054] In an exemplary embodiment, each request also carries a target file offset;
[0055] The association request determining unit includes:
[0056] a candidate request determining unit configured to execute, in the second request waiting queue, searching for a preset number of candidate requests that entered the second request waiting queue after the target request; wherein each candidate request has the same request source identifier and requested target file identifier as the target request;
[0057] a candidate request sorting unit, configured to sort the preset number of candidate requests based on a target file offset carried by each candidate request;
[0058] The third determining unit is configured to determine the at least one associated request from the preset number of candidate requests based on the sorting result.
[0059] In an exemplary embodiment, the apparatus further comprises:
[0060] a candidate request number determining unit configured to determine the preset number of candidate requests corresponding to the second request waiting queue based on the queue priority of the second request waiting queue and a preset correspondence between the queue priority and the number of requests to be responded to;
[0061] Among them, in the correspondence relationship between the preset queue priority and the number of requests to be responded to, the number of requests to be responded to corresponding to the high queue priority is greater than the number of requests to be responded to corresponding to the low queue priority.
[0062] In an exemplary embodiment, the apparatus further comprises:
[0063] a timer setting unit configured to set a timer for the pending request when caching the pending request in the first request waiting queue, wherein the duration of the timer is the waiting response duration of the pending request;
[0064] The second determining unit includes:
[0065] The fourth determining unit is configured to determine a request to reset the timer to zero as the target request.
[0066] In an exemplary embodiment, the apparatus further comprises:
[0067] a non-empty queue determining unit, configured to determine a plurality of non-empty queues in the plurality of request waiting queues when the request response queue is empty;
[0068] The pending request selection unit is configured to select the pending request from the multiple non-empty queues in descending order of queue priorities of the multiple non-empty queues.
[0069] In an exemplary embodiment, the apparatus further comprises:
[0070] A first adjusting unit is configured to increase the number of pending requests cached in the request response queue each time and reduce a waiting response time for each request in the plurality of request waiting queues when the number of requests in the request response queue is less than an idle threshold;
[0071] a maintaining unit configured to maintain the number of pending requests cached in the request response queue each time and the waiting response time of each request in the multiple request waiting queues unchanged when the number of requests in the request response queue is greater than or equal to the no-load threshold and less than or equal to the full-load threshold;
[0072] The second adjustment unit is configured to reduce the number of pending requests cached in the request response queue each time and increase the waiting response time for each request in the multiple request waiting queues when the number of requests in the request response queue is greater than the full load threshold.
[0073] According to a third aspect of an embodiment of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the request processing method as described above.
[0074] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided. When instructions in the computer-readable storage medium are executed by a processor of a server, the server is enabled to execute the request processing method as described above.
[0075] According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, which includes a computer program stored in a readable storage medium, and at least one processor of a computer device reads and executes the computer program from the readable storage medium, so that the device executes the above-mentioned request processing method.
[0076] The technical solutions provided by the embodiments of the present disclosure bring at least the following beneficial effects:
[0077] The present disclosure monitors each request in a plurality of request waiting queues with different queue priorities, specifically monitors the time length for each request to enter the corresponding request waiting queue, and determines a request to be responded to when there is a request that has entered the corresponding request waiting queue for a time length that reaches the corresponding waiting time length; caches the request to be responded to in the request response queue, and processes the requests in the request response queue. The present disclosure caches requests of different priorities into corresponding request waiting queues, and sets the waiting time length for response of high-priority requests to be shorter than the waiting time length for response of low-priority requests, thereby scheduling the execution of requests in each request waiting queue in different cycles, thereby achieving hierarchical service for requests of different priorities. Under the premise of fully utilizing cluster resources, it can provide a guarantee for the completion time of requests of different priorities, that is, it can process high-priority requests first, while not neglecting low-priority requests, thereby avoiding the problem of node resource waste caused by processing requests of different priorities through physical isolation of resources.
[0078] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0079] The accompanying drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute an improper limitation of the present disclosure.
[0080] Figure 1 It is a schematic diagram of an implementation environment according to an exemplary embodiment.
[0081] Figure 2 The figure is a flow chart of a request processing method according to an exemplary embodiment.
[0082] Figure 3 The figure is a flow chart of a method for caching pending requests according to an exemplary embodiment.
[0083] Figure 4 The figure is a flow chart of a method for determining requests to be responded to according to an exemplary embodiment.
[0084] Figure 5 The figure is a flow chart of a method for determining an association request according to an exemplary embodiment.
[0085] Figure 6 The figure is a schematic diagram of file storage according to an exemplary embodiment.
[0086] Figure 7The figure is a flow chart of another method for determining requests to be responded to according to an exemplary embodiment.
[0087] Figure 8 The figure is a schematic diagram showing dequeuing and enqueuing requests according to an exemplary embodiment.
[0088] Figure 9 The figure is a flow chart of a parameter adjustment method according to an exemplary embodiment.
[0089] Figure 10 The figure is a block diagram of a request processing device according to an exemplary embodiment.
[0090] Figure 11 The figure is a schematic diagram showing a device structure according to an exemplary embodiment. DETAILED DESCRIPTION
[0091] In order to enable ordinary persons in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.
[0092] It should be noted that the terms "first," "second," and the like in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the numbers used in this manner are interchangeable where appropriate so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure as detailed in the appended claims.
[0093] See also Figure 1 , which shows a schematic diagram of the implementation environment provided by an embodiment of the present disclosure. The present disclosure can be applied to a distributed cluster, which may include a management node 110 and multiple data processing nodes 120; wherein the management node 110 and multiple data processing nodes 120 can communicate data through a network.
[0094] Specifically, management node 110 can receive data requests from multiple applications and distribute them to corresponding data processing nodes 120. Upon receiving a data request, data processing node 120 processes the request based on its priority and sends the processing result to management node 110. Management node 110 then returns the processing result to the corresponding application. In one example, an application refers to an application program installed on a device.
[0095] The management node 110 and the data processing node 120 may specifically be servers, which may be physical servers or cloud servers.
[0096] In order to solve the problem of node resource waste caused by physical isolation of resources when processing requests of different priorities in the related art, the present disclosure provides a request processing method, see Figure 2 , the execution subject of this method can be Figure 1 For the data processing nodes in the data processing node, the request processing method at each data processing node may include at least S210-S250.
[0097] S210. Determine multiple request waiting queues with different queue priorities; wherein the queue priority of each request waiting queue matches the priority of the requests in the request waiting queue, and the waiting response time of high priority requests is shorter than the waiting response time of low priority requests.
[0098] In an embodiment of the present disclosure, multiple request waiting queues with different queue priorities are set up at each data processing node to store requests of different priorities; the queue priority of the request waiting queue matches the priority of the requests in the request waiting queue, which may mean that the queue priority of the request waiting queue and the priority of the requests therein satisfy a preset relationship, specifically, the preset relationship may mean that the queue priority is the same as the request priority, and requests of the same priority can be cached in the same request waiting queue, that is, the priority of each request in the same request waiting queue is the same; wherein the queue priority in each request waiting queue is consistent with the priority of the requests in the request waiting queue.
[0099] Specifically, since the priorities of requests from different applications may be different, and the priorities of requests from the same application may also be different, relevant priority information is carried in a specific request. Thus, when a data processing node receives a request, it can determine the priority according to the priority information carried in the request. Here, if the priorities of the requests include priority P0, P1, and P2, and priority P0 > priority P1 > priority P2, correspondingly, there are request waiting queues with queue priority P0, request waiting queues with queue priority P1, and request waiting queues with queue priority P2. Therefore, the requests cached in the request waiting queue with queue priority P0 are requests with priority P0, the requests cached in the request waiting queue with queue priority P1 are requests with priority P1, and the requests cached in the request waiting queue with queue priority P2 are requests with priority P2. In an optional embodiment, when there is no request waiting queue with the same queue priority as the request, the associated request waiting queue corresponding to the request can be determined. The associated request waiting queue can be a request waiting queue with a queue priority greater than the priority of the request and closest to the priority of the request. For example, if the priority of the request is P0 and there is no request waiting queue with queue priority P0, the associated request waiting queue for this request can be determined as the request waiting queue with queue priority P1. Thus, it is possible to cache requests without a corresponding request waiting queue into the associated request waiting queue. In another optional embodiment, when there is no request waiting queue with the same queue priority as the request, a request waiting queue with the same queue priority as the request can also be created immediately, which realizes the on-demand dynamic creation of request waiting queues and avoids the resource waste caused by the premature creation of request waiting queues.
[0100] In one embodiment, a corresponding waiting response duration can also be set for each request. The waiting response durations corresponding to requests with the same priority are the same. For example, the waiting response duration corresponding to a request with priority P0 is T0, the waiting response duration corresponding to a request with priority P1 is T1, and the waiting response duration corresponding to a request with priority P2 is T2, where T0 < T1 < T2. By setting a shorter waiting response duration for requests with a higher priority, the processing frequency of requests with a higher priority can be increased, thus realizing the preferential processing of requests with a higher priority.
[0101] For each request waiting queue, since there are requests enqueuing and dequeuing, enqueuing means receiving a new pending request and caching the new pending request into the corresponding request waiting queue, where the queue priority of the corresponding request waiting queue matches the priority of the pending request; dequeuing means taking out a request from the request waiting queue for processing. Therefore, each request waiting queue is constantly updated. Thus, every time a request needs to be dequeued from the queue, it is necessary to re-determine the current request waiting queue.
[0102] For methods of enqueuing requests, see Figure 3 , which shows a method for caching pending requests, which may include S310-S330.
[0103] S310. Receive pending requests and determine the priority of the pending requests.
[0104] S320. Determine a first request waiting queue corresponding to the pending request; the queue priority of the first request waiting queue matches the priority of the pending request.
[0105] S330. Cache the pending request in the first request waiting queue.
[0106] When a data processing node receives a pending request, it determines its priority based on the priority information carried by the pending request. Here, the priority information carried by the pending request can be assigned by the corresponding application. Specifically, by setting the priorities of different applications, a request issued based on a certain application will have the priority corresponding to the application. For example, if the priority of application A is P0, the priority of the corresponding request issued based on application A is also P0. Furthermore, different priorities can be set for different types of requests issued by the same application. For example, if the priority of application A is P0, the priority of the first type of request is P0, and the priority of the second type of request is P1. The above examples are only for illustrating the specific implementation methods of the present disclosure and do not constitute a limitation on the implementation methods of the present disclosure.
[0107] After the priority of the pending request is determined, the pending request is cached in a request waiting queue of a corresponding queue priority to update the corresponding request waiting queue.
[0108] When processing requests with delayed response characteristics, for example, in scenarios where the real-time processing requirements for requests are not high or in batch processing scenarios, the request processing method disclosed in the present invention can be used to cache pending requests in the corresponding queue, and read pending requests for processing within the delay time range that the pending requests can receive; for example, in offline processing scenarios, the real-time processing requirements for requests are not high at this time, so there can be a delay in the processing of requests; in batch processing scenarios, when the number of pending requests received accumulates to a certain number, the batch of requests is processed centrally. The above application of the request processing method disclosed in the present invention to scenarios where the real-time processing requirements for requests are not high or in batch processing scenarios is only for the purpose of illustrating the specific implementation methods of the present invention, and does not constitute a limitation on the implementation methods of the present invention. In any scenario where the request processing method in the present invention can be applied, the method in this embodiment can be used to process requests.
[0109] By caching pending requests into the corresponding request waiting queue, on the one hand, it is convenient to manage and query the pending requests in a hierarchical manner, and to facilitate the subsequent processing of requests in the same request waiting queue; on the other hand, it provides cache space for requests with delayed response characteristics.
[0110] S220. Monitor the remaining response time of each request; the remaining response time is the difference between the waiting response time of the request and the time the request enters the request waiting queue.
[0111] By monitoring the remaining response time of each request, it is determined whether a response to the request is required; specifically, when the pending request is cached in the first request waiting queue, a timer is set for the pending request, and the timer duration is the waiting response time of the pending request; that is, a corresponding timer is set for each request, and when the request enters the corresponding request waiting queue, the timer is started to count down. For example, for a request with a priority of P0, the corresponding timer duration is T0; for a request with a priority of P1, the corresponding timer duration is T1; for a request with a priority of P2, the corresponding timer duration is T2. Specifically, the P0 timer duration is 1 second, the P1 timer duration is 5 seconds, and the P2 timer duration is 15 seconds. Here, monitoring the remaining response time of each request can specifically be monitoring the timer. By setting a timer to represent the remaining response time of the request, it is convenient to monitor the remaining response time of the request, improve the convenience of time monitoring, and is easy to implement. By allowing different maximum delay request response times, a better read disk access mode can be achieved.
[0112] S230. Determine the requests to be responded to based on the remaining response time of each request.
[0113] In the embodiment of the present disclosure, each request may also carry a request source identifier and a requested target file identifier; the request source identifier may specifically be an application identifier that issues the request, and the requested target file identifier may refer to an identifier of a target file to be accessed by the current request; thus, please refer to Figure 4 , which shows a method for determining requests to be responded to, which may include:
[0114] S410: Determine the request with the remaining response time of zero as the target request, and the second request waiting queue where the target request is located.
[0115] S420. Search the second request waiting queue for at least one associated request that entered the second request waiting queue after the target request; wherein the associated request has the same request source identifier and requested target file identifier as the target request.
[0116] S430. Determine the target request and the at least one associated request as the requests to be responded to.
[0117] Specifically, according to the above content, if the timer corresponding to each request is started when it enters the request waiting queue, when there is a request whose timer has returned to zero, the request whose timer has returned to zero is determined as the target request. In one case, the target request is regarded as the request to be responded to.
[0118] In another case, such as a scenario where requests are batch processed, multiple requests to be responded to may be determined. Specifically, an associated request associated with the target request may be searched in the second request waiting queue where the target request is located. The associated request and the target request carry the same request source identifier and the same target file identifier, i.e., the target request and the associated request come from the same application and need to access the same target file, which is generally stored on a disk. Since the target request and the associated request may be discontinuous in the queue, i.e., there are other requests between the target request and the associated request in the second request waiting queue, if each request is processed sequentially according to the cache order in the second request waiting queue, different requests require access to different target files, resulting in random access to the disk. In the embodiment of the present disclosure, the target request and the associated request are processed uniformly as a batch of requests. On the one hand, the request source identifiers of the batch of requests are the same, so that requests can be processed for the same request source and the processing results can be returned as quickly as possible. On the other hand, the target files to be accessed by the batch of requests are the same, so that small-granularity random access to the disk can be converted to large-granularity access to the disk, thereby optimizing the disk access pattern and reducing the impact of full random access on disk performance.
[0119] For example, for target request 1, its request source is identified as application A, and the target file identifier of the request is the same file f1; the source identifier of target request 2 adjacent to target request 1 in the second request waiting queue is application B, and the target file identifier of the request is the same file f2, that is, target request 2 is a non-associated request of target request 1, and the target files to be accessed by target request 1 and target request 2 are different. If target request 1 and target request 2 are responded to in sequence, it is necessary to first access the area where file f1 is located on the disk, and then access the area where file f2 is located on the disk, resulting in random access to the disk; in the present disclosure, the associated requests after target request 1 are found, the target requests and associated requests are batch-processed, and the file f1 is accessed centrally, thereby avoiding repeated adjustment of the disk access area during the file access process.
[0120] Furthermore, each request also carries the target file offset; see Figure 5 , which shows a method for determining an association request, which may include:
[0121] S510. In the second request waiting queue, search for a preset number of candidate requests that entered the second request waiting queue after the target request; wherein each candidate request has the same request source identifier and requested target file identifier as the target request.
[0122] S520. Sort the preset number of candidate requests based on the target file offset carried by each candidate request.
[0123] S530. Determine the at least one associated request from the preset number of candidate requests based on the sorting result.
[0124] The target file offset here is used to represent the offset information relative to the file header of the target file. In the embodiment of the present disclosure, the number of associated requests can be set to be less than or equal to the number of candidate requests, and when determining the candidate requests, the number of target requests and candidate requests is less than the total number of requests in the second request waiting queue where the target request is located; the top R candidate requests are selected from the sorting results as associated requests.
[0125] Sorting candidate requests based on the file offset relative to the file header can make the file area to be accessed by the selected associated requests more concentrated, further converting random access to the disk into continuous access, avoiding repeated adjustment of the access position during the disk access process, and further improving the disk access performance and disk access efficiency.
[0126] See also Figure 6 , which shows a file storage diagram. If the storage area for target file f1 includes area 0-area n-1, the offset from area 0 to area n-1 relative to the file header gradually increases; if there are 6 candidate requests, requesting access to area n-1, area 1, area n-2, area 2, area 8, and area 3 of file f1, respectively, n>10, and sorting based on offset, the offset information corresponding to the sorted requests is area 1, area 2, area 3, area 8, area n-2, and area n-1. If the number of associated requests is 3, the requests corresponding to area 1, area 2, and area 3 can be determined to be associated requests. Here, a request corresponding to a region refers to a request that carries the region identifier of the region.
[0127] In certain embodiments, the present disclosure determines the preset number of candidate requests corresponding to the second request waiting queue based on the queue priority of the second request waiting queue and a preset correspondence between the queue priority and the number of requests to be responded to;
[0128] Among them, in the correspondence relationship between the preset queue priority and the number of requests to be responded to, the number of requests to be responded to corresponding to the high queue priority is greater than the number of requests to be responded to corresponding to the low queue priority.
[0129] For example, for queue priority P0, the corresponding number of pending requests is R0; for queue priority P1, the corresponding number of pending requests is R1; and for queue priority P2, the corresponding number of pending requests is R2; and R0>R1>R2. Queues of different priorities have different maximum numbers of requests dequeued at a time. For example, the P0 queue can dequeue a maximum of 50 requests at a time, the P1 queue can dequeue a maximum of 30 requests at a time, and the P2 queue can dequeue a maximum of 15 requests at a time. The number of pending requests dequeued from a higher-priority queue is greater than the number of pending requests dequeued from a lower-priority queue, further ensuring that higher-priority requests are processed first.
[0130] S240. Cache the pending response request into a request response queue.
[0131] For a request in the request waiting queue, when it enters the request response queue, the timer corresponding to the request is canceled accordingly.
[0132] S250. Process the requests in the request response queue.
[0133] The data processing node processes the requests in the request response queue in sequence, and may also perform corresponding batch processing on the requests determined above, and return corresponding processing results.
[0134] Also, see Figure 7 , which shows another method for determining requests to be responded to, which may include:
[0135] S710. When the request response queue is empty, determine multiple non-empty queues among the multiple request waiting queues.
[0136] S720. Select the pending request from the multiple non-empty queues in descending order of queue priorities of the multiple non-empty queues.
[0137] Because the requests in the request response queue are determined from the request waiting queue, when there is a request with a remaining response time of zero, specifically a request whose timer has returned to zero, the request will be taken out from the corresponding request waiting queue and placed in the request response queue; the corresponding situation when the request response queue is empty is that there is no request with a remaining response time of zero at this time, that is, the timer time of all requests in the request waiting queue has not been exhausted, or the request waiting queue may be empty.
[0138] When a non-empty queue exists, pending requests are removed and placed into the request response queue in descending order of priority based on the non-empty queue. The specific method for determining pending requests can be found in the above-mentioned method of the embodiment of this disclosure and will not be described in detail here. When the request response queue is empty, pending requests are determined based on the queue priority of the non-empty queue, thereby ensuring that high-priority requests receive timely responses.
[0139] For the process of taking out pending requests from the request waiting queue and caching them in the request response queue, see Figure 8 , which includes three request waiting queues with priorities P0, P1, and P2 respectively. When there is a request whose timer has expired, the request whose timer has expired is cached in the request response queue. Specifically, in the order of queue priority from high to low, the request whose timer has expired in each request waiting queue is read out from the request waiting queue where it is located and put into the request response queue.
[0140] See also Figure 9 , which shows a parameter adjustment method, which may include:
[0141] S910. Determine whether the number of requests in the request response queue is less than the idle threshold; if so, execute step S920; if not, execute step S930.
[0142] S920. Increase the number of the pending requests cached in the request response queue each time, and reduce the waiting response time of each request in the multiple request waiting queues.
[0143] S930. Determine whether the number of requests in the request response queue is greater than the full load threshold; if so, execute step S940; if not, execute step S950.
[0144] S940. Reduce the number of the pending requests cached in the request response queue each time, and increase the waiting response time of each request in the multiple request waiting queues.
[0145] S950. Maintain the number of the pending requests cached in the request response queue each time and the waiting response time of each request in the multiple request waiting queues unchanged.
[0146] Among them, the no-load threshold and the full-load threshold can be pre-set values used to characterize the properties of the request response queue. When the number of requests in the request response queue is less than the no-load threshold, it can be determined that the request response queue is in an idle state and more requests can be cached; when the number of requests in the request response queue is greater than the full-load threshold, it can be determined that the request response queue is in an overload state or an overload state, and the number of requests in the request response queue needs to be reduced.
[0147] Adaptively adjusting relevant parameters based on the current load can improve the efficiency of the cluster.
[0148] The parameters that need to be adjusted include: for each priority level request, the maximum response time T (the waiting time for each request in the request waiting queue), the number of requests taken out of the priority queue each time R (the number of pending requests cached in the request response queue each time), and the request response queue length L (the number of requests in the request response queue) that reflects the current service response status of the system. The adaptive adjustment method is as follows:
[0149] 1. When L is less than the no-load threshold len1, the number of R is periodically increased: Rnew = Rold*c1; and the T time is simultaneously decreased: Tnew = Told*c2; where Rold is the number of requests taken out of the priority queue each time before the adjustment, and Rnew is the number of requests taken out of the priority queue each time after the adjustment; Told is the longest response time of the request before the adjustment, and Tnew is the longest response time of the request after the adjustment; c1 is the increase ratio, and c2 is the decrease ratio (c1>1, c2<1).
[0150] 2. When L is greater than the no-load threshold len1 and less than the full-load threshold len2, the T and R values remain unchanged;
[0151] 3. When L is greater than the full load threshold len2, the number of R is periodically reduced: Rnew = Rold*c2; and the T time is increased at the same time: Tnew = Told*c1.
[0152] In the above algorithm, len1 and len2, the adjustment ratios c1 and c2 (c1>1, c2<1), and the adjustment period are all empirical values that can be estimated using the compute node disk. The system is insensitive to these empirical values, meaning that the system can always achieve a balance between response time and parameters through the above adaptive adjustment method.
[0153] The present disclosure monitors each request in a plurality of request waiting queues with different queue priorities, specifically monitors the time length for each request to enter the corresponding request waiting queue, and determines a request to be responded to when there is a request that has entered the corresponding request waiting queue for a time length that reaches the corresponding waiting time length; caches the request to be responded to in the request response queue, and processes the requests in the request response queue. The present disclosure caches requests of different priorities into corresponding request waiting queues, and sets the waiting time length for response of high-priority requests to be shorter than the waiting time length for response of low-priority requests, thereby scheduling the execution of requests in each request waiting queue in different cycles, thereby achieving hierarchical service for requests of different priorities. Under the premise of fully utilizing cluster resources, it can provide a guarantee for the completion time of requests of different priorities, that is, it can process high-priority requests first, while not neglecting low-priority requests, thereby avoiding the problem of node resource waste caused by processing requests of different priorities through physical isolation of resources.
[0154] The present disclosure can be applied to Shuffle service scenarios, wherein Shuffle read request priorities are distinguished by job priority through hierarchical caching of Shuffle read requests and different granularity services at various levels. Specifically, by caching requests of different priorities into corresponding request waiting queues, and setting the waiting response time of high-priority requests to be shorter than the waiting response time of low-priority requests, requests in each request waiting queue are scheduled and executed in different cycles, thereby achieving hierarchical services for requests of different priorities. Under the premise of making full use of cluster resources, it is possible to provide guarantees for the completion time of requests of different priorities, that is, it is possible to process high-priority requests first, while not neglecting low-priority requests, thereby avoiding a large number of low-priority Shuffle read requests blocking high-priority Shuffle read requests, and avoiding the problem of node resource waste caused by processing requests of different priorities through physical isolation of resources. In addition, the target request and the associated requests are processed as a batch of requests. On the one hand, the request source identifiers of the batch of requests are the same, so that the requests can be processed for the same request source and the processing results can be returned as quickly as possible. On the other hand, the target files to be accessed by the batch of requests are the same, so that small-grained random access to the disk can be converted to large-grained access to the disk, thereby optimizing the disk access pattern and reducing the impact of full random access on disk performance. Through the timer-based request batch dequeue method, the monitoring of the remaining response time of each request can be specifically monitoring the timer. By setting the timer to represent the remaining response time of the request, it is convenient to monitor the remaining response time of the request, ensuring that the maximum waiting time of each request is controllable, while optimizing the disk I / O access pattern as much as possible and reducing the impact of full random disk I / O on disk performance. The adaptive parameter adjustment method based on disk load adaptively tunes parameters based on the current load, improving the cluster Shuffle service capabilities while reducing the tuning requirements of the system administrator.
[0155] Figure 10 FIG. 1 is a block diagram of a request processing device according to an exemplary embodiment. Figure 10 , the device comprises:
[0156] The request waiting queue determining unit 1010 is configured to determine a plurality of request waiting queues having different queue priorities; wherein the queue priority of each request waiting queue matches the priority of the requests in the request waiting queue, and the waiting response time of the high priority request is shorter than the waiting response time of the low priority request;
[0157] The monitoring unit 1020 is configured to monitor the remaining response time of each request; the remaining response time is the difference between the waiting response time of the request and the time the request enters the request waiting queue;
[0158] The pending response request determining unit 1030 is configured to determine the pending response request based on the remaining response time of each request;
[0159] The pending response request caching unit 1040 is configured to cache the pending response request into a request response queue;
[0160] The request processing unit 1050 is configured to process the requests in the request response queue.
[0161] In an exemplary embodiment, the apparatus comprises:
[0162] a pending request receiving unit, configured to receive pending requests and determine the priority of the pending requests;
[0163] A first determining unit is configured to determine a first request waiting queue corresponding to the pending request; the queue priority of the first request waiting queue matches the priority of the pending request;
[0164] The pending request caching unit is configured to cache the pending request into the first request waiting queue.
[0165] In an exemplary embodiment, each request carries a request source identifier and a requested target file identifier;
[0166] The pending response request determining unit 1030 includes:
[0167] A second determining unit is configured to determine that the request with a remaining response time of zero is a target request and a second request waiting queue where the target request is located;
[0168] an association request determining unit configured to search the second request waiting queue for at least one association request that entered the second request waiting queue after the target request; wherein the association request and the target request carry the same request source identifier and requested target file identifier;
[0169] The pending response request determining unit is configured to determine the target request and the at least one associated request as the pending response requests.
[0170] In an exemplary embodiment, each request also carries a target file offset;
[0171] The association request determining unit includes:
[0172] a candidate request determining unit configured to execute, in the second request waiting queue, searching for a preset number of candidate requests that entered the second request waiting queue after the target request; wherein each candidate request has the same request source identifier and requested target file identifier as the target request;
[0173] a candidate request sorting unit, configured to sort the preset number of candidate requests based on a target file offset carried by each candidate request;
[0174] The third determining unit is configured to determine the at least one associated request from the preset number of candidate requests based on the sorting result.
[0175] In an exemplary embodiment, the apparatus further comprises:
[0176] a candidate request number determining unit configured to determine the preset number of candidate requests corresponding to the second request waiting queue based on the queue priority of the second request waiting queue and a preset correspondence between the queue priority and the number of requests to be responded to;
[0177] Among them, in the correspondence relationship between the preset queue priority and the number of requests to be responded to, the number of requests to be responded to corresponding to the high queue priority is greater than the number of requests to be responded to corresponding to the low queue priority.
[0178] In an exemplary embodiment, the apparatus further comprises:
[0179] a timer setting unit configured to set a timer for the pending request when caching the pending request in the first request waiting queue, wherein the duration of the timer is the waiting response duration of the pending request;
[0180] The second determining unit includes:
[0181] The fourth determining unit is configured to determine a request to reset the timer to zero as the target request.
[0182] In an exemplary embodiment, the apparatus further comprises:
[0183] a non-empty queue determining unit, configured to determine a plurality of non-empty queues in the plurality of request waiting queues when the request response queue is empty;
[0184] The pending request selection unit is configured to select the pending request from the multiple non-empty queues in descending order of queue priorities of the multiple non-empty queues.
[0185] In an exemplary embodiment, the apparatus further comprises:
[0186] A first adjusting unit is configured to increase the number of pending requests cached in the request response queue each time and reduce a waiting response time for each request in the plurality of request waiting queues when the number of requests in the request response queue is less than an idle threshold;
[0187] a maintaining unit configured to maintain the number of pending requests cached in the request response queue each time and the waiting response time of each request in the multiple request waiting queues unchanged when the number of requests in the request response queue is greater than or equal to the no-load threshold and less than or equal to the full-load threshold;
[0188] The second adjustment unit is configured to reduce the number of pending requests cached in the request response queue each time and increase the waiting response time for each request in the multiple request waiting queues when the number of requests in the request response queue is greater than the full load threshold.
[0189] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.
[0190] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided. Optionally, the computer-readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a tape, a floppy disk, an optical data storage device, etc.; when the instructions in the computer-readable storage medium are executed by the processor of the server, the server is enabled to execute any of the methods described above.
[0191] In an exemplary embodiment, a computer program product is also provided, which includes a computer program stored in a readable storage medium, and at least one processor of a computer device reads and executes the computer program from the readable storage medium, so that the device performs any of the above methods.
[0192] This embodiment also provides a device, the structure of which can be seen in Figure 11The device 1100 may vary greatly due to different configurations or performance, and may include one or more central processing units (CPUs) 1122 (e.g., one or more processors) and memory 1132, one or more storage media 1130 (e.g., one or more mass storage devices) storing application programs 1142 or data 1144. The memory 1132 and the storage media 1130 may be temporary storage or permanent storage. The program stored in the storage media 1130 may include one or more modules (not shown in the figure), each module may include a series of instruction operations on the device. Furthermore, the central processing unit 1122 may be configured to communicate with the storage media 1130 and execute a series of instruction operations in the storage media 1130 on the device 1100. The device 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input and output interfaces 1158, and / or one or more operating systems 1141, such as Windows Server TM , Mac OS X TM , Unix TM , Linux TM , FreeBSD TM Etc. Any of the above methods in this embodiment can be based on Figure 11 The device shown is implemented.
[0193] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the following claims.
[0194] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes can be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.
Claims
1. A request processing method, characterized in that: include: Determine multiple request waiting queues with different queue priorities; The queue priority of each request waiting queue matches the priority of the requests in the request waiting queue, and the waiting response time of a high-priority request is shorter than the waiting response time of a low-priority request; each request carries a request source identifier and a requested target file identifier; Monitor the remaining response time of each request; The remaining response time is the difference between the waiting response time of the request and the time the request enters the request waiting queue; Determine the request with the remaining response time being zero as a target request, and the second request waiting queue where the target request is located; Searching the second request waiting queue for at least one associated request that entered the second request waiting queue after the target request; wherein the request source identifier carried by the associated request is the same as the request source identifier carried by the target request, and the target file identifier requested by the associated request is the same as the target file identifier requested by the target request; determining the target request and the at least one associated request as requests to be responded to; Cache the pending response request in a request response queue; The requests in the request response queue are processed.
2. A request processing method according to claim 1, characterized in that: The method further comprises: receiving a pending request and determining a priority of the pending request; Determining a first request waiting queue corresponding to the pending request; wherein the queue priority of the first request waiting queue matches the priority of the pending request; The pending request is cached in the first request waiting queue.
3. A request processing method according to claim 1, characterized in that: Each request also carries the target file offset; The step of searching the second request waiting queue for at least one associated request whose time of entering the second request waiting queue is later than the target request comprises: Searching the second request waiting queue for a preset number of candidate requests that entered the second request waiting queue after the target request; wherein the request source identifiers carried by the candidate requests are the same as the request source identifier carried by the target request, and the target file identifiers requested by the candidate requests are the same as the target file identifier requested by the target request; Sort the preset number of candidate requests based on the target file offset carried by each candidate request; The at least one associated request is determined from the preset number of candidate requests based on the sorting result.
4. A request processing method according to claim 1, characterized in that: The method further comprises: Determining a preset number of candidate requests corresponding to the second request waiting queue based on the queue priority of the second request waiting queue and a preset correspondence between the queue priority and the number of requests to be responded to; Among them, in the correspondence relationship between the preset queue priority and the number of requests to be responded to, the number of requests to be responded to corresponding to the high queue priority is greater than the number of requests to be responded to corresponding to the low queue priority.
5. A request processing method according to claim 2, characterized in that: The method further comprises: When caching the pending request in the first request waiting queue, setting a timer for the pending request, the duration of the timer being the waiting response duration of the pending request; Determining the request with the remaining response time being zero as the target request includes: A request for resetting the timer to zero is determined as the target request.
6. A request processing method according to claim 1, characterized in that: The method further comprises: When the request response queue is empty, determining a plurality of non-empty queues among the plurality of request waiting queues; The pending requests are selected from the multiple non-empty queues in descending order of queue priorities of the multiple non-empty queues.
7. A request processing method according to claim 1, characterized in that: The method further comprises: When the number of requests in the request response queue is less than the no-load threshold, increasing the number of the pending requests cached in the request response queue each time, and reducing the waiting response time of each request in the multiple request waiting queues; When the number of requests in the request response queue is greater than or equal to the no-load threshold and less than or equal to the full-load threshold, the number of pending requests cached in the request response queue and the waiting response time of each request in the multiple request waiting queues are kept unchanged; When the number of requests in the request response queue is greater than the full load threshold, the number of the pending requests cached in the request response queue each time is reduced, and the waiting response time of each request in the multiple request waiting queues is increased.
8. A request processing device, characterized in that: include: a request waiting queue determining unit, configured to determine a plurality of request waiting queues having different queue priorities; The queue priority of each request waiting queue matches the priority of the requests in the request waiting queue, and the waiting response time of a high-priority request is shorter than the waiting response time of a low-priority request; each request carries a request source identifier and a requested target file identifier; A monitoring unit is configured to monitor the remaining response time of each request; The remaining response time is the difference between the waiting response time of the request and the time the request enters the request waiting queue; a pending response request determining unit, configured to determine pending response requests based on the remaining response time of each request; The pending request determination unit includes: a second determination unit, configured to determine that the request with the remaining response time being zero is the target request, and a second request waiting queue where the target request is located; an associated request determination unit, configured to search the second request waiting queue for at least one associated request whose time of entering the second request waiting queue is after the target request; wherein the request source identifier carried by the associated request is the same as the request source identifier carried by the target request, and the target file identifier requested by the associated request is the same as the target file identifier requested by the target request; the pending request determination unit is configured to determine the target request and the at least one associated request as the pending request; a pending response request caching unit, configured to cache the pending response request into a request response queue; The request processing unit is configured to process the requests in the request response queue.
9. A request processing device according to claim 8, characterized in that: The device comprises: a pending request receiving unit, configured to receive pending requests and determine the priority of the pending requests; A first determining unit is configured to determine a first request waiting queue corresponding to the pending request; the queue priority of the first request waiting queue matches the priority of the pending request; The pending request caching unit is configured to cache the pending request into the first request waiting queue.
10. A request processing device according to claim 8, characterized in that: Each request also carries the target file offset; The association request determining unit includes: a candidate request determining unit configured to execute, in the second request waiting queue, searching for a preset number of candidate requests that entered the second request waiting queue after the target request; wherein the request source identifiers carried by the candidate requests are the same as the request source identifier carried by the target request, and the target file identifiers requested by the candidate requests are the same as the target file identifier requested by the target request; a candidate request sorting unit, configured to sort the preset number of candidate requests based on a target file offset carried by each candidate request; The third determining unit is configured to determine the at least one associated request from the preset number of candidate requests based on the sorting result.
11. A request processing device according to claim 8, characterized in that: The device further comprises: a candidate request number determining unit configured to determine a preset number of candidate requests corresponding to the second request waiting queue based on the queue priority of the second request waiting queue and a preset correspondence between the queue priority and the number of requests to be responded to; Among them, in the correspondence relationship between the preset queue priority and the number of requests to be responded to, the number of requests to be responded to corresponding to the high queue priority is greater than the number of requests to be responded to corresponding to the low queue priority.
12. A request processing device according to claim 9, characterized in that: The device further comprises: a timer setting unit configured to set a timer for the pending request when caching the pending request in the first request waiting queue, wherein the duration of the timer is the waiting response duration of the pending request; The second determining unit includes: The fourth determining unit is configured to determine a request for resetting the timer to zero as the target request.
13. A request processing device according to claim 8, characterized in that: The device further comprises: a non-empty queue determining unit, configured to determine a plurality of non-empty queues in the plurality of request waiting queues when the request response queue is empty; The pending request selection unit is configured to select the pending request from the multiple non-empty queues in descending order of queue priorities of the multiple non-empty queues.
14. A request processing device according to claim 8, characterized in that: The device further comprises: A first adjusting unit is configured to increase the number of pending requests cached in the request response queue each time and reduce a waiting response time for each request in the plurality of request waiting queues when the number of requests in the request response queue is less than an idle threshold; a maintaining unit configured to maintain the number of pending requests cached in the request response queue each time and the waiting response time of each request in the multiple request waiting queues unchanged when the number of requests in the request response queue is greater than or equal to the no-load threshold and less than or equal to the full-load threshold; The second adjustment unit is configured to reduce the number of pending requests cached in the request response queue each time and increase the waiting response time for each request in the multiple request waiting queues when the number of requests in the request response queue is greater than the full load threshold.
15. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the request processing method according to any one of claims 1 to 7.
16. A computer-readable storage medium, characterized in that When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the request processing method according to any one of claims 1 to 7.
17. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the request processing method according to any one of claims 1 to 7 is implemented.
Citation Information
Patent Citations
Real-time task scheduling method and system based on multicore network processor
CN103942101A
Block chain intelligent contract timed task dispatching method
CN106874087A