Method, apparatus, computer device, and storage medium for processing data requests

Abstract

The present application relates to a method, apparatus, computer device, and storage medium for processing data requests. The method includes: obtaining depth information of waiting queues corresponding to respective request types; respectively calculating current weights of the waiting queues according to priority weights of the respective request types and the depth information of the waiting queues corresponding to the respective request types; for each waiting queue, calculating according to the current number of idle data requests in the processing queue and the current weight of the waiting queue to obtain the number of target data requests corresponding to the waiting queue, where the processing queue includes a plurality of data requests; extracting data requests with the number of target data requests from the waiting queue and adding the data requests with the number of target data requests to the processing queue so that the processing queue processes the data requests.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a method, apparatus, computer device, and storage medium for processing data requests. Background Art

[0002] In a computer system, based on different application scenarios, the requirements for the processing timeliness of various data requests to be processed in the computer system change dynamically. In order to ensure the processing priorities and timeliness of each data request, it is necessary to uniformly manage these data requests.

[0003] In related technologies, generally, the priorities of each data request are determined in advance, and the processing is performed in the order of the priorities of various data requests, so that the timeliness of high-priority data requests can be ensured. However, this will lead to the backlog of low-priority data requests and cannot be processed in time. Summary of the Invention

[0004] Based on this, in view of the above technical problems, it is necessary to provide a method, apparatus, computer device, and storage medium for processing data requests that can ensure the processing timeliness of data requests with different priorities.

[0005] In a first aspect, this application provides a method for processing data requests. The method includes:

[0006] Obtaining the depth information of the waiting queue corresponding to each request type;

[0007] Respectively calculating the current weight of each waiting queue according to the priority weight of each request type and the depth information of the waiting queue corresponding to each request type;

[0008] For each waiting queue, calculating according to the current number of idle requests in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue, where the processing queue includes multiple data requests;

[0009] Extracting the data requests with the target number of data requests from the waiting queue, and adding the data requests with the target number of data requests to the processing queue, so that the processing queue processes the data requests.

[0010] The data request processing method provided by the embodiments of the present application can dynamically calculate the current weights corresponding to each waiting queue, ensure the balance between data requests with different priority weights in the processing queue, increase the processing volume of low-priority data requests, avoid the backlog of low-priority data requests, shorten the response time of high-priority data requests, improve the adaptive processing ability of the service system for data requests of various request types, and further improve the user experience.

[0011] In one embodiment, the depth information includes the real-time queue depth;

[0012] Calculating the current weight of each waiting queue according to the priority weight of each request type and the depth information of the waiting queue corresponding to each request type respectively includes:

[0013] For each waiting queue, determine the maximum priority weight among the priority weights of each waiting queue;

[0014] In the real-time queue depths of each waiting queue, determine the maximum real-time queue depth, and calculate the queue depth weight of the waiting queue according to the real-time queue depth of the waiting queue, the maximum real-time queue depth, and the maximum priority weight;

[0015] Determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

[0016] The data request processing method provided by the embodiments of the present application can determine the trend of the processing pressure of data requests of each request type, and calculate the current weight of the waiting queue corresponding to each request type according to the trend, so as to balance the current weights of the waiting queues of each request type with different priority weights.

[0017] In one embodiment, the depth information further includes the remaining queue depth;

[0018] Determining the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue includes:

[0019] Obtain the remaining queue depth of each waiting queue in the previous cycle of the current processing cycle, and determine the maximum remaining queue depth among the remaining queue depths;

[0020] Calculate the backlog depth weight of the waiting queue according to the remaining queue depth of the waiting queue, the maximum remaining queue depth, and the priority weight;

[0021] Calculate the first sum value of the priority weight of the waiting queue, the queue depth weight of the waiting queue, and the backlog depth weight of the waiting queue, and use the first sum value as the current weight of the waiting queue.

[0022] The data request processing method provided by the embodiments of the present application can dynamically adjust the weights of the waiting queues of various request types according to the number of requests of each request type in the current processing cycle and the remaining requests in the previous cycle, so as to balance the processing volume of high-priority data requests and low-priority data requests, improve the average response time of high-priority data requests, and avoid the backlog of low-priority data requests, thereby improving the user experience.

[0023] In one embodiment, the depth information further includes the remaining queue depth;

[0024] The determining the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue includes:

[0025] Calculate the second sum value of the priority weight of the waiting queue and the queue depth weight of the waiting queue, and use the first sum value as the current weight of the waiting queue.

[0026] The data request processing method provided by the embodiments of the present application can dynamically adjust the weights of the waiting queues of various request types according to the number of requests of each request type in the current processing cycle, so as to balance the processing volume of high-priority data requests and low-priority data requests, improve the average response time of high-priority data requests, and avoid the backlog of low-priority data requests, thereby improving the user experience.

[0027] In one embodiment, the method further includes:

[0028] Obtain the real-time queue depth of the processing queue;

[0029] Calculate the current number of idle requests of the processing queue according to the preset maximum queue depth of the processing queue and the real-time queue depth.

[0030] The data request processing method provided by the embodiments of the present application can obtain the accurate current number of idle requests of the processing queue through the preset maximum queue depth determined based on the actual application scenario and the real-time queue depth of the processing queue, and avoid the backlog of data requests.

[0031] In one embodiment, the method further includes:

[0032] When the real-time queue depth of the processing queue is less than or equal to a preset queue depth threshold, execute the step of obtaining the depth information of the waiting queues corresponding to the respective request types.

[0033] The data request processing method provided by the embodiments of the present application can ensure the continuity of data request processing in the processing queue, avoid the extra time consumption of waiting for data requests to be added to the processing queue, and also reduce the resource consumption of dynamically adjusting the current weights of the respective request types and extracting data requests from the waiting queues.

[0034] In one embodiment, the method further includes:

[0035] Receive a plurality of the data requests;

[0036] When it is determined that the data request processing link meets a preset congestion condition, respectively determine the request types of the respective data requests, and add the respective data requests to the waiting queues corresponding to the request types of the respective data requests.

[0037] The data request processing method provided by the embodiments of the present application can accurately identify the trend of the processing pressure of the respective request types within a certain time range and realize the dynamic adjustment of the weights of the waiting queues of the respective request types by extracting data requests from the respective waiting queues and adding them to the processing queue when it is determined that the data request processing link meets a preset congestion condition.

[0038] In a second aspect, the present application also provides a data request processing device. The device includes:

[0039] An acquisition module, configured to acquire the depth information of the waiting queues corresponding to the respective request types;

[0040] A first calculation module, configured to calculate the current weights of the respective waiting queues respectively according to the priority weights of the respective request types and the depth information of the waiting queues corresponding to the respective request types;

[0041] A second calculation module, configured to calculate, for each of the waiting queues, a target number of data requests corresponding to the waiting queue according to the current number of idle requests in the processing queue and the current weight of the waiting queue, where the processing queue includes a plurality of data requests;

[0042] An addition module, configured to extract the number of data requests of the target number of data requests from the waiting queue and add the number of data requests of the target number of data requests to the processing queue, so that the processing queue processes the data requests.

[0043] In one embodiment, the depth information includes a real-time queue depth;

[0044] The first calculation module is specifically configured to:

[0045] Determine the maximum priority weight among the priority weights of each of the waiting queues, and determine the maximum real-time queue depth among the real-time queue depths of each of the waiting queues;

[0046] For each of the waiting queues, calculate the queue depth weight of the waiting queue according to the real-time queue depth of the waiting queue, the maximum real-time queue depth, and the maximum priority weight;

[0047] Determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

[0048] In one embodiment, the depth information further includes the remaining queue depth;

[0049] The first calculation module is specifically configured to:

[0050] Obtain the remaining queue depths of each of the waiting queues in the previous cycle of the current processing cycle, and determine the maximum remaining queue depth among the remaining queue depths;

[0051] Calculate the backlog depth weight of the waiting queue according to the remaining queue depth of the waiting queue, the maximum remaining queue depth, and the priority weight;

[0052] Calculate the first sum value of the priority weight of the waiting queue, the queue depth weight of the waiting queue, and the backlog depth weight of the waiting queue, and use the first sum value as the current weight of the waiting queue.

[0053] In one embodiment, the depth information further includes the remaining queue depth;

[0054] The first calculation module is specifically configured to:

[0055] Calculate the second sum value of the priority weight of the waiting queue and the queue depth weight of the waiting queue, and use the second sum value as the current weight of the waiting queue.

[0056] In one embodiment, the device further includes:

[0057] A real-time queue depth acquisition module, configured to acquire the real-time queue depth of the processing queue;

[0058] A current idle request number calculation module, configured to calculate the current idle request number of the processing queue according to the preset maximum queue depth of the processing queue and the real-time queue depth.

[0059] In one embodiment, the apparatus further includes:

[0060] An execution module, configured to execute the step of obtaining the depth information of the waiting queue corresponding to each request type when the real-time queue depth of the processing queue is less than or equal to a preset queue depth threshold.

[0061] In one embodiment, the apparatus further includes:

[0062] A receiving module, configured to receive a plurality of the data requests;

[0063] An adding module, configured to determine the request type of each data request respectively and add each data request to the waiting queue corresponding to the request type of each data request when it is determined that the data request processing link meets a preset congestion condition.

[0064] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0065] Obtain the depth information of the waiting queue corresponding to each request type;

[0066] Calculate the current weight of each waiting queue respectively according to the priority weight of each request type and the depth information of the waiting queue corresponding to each request type;

[0067] For each waiting queue, calculate according to the current number of idle requests in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue, where the processing queue includes a plurality of data requests;

[0068] Extract the data requests with the target number of data requests from the waiting queue and add the data requests with the target number of data requests to the processing queue, so that the processing queue processes the data requests.

[0069] In a fourth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0070] Obtain the depth information of the waiting queue corresponding to each request type;

[0071] Calculate the current weight of each waiting queue respectively according to the priority weight of each request type and the depth information of the waiting queue corresponding to each request type;

[0072] For each of the waiting queues, calculate according to the current number of idle requests in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue, where the processing queue contains multiple data requests;

[0073] Extract the data requests with the target number of data requests from the waiting queue, and add the data requests with the target number of data requests to the processing queue, so that the processing queue processes the data requests.

[0074] In a fifth aspect, the present application also provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0075] Obtain the depth information of the waiting queues corresponding to each request type;

[0076] Calculate the current weights of the respective waiting queues according to the priority weights of the respective request types and the depth information of the waiting queues corresponding to the respective request types;

[0077] For each of the waiting queues, calculate according to the current number of idle requests in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue, where the processing queue contains multiple data requests;

[0078] Extract the data requests with the target number of data requests from the waiting queue, and add the data requests with the target number of data requests to the processing queue, so that the processing queue processes the data requests.

[0079] The above method, device, computer device, and storage medium for processing data requests, the method includes: obtaining the depth information of the waiting queues corresponding to each request type; calculating the current weights of the respective waiting queues according to the priority weights of the respective request types and the depth information of the waiting queues corresponding to the respective request types; for each waiting queue, calculate according to the current number of idle requests in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue, where the processing queue contains multiple data requests; extract the data requests with the target number of data requests from the waiting queue, and add the data requests with the target number of data requests to the processing queue, so that the processing queue processes the data requests. By adopting the present invention, the current weights corresponding to each waiting queue can be dynamically calculated, the balance between data requests with different priority weights in the processing queue can be ensured, the processing volume of low-priority data requests can be increased, the backlog of low-priority data requests can be avoided, the response time of high-priority data requests can be shortened, the adaptive processing ability of the service system to data requests of each request type can be improved, and the user experience can also be further improved. Brief Description of the Drawings

[0080] Figure 1 is an application environment diagram of the data request processing method in an embodiment;

[0081] Figure 2 is a flowchart of the data request processing method in an embodiment;

[0082] Figure 3 is a schematic flowchart of the current weight determination step in an embodiment;

[0083] Figure 4 is a schematic flowchart of the current weight determination step in an embodiment;

[0084] Figure 5 is a schematic flowchart of the current weight determination step in an embodiment;

[0085] Figure 6 is a schematic flowchart of the step of determining the current number of idle requests in an embodiment;

[0086] Figure 7 is a schematic flowchart of the partitioning step in an embodiment;

[0087] Figure 8 is a flowchart of the data request processing method in another embodiment;

[0088] Figure 9 is a structural block diagram of the data request processing device in an embodiment;

[0089] Figure 10 is an internal structure diagram of a computer device in an embodiment. Detailed Embodiments

[0090] In order to make the objectives, technical solutions, and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0091] The data request processing method provided by the embodiments of the present application can be applied as follows Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or can be placed on the cloud or other network servers. The server 104 can be the server corresponding to the distributed storage system, or the server corresponding to other computer systems. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptop computers, smart phones, tablet computers, etc. The server 104 can be implemented by an independent server or a server cluster composed of multiple servers.

[0092] Such as Figure 2 As shown, in this embodiment, the method for processing the data request includes the following steps:

[0093] Step 202, obtain the depth information of the waiting queue corresponding to each request type.

[0094] Among them, the data request can be a data request generated in response to a user's trigger request. In one example, the data request can be an io (input output) request generated by the distributed storage system in response to a data modification operation of the user device, or other systems in the computer device. The data request can include multiple types, for example, it can include a user read data request, an internal re-read data request, a pre-read data request, a direct write data request, a flush write data request, and so on. The waiting queue can include multiple data requests, and multiple data requests in the same waiting queue are of the same type. The depth information of the waiting queue is information related to the number of data requests included in the waiting queue.

[0095] In implementation, the distributed storage system generates a data request in response to a user's trigger operation, and sends the data request to the terminal. When the terminal receives at least one data request, it can divide the at least one data request based on the request type to obtain the waiting queue corresponding to each request type. The waiting queue can be used for queuing of each data request when the data request processing link meets the preset congestion condition. In this way, the terminal can count the multiple data requests included in the waiting queue corresponding to each request type to obtain the depth information of the waiting queue.

[0096] Step 204, calculate the current weight of each waiting queue according to the priority weight of each request type and the depth information of the waiting queue corresponding to each request type.

[0097] Among them, the priority weight of each request type can be pre-configured for each request type according to the actual application scenario.

[0098] In implementation, for the waiting queues of multiple request types, the terminal can first obtain the priorities pre-configured for the waiting queues of each request type. The terminal can determine the priority weights of each request type according to the priorities of each request type. In this way, the terminal can calculate the current weight of each waiting queue respectively according to the priority weights of each request type and the depth information of the waiting queue corresponding to each request type.

[0099] Step 206, for each waiting queue, calculate according to the current number of idle requests in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue.

[0100] Among them, the processing queue includes multiple data requests to be processed. The current number of idle requests in the processing queue is the number of data requests that can be added to the processing queue under the current situation.

[0101] In implementation, for the waiting queue corresponding to each request type, the terminal can perform weighted calculation based on the current weight of the waiting queue and the current number of idle requests in the processing queue to obtain the target number of data requests corresponding to the request type. Among them, the current weight of the waiting queue corresponding to each request type can be the ratio of the number of data requests in the waiting queue of the request type to the current number of idle requests in the processing queue.

[0102] Step 208, extract the data requests of the target number of data requests from the waiting queue, and add the data requests of the target number of data requests to the processing queue so that the processing queue processes the data requests.

[0103] In implementation, for each waiting queue, the terminal can calculate the target number of data requests corresponding to the waiting queue based on the steps of the above embodiment, and extract the data requests of the target number of data requests in the waiting queue in the order of the time when each data request enters the waiting queue. In this way, the terminal can add the extracted data requests of the target number of data requests to the processing queue. Based on the above solution, the processing queue can send each data request in the processing queue to the data request processing link according to the preset processing order so that the data request processing link processes the data request. Among them, when the processing queue is a FIFO (First In First Out) queue, the preset processing order can be the time order.

[0104] In the above method for processing data requests, the depth information of the waiting queues corresponding to each request type is obtained. According to the priority weights of each request type and the depth information of the waiting queues corresponding to each request type, the current weights of each waiting queue are calculated respectively. For each waiting queue, based on the current number of idle data requests in the processing queue and the current weight of the waiting queue, a calculation is performed to obtain the target number of data requests corresponding to the waiting queue. The processing queue contains multiple data requests. The data requests with the target number of data requests are extracted from the waiting queue and added to the processing queue, so that the processing queue processes the data requests. By adopting the present invention, the current weights corresponding to each waiting queue can be dynamically calculated, which can ensure the balance between data requests with different priority weights in the processing queue, increase the processing volume of low-priority data requests, avoid the backlog of low-priority data requests, and can also shorten the response time of high-priority data requests at the same time, improve the adaptive processing ability of the service system for data requests of each request type, and further improve the user experience.

[0105] In one embodiment, the depth information includes the real-time queue depth.

[0106] Specifically, the real-time queue depth of the waiting queue represents the number of data requests included in the waiting queue under the current situation.

[0107] Correspondingly, as Figure 3 shown, the specific processing process of step 204 "According to the priority weights of each request type and the depth information of the waiting queues corresponding to each request type, calculate the current weights of each waiting queue respectively" includes:

[0108] Step 302, among the priority weights of each waiting queue, determine the maximum priority weight, and among the real-time queue depths of each waiting queue, determine the maximum real-time queue depth;

[0109] In practice, the terminal can obtain the priority weights (which can be denoted as Tw) of multiple waiting queues, and screen among the priority weights of the multiple waiting queues, and take the maximum priority weight as the maximum priority weight. The terminal can also obtain the real-time queue depth corresponding to each request type, and among the real-time queue depths corresponding to each request type, take the maximum real-time queue depth as the maximum real-time queue depth.

[0110] Step 304, for each waiting queue, calculate the queue depth weight of the waiting queue according to the real-time queue depth, the maximum real-time queue depth, and the maximum priority weight of the waiting queue.

[0111] In implementation, for each waiting queue, the terminal can calculate a first ratio of the real-time queue depth of the waiting queue to the maximum real-time queue depth. Based on this, the terminal can calculate a first product of the maximum priority weight and the first ratio, and use the first product as the queue depth weight of the waiting queue (which can be denoted as Qw). The queue depth weight of the waiting queue indicates that in the current situation, when there is a backlog of data requests in the waiting queue and the backlog situation in the waiting queue is relatively serious, the queue depth weight calculated based on the above solution will also increase accordingly.

[0112] In one example, the terminal can calculate the queue depth weight of the waiting queue through the following formula:

[0113]

[0114] where que depth represents the real-time queue depth of the waiting queue.

[0115] Step 306: Determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

[0116] In implementation, the terminal can determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

[0117] In this embodiment, the trend of the processing pressure of the data requests of each request type can be determined, and the current weight of the waiting queue corresponding to each request type can be calculated according to the trend, so as to balance the current weights of the waiting queues of each request type with different priority weights.

[0118] In one embodiment, the depth information further includes the remaining queue depth.

[0119] Specifically, the terminal can extract a certain number of data requests from the waiting queues of each request type based on the calculated current weights of each request type and add them to the processing queue. The remaining queue depth of the waiting queue represents the remaining number of data requests in the waiting queue after the terminal extracts a certain number of data requests from the waiting queues of each request type and adds them to the waiting queue.

[0120] Correspondingly, as Figure 4 shown, the specific processing process of step 306 "Determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue" includes:

[0121] Step 402: Obtain the remaining queue depth of each waiting queue in the previous cycle of the current processing cycle, and determine the maximum remaining queue depth among the remaining queue depths.

[0122] In implementation, the terminal can perform multiple rounds of adjustment on the processing queue, and each round of adjustment corresponds to a processing period. In this way, the terminal needs to determine the current processing period corresponding to the current situation. When the current processing period (which can be denoted as the i-th processing period) is not the initial processing period, the terminal needs to determine the previous period of the current processing period (which can be denoted as the (i - 1)-th processing period).

[0123] In the (i - 1)-th processing period, the terminal can, based on the method of the above embodiment, determine the current weights of the waiting queues, calculate the current weights of each waiting queue, and calculate the number of target data requests corresponding to the waiting queue. Based on this, the terminal can extract the data requests of the number of target data requests from the waiting queue and count the number of remaining data requests in the waiting queue, that is, the remaining queue depth of the waiting queue in the (i - 1)-th processing period.

[0124] In the i-th processing period, the terminal can obtain the remaining queue depths of the waiting queues corresponding to each request type in the (i - 1)-th processing period, and determine the maximum remaining queue depth among the remaining queue depths of the waiting queues in the (i - 1)-th processing period.

[0125] Step 404: Calculate the backlog depth weight of the waiting queue according to the remaining queue depth of the waiting queue, the maximum remaining queue depth, and the priority weight.

[0126] In implementation, for each waiting queue, the terminal can calculate the second ratio of the remaining queue depth of the waiting queue to the maximum remaining queue depth. Based on this, the terminal can calculate the second product of the maximum priority weight and the second ratio, and use the second product as the backlog depth weight of the waiting queue (which can be denoted as Pw). The backlog depth weight of the waiting queue represents the backlog situation of the remaining data requests in the waiting queue in the current situation. When the backlog situation of the remaining data requests in the waiting queue is relatively serious, the backlog depth weight calculated based on the above scheme will also increase accordingly.

[0127] In one example, the terminal can calculate the backlog depth weight of the waiting queue through the following formula:

[0128]

[0129] where Round_legacy represents the remaining queue depth of the waiting queue in the previous period of the current processing period.

[0130] Step 406: Calculate the first sum of the priority weight of the waiting queue, the queue depth weight of the waiting queue, and the backlog depth weight of the waiting queue, and use the first sum as the current weight of the waiting queue.

[0131] In this way, the terminal can sum up the priority weight of the waiting queue, the queue depth weight of the waiting queue, and the backlog depth weight of the waiting queue to obtain a first sum value. In this way, the terminal can use the obtained first sum value as the current weight of the waiting queue, that is, the weight in the i-th processing cycle.

[0132] In this embodiment, the weight of the waiting queue for each request type can be dynamically adjusted according to the number of requests of each request type in the current processing cycle and the remaining requests in the previous cycle, so as to balance the processing volume of high-priority data requests and low-priority data requests, improve the average response time of high-priority data requests, and avoid the backlog of low-priority data requests, thereby improving the user experience.

[0133] In one embodiment, the current processing cycle includes multiple situations. Correspondingly, the determination process of the current weight of the waiting queue also includes multiple situations. As Figure 5 shown, the specific processing process of step 306 "determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue" includes:

[0134] Step 502, calculate a second sum value of the priority weight of the waiting queue and the queue depth weight of the waiting queue, and use the second sum value as the current weight of the waiting queue.

[0135] In practice, the terminal can perform multiple rounds of adjustment on the processing queue, and each round of adjustment corresponds to a processing cycle. In this way, the terminal needs to determine the current processing cycle corresponding to the current situation. When the current processing cycle is the initial processing cycle (which can be denoted as the 1st processing cycle), the terminal can determine that the remaining queue depth of the waiting queue corresponding to each request type is zero in the current situation. In this way, the terminal can sum up the priority weight of the waiting queue and the queue depth weight of the waiting queue to obtain a second sum value. In this way, the terminal can use the obtained second sum value as the current weight of the waiting queue, that is, obtain the weight of the waiting queue in the 1st processing cycle.

[0136] In this embodiment, the weight of the waiting queue for each request type can be dynamically adjusted according to the number of requests of each request type in the current processing cycle, so as to balance the processing volume of high-priority data requests and low-priority data requests, improve the average response time of high-priority data requests, and avoid the backlog of low-priority data requests, thereby improving the user experience.

[0137] In one embodiment, as Figure 6 shown, the data request processing method further includes:

[0138] Step 602, obtain the real-time queue depth of the processing queue.

[0139] Step 604, calculate the current number of idle requests of the processing queue according to the preset maximum queue depth and the real-time queue depth of the processing queue.

[0140] Among them, the preset maximum queue depth of the processing queue can be pre-configured, and those skilled in the art can also determine it according to the actual application scenario. The present disclosure does not limit this.

[0141] In implementation, the terminal can obtain the number of data requests included in the processing queue in the current situation (the real-time queue depth of the processing queue) and the preset maximum queue depth pre-configured for the processing queue. Based on this, the terminal can perform a subtraction calculation on the preset maximum queue depth and the real-time queue depth of the processing queue, and use the obtained first difference as the current number of idle requests of the processing queue.

[0142] In an example, in order to ensure the timely processing of data requests in the processing queue, the terminal can also pre-determine a preset buffer number, such as 2. In this way, the terminal can perform a subtraction process on the preset maximum queue depth and the real-time queue depth of the processing queue to obtain a first difference. The terminal can also perform a subtraction process on the first difference and the preset buffer number to obtain a second difference, and use the second difference as the current number of idle requests of the processing queue.

[0143] In this embodiment, by using the preset maximum queue depth determined based on the actual application scenario and the real-time queue depth of the processing queue, the current number of idle requests of the processing queue can be accurately obtained, avoiding the backlog of data requests.

[0144] In one embodiment, the method for processing the data request further includes:

[0145] In the case where the real-time queue depth of the processing queue is less than or equal to the preset queue depth threshold, perform the step of obtaining the depth information of the waiting queue corresponding to each request type.

[0146] In implementation, the terminal can monitor the real-time queue depth of the processing queue. In the case where it is monitored that the real-time queue depth of the processing queue is less than or equal to the preset queue depth threshold, the terminal can determine that a certain number of data requests need to be extracted from the waiting queues corresponding to each request type in the current situation, and add the extracted data requests to the processing queue.

[0147] Among them, the preset queue depth threshold can be determined according to the data request processing capabilities of the data request processing link corresponding to the processing queue. The data request processing link can be a system for processing data requests, and the data request processing capabilities of the data request processing link can be the processing time information for processing data requests of each request type. Based on this, the terminal can determine the preset queue depth threshold in combination with the processing time information for processing data requests of each request type by the data request processing link.

[0148] In this embodiment, it is possible to ensure the continuity of the processing of data requests in the processing queue, avoid the additional time consumption of waiting for data requests to be added to the processing queue, and also reduce the resource consumption of dynamically adjusting the current weights of each request type and extracting data requests from the waiting queue.

[0149] In one embodiment, as Figure 7 shown, the data request processing method further includes:

[0150] Step 702, receiving a plurality of data requests.

[0151] Step 704, when it is determined that the data request processing link meets the preset congestion condition, respectively determine the request types of the data requests, and add the data requests to the waiting queues corresponding to the request types of the data requests.

[0152] In implementation, the terminal can obtain at least one monitoring metric of the data request processing link. If the value of at least one monitoring metric is greater than or equal to the monitoring threshold corresponding to the monitoring metric, the terminal can determine that the data request processing link meets the preset congestion condition. When the data request processing link meets the preset congestion condition, each data request received by the terminal needs to queue up and wait to be processed. In this way, the terminal can classify each data request based on the request type and add the data request to the waiting queue corresponding to the request type.

[0153] Among them, the monitoring metrics of the data request processing link can include processing delay and remaining resource volume, etc.

[0154] Optionally, after the step of the terminal adding the data request to the waiting queue corresponding to the request type, the terminal can further perform a driving operation on the processing queue. In response to the driving operation, the processing queue can send the data request to the data request processing link.

[0155] In this embodiment, by extracting data requests from each waiting queue and adding them to the processing queue when it is determined that the data request processing link meets the preset congestion condition, it is possible to accurately identify the trend of the processing pressure of each request type within a certain time range and realize the dynamic adjustment of the weights of the waiting queues of each request type.

[0156] In one embodiment, after the step of receiving a plurality of data requests, the method for processing the data requests further includes:

[0157] Compare the size of the data request with a preset size threshold. If the size of the data request is greater than the preset size threshold, perform a splitting process on the data request to obtain a plurality of split data requests.

[0158] In practice, after the terminal receives a plurality of data requests, it can perform preprocessing on each data request. A possible preprocessing process can be that the terminal compares the size of the data request with a preset size threshold. If the size of the data request is greater than the preset size threshold, perform a splitting process on the data request to obtain a plurality of split data requests.

[0159] In this embodiment, by performing preprocessing on the data requests, the processing speed of the data requests can be improved, and the experience of the user who issues the data requests can be enhanced.

[0160] Next, in combination with Figure 8 ..., the specific implementation process of the method for processing data requests provided by the present invention will be described in detail:

[0161] The terminal can split the data request queue corresponding to the data request processing link into a waiting queue and a processing queue (FIFO queue). The waiting queue is used for queuing data requests (IO requests) corresponding to each request type when the data request processing link meets the preset congestion condition. The processing queue is used to sequentially send the data requests to the data request processing link in chronological order within a preset time period. Each request type may include a user read data request, an internal re-read data request, a pre-read data request, a direct write data request, a flush write data request, and so on.

[0162] When the data request processing link does not meet the preset congestion condition, the terminal can directly send the data request to the data request processing link so that the data request processing link processes the data request.

[0163] When the data request processing link meets the preset congestion condition, the terminal can classify each data request based on the request type and add the data request to the waiting queue corresponding to the request type. Based on this, the terminal can perform a driving operation on the processing queue to determine whether the data requests in the processing queue can be sent to the data request processing link.

[0164] The processing process of the processing queue may include: if the processing queue contains data requests, the multiple data requests contained therein are processed in chronological order. If the real-time queue depth corresponding to the processing queue is less than or equal to the preset queue depth threshold, the terminal may calculate the current weight of each request type according to the method in the foregoing embodiments, and extract a certain number of data requests from the waiting queue of each request type and add them to the processing queue.

[0165] Optionally, the preset queue depth threshold may be zero. In this way, when the terminal determines that the processing queue is an empty queue, the terminal may calculate the current weight of each request type according to the method in the foregoing embodiments, and extract a certain number of data requests from the waiting queue of each request type and add them to the processing queue.

[0166] The terminal may calculate the current weight of each request type through SWRR (Smooth Weighted RoundRobin). The specific process may include: the terminal may assign fixed and different priority weights to each request type according to the actual application scenario and the priority of each request type. In this way, the terminal may determine the priority weight (which may be denoted as Tw) of the waiting queue corresponding to each request type. The terminal may calculate the queue depth weight (which may be denoted as Qw) of the waiting queue corresponding to each request type according to the real-time queue depth (real-time arrangement) of each request type.

[0167] The terminal may process the processing queue multiple times, corresponding to multiple processing cycles. In this way, the terminal may obtain the remaining queue depth of the waiting queue corresponding to each request type in the previous processing cycle, and calculate the backlog depth weight of the waiting queue corresponding to each request type based on the remaining queue depth of the waiting queue corresponding to each request type. In this way, by increasing the weight, the response speed of processing the data requests in the waiting queue where the data requests in the previous processing cycle were not cleared can be increased, and the backlog situation can be avoided.

[0168] In this way, the terminal may calculate the current weight (which may be denoted as W) of the waiting queue based on the sum of the priority weight, the queue depth weight, and the backlog depth weight (which may be denoted as Pw).

[0169] The processing queue may be a FIFO queue, and this FIFO queue can ensure the chronological order of the data requests therein. When the terminal determines that the real-time queue depth (which may be denoted as Depth) of the FIFO queue is less than the preset queue depth threshold, the terminal will calculate the current weight of the waiting queue corresponding to each request type in the current situation, and based on the current weight of the waiting queue corresponding to each request type, extract data requests from the waiting queue corresponding to each request type to the processing queue, so that the processing queue sends the data requests to the data request processing link in chronological order.

[0170] The data request processing method provided by the embodiments of the present invention can dynamically adjust the weights of various request types, thereby balancing the processing volumes of high-priority and low-priority data requests on the data request processing link, improving the average response time of high-priority data requests; avoiding the backlog caused by low-priority data requests not being processed for a long time, and further improving the self-adaptive ability of the distributed storage system, providing users with a better experience and higher comprehensive performance.

[0171] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are sequentially shown in the direction of the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise clearly stated in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same moment, but can be executed at different moments. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0172] Based on the same inventive concept, the embodiments of the present application also provide a data request processing device for implementing the above-mentioned data request processing method. The solution provided by this device for solving problems is similar to the solution described in the above method. Therefore, the specific limitations in one or more embodiments of the data request processing device provided below can refer to the limitations on the data request processing method in the above text, and will not be repeated here.

[0173] In one embodiment, as Figure 9 shown, a data request processing device 900 is provided, including: an acquisition module 901, a first calculation module 902, a second calculation module 903, and an addition module 904, where:

[0174] The acquisition module 901 is used to acquire the depth information of the waiting queue corresponding to each request type.

[0175] The first calculation module 902 is used to calculate the current weight of each waiting queue according to the priority weight of each request type and the depth information of the waiting queue corresponding to each request type.

[0176] The second calculation module 903 is used to calculate, for each waiting queue, the target number of data requests corresponding to the waiting queue according to the current number of idle requests in the processing queue and the current weight of the waiting queue, and the processing queue includes multiple data requests.

[0177] An adding module 904 is configured to extract data requests with a target data request number from a waiting queue and add the data requests with the target data request number to a processing queue, so that the processing queue processes the data requests.

[0178] In one embodiment, the depth information includes a real-time queue depth;

[0179] The first calculation module is specifically configured to:

[0180] Determine a maximum priority weight among the priority weights of the waiting queues and determine a maximum real-time queue depth among the real-time queue depths of the waiting queues;

[0181] For each waiting queue, calculate a queue depth weight of the waiting queue according to the real-time queue depth of the waiting queue, the maximum real-time queue depth, and the maximum priority weight;

[0182] Determine a current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

[0183] In one embodiment, the depth information further includes a remaining queue depth;

[0184] The first calculation module is specifically configured to:

[0185] Obtain the remaining queue depths of the waiting queues in the previous cycle of the current processing cycle, and determine a maximum remaining queue depth among the remaining queue depths;

[0186] Calculate a backlog depth weight of the waiting queue according to the remaining queue depth of the waiting queue, the maximum remaining queue depth, and the priority weight;

[0187] Calculate a first sum value of the priority weight of the waiting queue, the queue depth weight of the waiting queue, and the backlog depth weight of the waiting queue, and use the first sum value as the current weight of the waiting queue.

[0188] In one embodiment, the depth information further includes a remaining queue depth;

[0189] The first calculation module is specifically configured to:

[0190] Calculate a second sum value of the priority weight of the waiting queue and the queue depth weight of the waiting queue, and use the second sum value as the current weight of the waiting queue.

[0191] In one embodiment, the apparatus further includes:

[0192] A real-time queue depth acquisition module, configured to acquire the real-time queue depth of the processing queue;

[0193] A current idle request number calculation module, configured to calculate the current idle request number of the processing queue according to a preset maximum queue depth of the processing queue and the real-time queue depth.

[0194] In one embodiment, the apparatus further includes:

[0195] An execution module, configured to execute the step of acquiring depth information of waiting queues corresponding to respective request types when the real-time queue depth of the processing queue is less than or equal to a preset queue depth threshold.

[0196] In one embodiment, the apparatus further includes:

[0197] A receiving module, configured to receive a plurality of the data requests;

[0198] An adding module, configured to, when determining that a data request processing link meets a preset congestion condition, respectively determine request types of the respective data requests, and add the respective data requests to waiting queues corresponding to the request types of the respective data requests.

[0199] Each module in the above data request processing apparatus 900 may be implemented in whole or in part by software, hardware, and a combination thereof. The above modules may be embedded in a processor in a computer device in a hardware form or be independent of the processor, or may be stored in a memory in the computer device in a software form, so as to be called by the processor to execute operations corresponding to the above respective modules.

[0200] In one embodiment, a computer device is provided. The computer device may be a server, and an internal structure diagram thereof may be as Figure 10 shown. The computer device includes a processor, a memory, and a network interface connected through a system bus. Wherein, the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The database of the computer device is configured to store data request data. The network interface of the computer device is configured to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a data request processing method is implemented.

[0201] Those skilled in the art can understand, Figure 10The structure shown is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0202] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0203] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0204] In one embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0205] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data that have been authorized by the user or fully authorized by all parties.

[0206] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memories. Non-volatile memory can include Read-Only Memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in this application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in this application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.

[0207] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0208] The above-described embodiments merely represent several implementation manners of this application. The description is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of this application. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several modifications and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application should be subject to the appended claims.

Claims

1. A method for processing a data request, characterized in that, The method includes: Obtaining the depth information of the waiting queues corresponding to each request type; the depth information includes the real-time queue depth; Calculating the current weight of each waiting queue respectively according to the priority weights of each request type and the depth information of the waiting queues corresponding to each request type; For each waiting queue, calculating according to the current number of idle request in the processing queue and the current weight of the waiting queue to obtain the target number of data requests corresponding to the waiting queue, where the processing queue includes a plurality of data requests; Extracting the data requests of the target number of data requests from the waiting queue and adding the data requests of the target number of data requests to the processing queue, so that the processing queue processes the data requests; The calculating the current weight of each waiting queue respectively according to the priority weights of each request type and the depth information of the waiting queues corresponding to each request type includes: Determining the maximum priority weight among the priority weights of each waiting queue, and determining the maximum real-time queue depth among the real-time queue depths of each waiting queue; for each waiting queue, calculating the queue depth weight of the waiting queue according to the real-time queue depth of the waiting queue, the maximum real-time queue depth and the maximum priority weight; determining the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

2. The method according to claim 1, characterized in that, The depth information further includes the remaining queue depth; The determining the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue includes: Obtaining the remaining queue depth of each waiting queue in the previous cycle of the current processing cycle, and determining the maximum remaining queue depth among the remaining queue depths; Calculating the backlog depth weight of the waiting queue according to the remaining queue depth of the waiting queue, the maximum remaining queue depth and the priority weight; Calculating the first sum value of the priority weight of the waiting queue, the queue depth weight of the waiting queue and the backlog depth weight of the waiting queue, and using the first sum value as the current weight of the waiting queue.

3. The method according to claim 1, characterized in that, The depth information further includes the remaining queue depth; The determining the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue includes: Calculating the second sum value of the priority weight of the waiting queue and the queue depth weight of the waiting queue, and using the second sum value as the current weight of the waiting queue.

4. The method according to claim 1, characterized in that, The method further includes: Obtaining the real-time queue depth of the processing queue; Calculating the current number of idle request in the processing queue according to the preset maximum queue depth of the processing queue and the real-time queue depth.

5. The method according to claim 4, characterized in that, The method further includes: When the real-time queue depth of the processing queue is less than or equal to the preset queue depth threshold, performing the step of obtaining the depth information of the waiting queues corresponding to each request type.

6. The method according to claim 1, characterized in that, The method further includes: Receiving a plurality of the data requests; When it is determined that the data request processing link meets the preset congestion condition, the request types of the respective data requests are determined, and the respective data requests are added to the waiting queue corresponding to the request type of the respective data requests.

7. A device for processing a data request, characterized in that, The device includes: an acquisition module, configured to acquire depth information of the waiting queues corresponding to the respective request types; the depth information includes a real-time queue depth; a first calculation module, configured to calculate the current weight of each of the waiting queues respectively according to the priority weights of the respective request types and the depth information of the waiting queues corresponding to the respective request types; a second calculation module, configured to calculate, for each of the waiting queues, a target number of data requests corresponding to the waiting queue according to the current number of idle requests in the processing queue and the current weight of the waiting queue, where the processing queue includes a plurality of data requests; an addition module, configured to extract the number of data requests of the target number of data requests in the waiting queue, and add the number of data requests of the target number of data requests to the processing queue, so that the processing queue processes the data requests; The first calculation module is specifically configured to: determine the maximum priority weight among the priority weights of the respective waiting queues, and determine the maximum real-time queue depth among the real-time queue depths of the respective waiting queues; for each of the waiting queues, calculate the queue depth weight of the waiting queue according to the real-time queue depth of the waiting queue, the maximum real-time queue depth, and the maximum priority weight; Determine the current weight of the waiting queue according to the priority weight of the waiting queue and the queue depth weight of the waiting queue.

8. The device according to claim 7, characterized in that, The depth information further includes a remaining queue depth; the first calculation module is specifically configured to: acquire the remaining queue depths of the respective waiting queues in the previous cycle of the current processing cycle, and determine the maximum remaining queue depth among the respective remaining queue depths; calculate the backlog depth weight of the waiting queue according to the remaining queue depth of the waiting queue, the maximum remaining queue depth, and the priority weight; calculate a first sum value of the priority weight of the waiting queue, the queue depth weight of the waiting queue, and the backlog depth weight of the waiting queue, and use the first sum value as the current weight of the waiting queue.

9. A computer device, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium, having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images