Request processing method and device

Abstract

The embodiments of this specification provide a request processing method and device, wherein the request processing method includes: determining a corresponding request processing queue for a received initial data processing request, and determining a request storage unit corresponding to the request processing queue; storing the initial data processing request in the request storage unit, and merging the initial data processing requests in the request storage unit to obtain a target data processing request; sending the target data processing request to the request processing queue when it is determined that the current state information of the request storage unit meets a preset storage condition; and storing the target data processing request based on the request processing queue. This avoids the write amplification phenomenon caused by a large amount of storage space in the cache not being used, and further saves storage resources.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technology, and in particular to a request processing method. Background Art

[0002] With the continuous development of computer technology, in the message storage scenario, the operating system will write the received messages (such as requests sent by the client) into the cache, and directly store the messages in the cache to the storage module (such as disk, hard disk, cloud disk, etc.) through the asynchronous disk flushing mechanism. In this process, because the data volume of the message is too fragmented and cannot reach the unit size of a cache (for example, the size is 4K), when the operating system stores the messages written into the cache into the storage module through the disk flushing mechanism, since a large amount of storage space in the cache is not used, it will produce a significant write amplification phenomenon (that is, the actual amount of data written is greater than the required amount of data), resulting in a large amount of storage resources Waste. Summary of the invention

[0003] In view of this, an embodiment of this specification provides a request processing method. One or more embodiments of this specification also relate to a request processing device, a computing device, a computer-readable storage medium, and a computer program to solve the technical defects existing in the prior art.

[0004] According to a first aspect of an embodiment of this specification, a request processing method is provided, including:

[0005] Determine a corresponding request processing queue for the received initial data processing request, and determine a request storage unit corresponding to the request processing queue;

[0006] storing the initial data processing request in the request storage unit, and merging the initial data processing requests in the request storage unit to obtain a target data processing request;

[0007] When it is determined that the current state information of the request storage unit meets the preset storage condition, sending the target data processing request to the request processing queue;

[0008] The target data processing request is stored based on the request processing queue.

[0009] According to a second aspect of an embodiment of this specification, a request processing device is provided, including:

[0010] a determination module configured to determine a corresponding request processing queue for the received initial data processing request, and determine a request storage unit corresponding to the request processing queue;

[0011] a merging module, configured to store the initial data processing request in the request storage unit, and perform merging processing on the initial data processing request in the request storage unit to obtain a target data processing request;

[0012] a sending queue module, configured to send the target data processing request to the request processing queue when determining that the current state information of the request storage unit meets a preset storage condition;

[0013] The storage module is configured to store the target data processing request based on the request processing queue.

[0014] According to a third aspect of an embodiment of this specification, a computing device is provided, including:

[0015] Memory and processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the request processing method are implemented.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the request processing method are implemented.

[0018] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the request processing method.

[0019] The request processing method provided in this specification includes: determining a corresponding request processing queue for a received initial data processing request, and determining a request storage unit corresponding to the request processing queue; storing the initial data processing request in the request storage unit, and merging the initial data processing requests in the request storage unit to obtain a target data processing request; when it is determined that the current status information of the request storage unit meets a preset storage condition, sending the target data processing request to the request processing queue; and storing the target data processing request based on the request processing queue.

[0020] Specifically, the method stores the initial data processing request in the request storage unit corresponding to the request processing queue, and merges the initial data processing request to obtain the target data processing request, and when the current status information of the request storage unit meets the preset storage condition, the target data processing request is stored through the request processing queue, thereby avoiding the write amplification phenomenon caused by a large amount of unused storage space in the cache, and further saving storage resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a schematic diagram of a client batch solution provided by an embodiment of this specification;

[0022] Figure 2 It is a schematic diagram of a solution for a server to write separate files by slices provided by an embodiment of this specification;

[0023] Figure 3 This is a schematic diagram of an application scenario of a request processing method provided by an embodiment of this specification;

[0024] Figure 4 is a flowchart of a request processing method provided by an embodiment of this specification;

[0025] FIG5 is a flowchart of a request processing method provided by an embodiment of the present specification;

[0026] Figure 6 is a schematic diagram of the structure of a request processing device provided by an embodiment of this specification;

[0027] Figure 7 It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0028] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0029] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0030] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0031] First, the terms involved in one or more embodiments of this specification are explained.

[0032] Page Cache: Page cache, used to cache file page data.

[0033] CommitLog: is a write-ahead log. The data system generally stores the received data in CommitLog in order to speed up data processing.

[0034] Page Cache: When reading and writing disk files, part of the file is cached in memory to improve performance. The default size of each page of Page Cache is 4KB.

[0035] Write Amplification: It is an IO phenomenon, which means that the amount of data actually written is greater than the amount of data required. Write amplification will increase the write cost. There are many reasons for this. For example, because the amount of data requested by the client each time is too small, the page cache data amount is less than 4KB. At this time, the operating system triggers dirty page writeback, resulting in the actual amount of data written being many times greater than the required amount of data.

[0036] The CommitLog-based message engine can achieve high storage performance through sequential writing to Page Cache and asynchronous disk flushing mechanism. However, there are the following challenges in the multi-partition fragmented message storage scenario: For example, in terms of IO, the amount of data initiated by the client's write request is too fragmented and not enough for the unit size of PageCache. For example, the unit size of a PageCache is 4K; therefore, when the operating system triggers IO behavior, it will produce significant write amplification, causing the system to pay a write cost that is dozens of times the original data size.

[0037] At the same time, due to the limitation of IO bandwidth, IO shortage is formed, which generates back pressure and affects the overall write performance of the system. That is to say, the system writes data to the disk in 4K size, but due to the write amplification effect, the actual amount of data written is greater than the required amount of data. Therefore, when the IO bandwidth reaches the limit (for example, the single-second throughput is 140 megabytes), the disk storage space has been fully used, resulting in the inability to store data from the upper network to the disk, so there will be IO shortage, resulting in back pressure.

[0038] At the same time, in terms of computing, due to the exclusive lock of CommitLog, each IO request can only be processed by one thread, which will block all other partition requests and fail to efficiently utilize the advantages of multi-core parallel computing, thus affecting write performance.

[0039] Therefore, this manual provides two solutions to the write amplification phenomenon. The first solution is: client batch (merge messages); see Figure 1 , Figure 1 This is a schematic diagram of a client batch solution provided in an embodiment of this specification; specifically, after receiving a message (Message, such as IO request, write request, read request, etc.), the client stores the message in the cache through the RecordAccumulator process, and merges the message in the cache to obtain a merged message (batch); then the merged message is sent to the Broker through the sending module (Sender). Among them, the advantages and disadvantages of this solution are: client batch can solve the fragmentation problem caused by a small number of clients, but cannot solve the fragmentation problem caused by multiple clients.

[0040] The second option is: See Figure 2 , Figure 2 The schematic diagram of a solution for writing separate files by slices provided by an embodiment of the present specification is as follows; specifically, the server writes separate files by slices. In the page cache, the solution creates a corresponding storage file (i.e. Figure 2 "Partition queue 0-24" to "Partition queue 0-28", and "Partition queue 1-724" to "Partition queue 1-11"), where the partition queue stores messages in the memory. Then, the messages of each partition queue are written sequentially to the storage file in the corresponding page cache by locked writing. Among them, the advantages and disadvantages of this solution are: this method realizes multi-threaded concurrent writing and improves writing efficiency; but it cannot solve the problem of write amplification caused by fragmented messages. At the same time, once there are more partition queues, there will be file fragmentation problems, resulting in a large number of random writes on IO, and the performance will drop sharply.

[0041] Based on this, in this specification, a request processing method is provided. This specification also involves a request processing device, a computing device, a computer-readable storage medium and a computer program, which are described in detail one by one in the following embodiments.

[0042] Figure 3 A schematic diagram of an application scenario of a request processing method provided according to an embodiment of this specification is shown, wherein: Figure 3 The 301 here refers to Msg (i.e. message). Figure 3 The 302 here refers to Local batch (i.e. local batch cache). Figure 3 The 303 in the header refers to the batch buffer. Figure 3The English explanations of the terms in the following are respectively: Commit buffer. Accumulate Service. Requests, which can be understood as the initial data processing request in this specification. Asynchronous callback result (Future). Future interface management request (Future manager). Buffer pool. Lock separation request. Parallel batch request. File that stores consumer (user) offset information (Offsets). Expiration time. Pools manager. Poll batch. Sub-pool thread. No competition. Automatic recycling. Apply offset. Partition queue. Top queue batch. Batch results (batches). Accumulate Service getbatches. Check whether the batch result meets the preset condition (Check follow condition). Batches waiting to be written to disk (Inflight bathes). Last defaultfile. Offsetcheck. Offsetrebuild. Batch write, which means writing the batch results to disk. Commitlog. Complete. Build index. Collect batch buffer. Pool batchbuffer. Send batch results to Consume queue. Consume queue. Bytebuffer. Preen code can be understood as a kind of encoding.

[0043] It should be noted that Figure 3The capacity is full in the local batch cache, which can be understood as the capacity of the local batch cache has reached the preset capacity threshold, which can be 80%; that is, the local batch cache is full of requests, and the capacity is full can be represented by Full. The request expiration can be understood as the request stored in the local batch cache has expired, and the request expiration can be represented by Expire.

[0044] See also Figure 3 It can be seen that the request processing method provided in this specification provides a request processing system, which is composed of two core subsystems: Commit Buffer and Accumulate Service. Commit Buffer is responsible for: partitioned parallel computing, memory pool management, request merging and other core functions; Accumulate Service is responsible for batch storage, memory recycling and other core functions. Through the execution process of Commit Buffer and the execution process of Accumulate Service, functions such as partitioned parallel computing, pre-merging IO requests, and batch storage can be realized; specifically, the request processing method provided in this specification builds a partitioned cache queue through memory pool and Local batch to achieve high-performance parallel computing. Through the pre-calculation of the partitioned cache queue, the benefits of parallel computing are obtained while not occupying disk IO resources, and high-performance parallel merging is achieved. And through the FIFO queue, the Accumulate Service single-thread obtains the merged IO request, ensuring sequential writing while batch storage significantly reduces write amplification. Thereby greatly reducing IOPS while significantly reducing the phenomenon of write amplification, which not only saves IO bandwidth, but also significantly improves the performance of message storage. It should be noted that this Figure 3 For the specific steps of implementing the request processing method of the components shown in Figure 4 , and the corresponding contents in Figure 5 will not be elaborated in this manual.

[0045] Figure 4 A flowchart of a request processing method provided according to an embodiment of the present specification is shown, which specifically includes the following steps.

[0046] It should be noted that the request processing method provided in this specification includes two processes: a request queue entry process, and a request storage process. Among them, the request queue entry process includes: determining the corresponding request processing queue for the received initial data processing request, and determining the request storage unit corresponding to the request processing queue; storing the initial data processing request to the request storage unit, and merging the initial data processing request in the request storage unit to obtain the target data processing request; when it is determined that the current status information of the request storage unit meets the preset storage conditions, sending the target data processing request to the request processing queue. For example, the above-mentioned Commit Buffer process.

[0047] The request storage process includes storing the target data processing request based on the request processing queue, for example, the Accumulate Service process.

[0048] Moreover, the request processing method provided in this specification can be applied in different scenarios. For example, in a cloud storage scenario, the request processing method provided in this specification can be applied to a server of a cloud storage system. The cloud storage system may include a server and a data storage module (such as a cloud disk, a disk, a solid-state hard disk, etc.). The server is used to process and merge received requests and / or messages, and send the processed requests and / or messages to the data storage module for storage. The data storage module is used to store received data (including but not limited to requests, messages, etc.).

[0049] For example, in a distributed storage scenario, the request processing method provided in this specification can be applied to a request processing node of a distributed storage system. The distributed storage system may include a request processing node and a request storage node. The request processing node is used to process and merge received requests and / or messages, and send the processed requests and / or messages to the request storage node for storage. The request storage node is used to store received data (including but not limited to requests, messages, etc.).

[0050] Step 402: Determine a corresponding request processing queue for the received initial data processing request, and determine a request storage unit corresponding to the request processing queue.

[0051] It should be noted that the request processing method provided in this specification can be applied in different scenarios. For the sake of convenience, the request processing method is described by taking the application of the request processing method to a cloud storage scenario as an example. In the case of a cloud storage scenario, the request processing method is applied to a server of a cloud storage system. In addition, for the description of the application of the request processing method to other scenarios, please refer to the corresponding or corresponding content in this specification, and this specification does not make any specific restrictions here.

[0052] The initial data processing request may be understood as a request received by the server, and the initial data processing request includes but is not limited to a read request, a write request, an IO request, etc.;

[0053] A request processing queue can be understood as a queue that can store the received initial data processing requests according to the first-in-first-out rule, such as a partition queue; when the request processing method is applied to a cloud storage scenario, the server can store the initial data processing requests in the partition queue to the cloud disk according to the first-in-first-out rule.

[0054] The request storage unit can be understood as a storage unit that can pre-store requests that need to be placed in the request processing queue, such as a cache, a local batch (local batch cache), etc. It should be noted that the request processing method provided in this specification, in order to avoid the write amplification phenomenon, needs to perform parallel merging processing on the received requests, and then put the merged requests into the queue after completing the parallel merging processing. Therefore, in order to ensure the smooth progress of the data merging processing, the corresponding cache will be determined for different queues, and the received request will be stored in the cache corresponding to the queue.

[0055] The following is an example of the application of the request processing method provided in this specification in the scenario of storing messages in batches based on partition queues through and merging, and further describes the determination of the corresponding request processing queue and request storage unit for the received initial data processing request. The initial data processing request may be an IO request, the request processing queue may be a partition queue, and the request storage unit may be a local batch.

[0056] Based on this, in a cloud storage scenario, the client can send an IO request to the server of the cloud storage system. After receiving the IO request, the server can determine the corresponding partition queue for the IO request and determine the local batch corresponding to the partition queue.

[0057] Furthermore, in an embodiment provided in this specification, after receiving the initial data processing request, the server can store the initial data processing request in the cloud disk through the Topic message delivery model. Each topic corresponds to multiple partition queues. Based on this, the server can determine the corresponding topic according to the request type of the initial data processing request; and select an idle partition queue from the partition queue corresponding to the topic, and store the request in the cloud disk. Specifically, the corresponding request processing queue for the received initial data processing request includes:

[0058] Determining a request type of the received initial data processing request, and determining a queue type corresponding to the request type;

[0059] Determine at least two request processing queues corresponding to the queue type, and respectively determine current status information of the at least two request processing queues;

[0060] Based on the current state information, a corresponding request processing queue is determined for the initial data processing request from the at least two request processing queues.

[0061] The request type may be understood as the type of the initial data processing request, for example, when the initial data processing request is an IO request, the request type is an IO request type. When the initial data processing request is a write request, the request type is a write request type.

[0062] The queue type can be understood as the type of the request processing queue. The same type of request processing queues are used to process the same type of data processing requests. For example, the queue type can be the topic to which the request processing queue belongs.

[0063] The current status information may be understood as any information that can characterize whether the request processing queue is currently idle, for example, the number of requests currently stored in the request processing queue.

[0064] Specifically, after receiving the initial data processing request, the server can determine the request type of the initial data processing request and determine the queue type corresponding to the request type. In actual applications, the server records the corresponding relationship between the request type and the queue type.

[0065] The server then determines at least two request processing queues corresponding to the queue type, and respectively determines current status information of each of the at least two request processing queues.

[0066] Based on the current state information, a request processing queue with better performance is determined from at least two request processing queues, and the request processing queue with better performance is used as the request processing queue corresponding to the initial data processing request. The request processing queue with better performance can be understood as the most idle request processing queue.

[0067] Continuing with the above example, after receiving the IO request, the server can determine the corresponding topic for it according to the type of the IO request, and determine the multiple partition queues corresponding to the topic; obtain information characterizing the idle state of each partition queue (such as the number of requests in the partition queue); based on the information, select the most idle partition queue from multiple partition queues, and use the most idle partition queue as the queue for storing the IO request to the cloud disk.

[0068] In the embodiments provided in this specification, based on the request type of the initial data processing request, a corresponding request processing queue is quickly and accurately determined for the initial data processing request from at least two request processing queues, so as to facilitate subsequent processing of the initial data processing request based on the request processing queue.

[0069] Furthermore, in the embodiments provided in the present specification, when the server is determining the request storage unit corresponding to the request processing queue, there may be a situation where the request processing queue does not have a corresponding request storage unit, or the capacity of the request storage unit corresponding to the request processing queue is insufficient to accommodate the initial data processing request. In this case, in order to ensure that the initial data processing request can be merged, it is necessary to create a corresponding request storage unit for the request processing queue. That is to say, when it is determined that the request processing queue does not have a corresponding request storage unit, or the request storage unit corresponding to the request processing queue does not meet the request storage conditions, a corresponding request storage unit is created for the request processing queue, thereby ensuring that the merge processing for the initial data processing request can be smoothly executed, thereby further avoiding the write amplification phenomenon caused by a large amount of unused storage space in the cache. Specifically, the determination of the request storage unit corresponding to the request processing queue includes:

[0070] After determining that the request processing queue does not have a corresponding request storage unit, or

[0071] When the request storage unit corresponding to the request processing queue does not meet the request storage condition, a request is acquired based on the attribute information of the request processing queue and the attribute information generating unit of the initial data processing request;

[0072] sending the unit acquisition request to a unit allocation module;

[0073] The unit allocation module obtains the request storage unit allocated to the request processing queue from the preset to-be-allocated module in response to the unit acquisition request.

[0074] The request storage unit not meeting the request storage condition can be set according to the actual application scenario, and this specification does not impose specific restrictions on this. For example, in actual applications, when the remaining storage space of the request storage unit is insufficient to accommodate the initial data processing request, it is determined that the request storage unit does not meet the request storage condition. Alternatively, after the target data in the request storage unit has been processed and stored, but the request storage unit has not been recycled, it is determined that the request storage unit does not meet the request storage condition. Alternatively, when the request storage unit is set to prohibit access, it is determined that the request storage unit does not meet the request storage condition.

[0075] The attribute information of the request processing queue includes, but is not limited to, identification information of the request processing queue (for example, the identification information may be information such as name, ID, number, etc.).

[0076] The attribute information of the initial data processing request includes, but is not limited to, identification information, request type, size, and other information of the initial data processing request.

[0077] The unit allocation module may be understood as a module in the server that can allocate corresponding request storage units to the request processing queue. For example, the unit allocation module may be a memory pool management module.

[0078] The unit acquisition request can be understood as an application to the unit allocation module to allocate a module that requests a storage unit. For example, when the requested storage unit is a local batch, the unit acquisition request is a local batch application. Therefore, the local batch application can carry the identification information of the partition queue and the size of the write request. Subsequently, based on the identification information and the size of the write request, a local batch that can accommodate the write request can be allocated to the partition queue.

[0079] The unit acquisition request can carry the identification information of the request processing queue and the size of the initial data processing request

[0080] The preset module to be allocated can be understood as a module that is predetermined by the unit allocation module for the request processing queue and is dedicated to allocating the corresponding request storage unit to the request processing queue when a unit acquisition request is received. In actual applications, the request storage unit belongs to the preset module to be allocated. In actual applications, in order to quickly allocate the corresponding local batch to the partition queue, the memory pool management module will pre-allocate a storage area (i.e., the preset module to be allocated) from the memory for the partition queue. When a local batch application (i.e., a unit acquisition request) is received, a sub-area of ​​the same size can be allocated from the storage area for the partition queue as the local batch.

[0081] Continuing with the above example, after the server selects a partition queue for an IO request, it needs to determine whether the local batch corresponding to the partition queue exists, or whether the remaining capacity of the local batch corresponding to the partition queue can accommodate the IO request.

[0082] When there is no corresponding local batch for the partition queue, or the remaining capacity of the local batch corresponding to the partition queue cannot accommodate the IO request, a new local batch is requested from the memory pool management module based on the identification information of the partition queue and the size of the IO request.

[0083] After receiving the application, the memory pool management module can allocate an area large enough to accommodate the IO request as a local batch for the partition queue applying for a new local batch from the memory area pre-allocated for all partition queues.

[0084] Step 404: Store the initial data processing request in the request storage unit, and merge the initial data processing requests in the request storage unit to obtain a target data processing request.

[0085] Among them, the merging of the initial data processing requests can be achieved by any method that can achieve request merging, and this manual does not impose specific restrictions on this. For example, all IO requests currently stored in the local batch are packaged and processed, and when a new request is written in the local batch, the new request can be repackaged with the historically packaged IO, thereby merging the IO requests in the local batch. Alternatively, determine the logical address that needs to be operated in the IO request data storage module, and merge multiple IO requests with consecutive logical addresses into one request. Request merging is thus achieved.

[0086] Specifically, the server stores the initial data processing request in a request storage unit, and merges the initial data processing requests in the request storage unit to obtain a target data processing request.

[0087] Furthermore, in the process of storing the initial data processing request in the request storage unit, in order to facilitate the subsequent rapid and secure merging and processing of the initial data processing request, the initial data processing request will be pre-processed; the pre-processing includes but is not limited to serialization operations, data local integrity verification, security verification, etc., which are not specifically limited in this specification, so as to ensure the regularity, integrity, and completeness of the initial data processing request. Specifically, the storing of the initial data processing request in the request storage unit includes:

[0088] Preprocessing the initial data processing request to obtain a processed initial data processing request;

[0089] The processed initial data processing request is stored in the request storage unit.

[0090] The preprocessing of the initial data processing request includes but is not limited to serialization operations, local data integrity verification, security verification, etc., which are not specifically limited in this specification. Moreover, the preprocessing can be implemented in any way, which is not specifically limited in this specification.

[0091] Continuing with the above example, when the server stores the IO request in the local batch, it will perform serialization operations, local data integrity verification, security verification and other processing on the IO request, and store the processed IO request in the localbatch.

[0092] Further, in the embodiment provided in this specification, the merging process of the initial data processing requests in the request storage unit to obtain the target data processing request includes:

[0093] When it is determined that at least two initial data processing requests are stored in the request storage unit, the at least two initial data processing requests are merged to obtain a target data processing request.

[0094] Using the above example, when the server determines that there are at least two IO requests in the local batch, it can merge the at least two IO requests to obtain a merged IO request. This avoids the write amplification phenomenon caused by a large amount of unused storage space in the cache, further saving storage resources.

[0095] Step 406: When it is determined that the current state information of the request storage unit meets the preset storage condition, the target data processing request is sent to the request processing queue.

[0096] Among them, the current status information can be understood as information that characterizes the current status of the request storage unit, for example, the current remaining capacity of the local batch, the current used capacity of the local batch, the reception time of the IO request stored in the local batch, etc.

[0097] The preset storage condition can be set according to the actual application scenario, and this specification does not impose specific restrictions on this. For example, when the current status information is the current remaining capacity of the local batch, when the current remaining capacity of the local batch is lower than the preset capacity threshold (for example, 5%), it is determined that the current status information meets the preset storage condition. Alternatively, when the current status information is the reception time of the IO request stored in the local batch, in order to ensure that the IO request is not lost, the time difference between the reception time of the IO request and the current time is greater than the preset time threshold (for example, 1 minute), it is determined that the current status information meets the preset storage condition.

[0098] Continuing with the above example, the current status information of the requested storage unit is the current remaining capacity of the local batch; based on this, the server will obtain the current remaining capacity of the local batch in real time. When it is determined that the current remaining capacity is lower than the preset capacity threshold (for example, 5%), it is determined that the current status information meets the preset storage condition, and the IO requests obtained after the merge processing in the local batch are sent to the partition queue.

[0099] Step 406: Store the target data processing request based on the request processing queue.

[0100] In one embodiment provided in this specification, storing the target data processing request based on the request processing queue includes:

[0101] A target data processing request is obtained from the request processing queue, and the target data processing request is stored in a request storage module.

[0102] The request storage module may be understood as a module for storing the request, such as a disk, a network disk, or an SSD (solid state drive).

[0103] Specifically, after the server sends the target data processing request to the request processing queue, the server can obtain the target data processing request from the request processing queue in a first-in-first-out manner, and store the target data processing request in the request storage module.

[0104] Furthermore, in the embodiments provided in this specification, due to the low number of initial data processing requests, there may be a situation where there are no target data processing requests that need to be stored in the request storage module in the request processing queue, which further causes the data processing requests stored in the request storage unit to be lost. Based on this, the server can determine the request storage unit corresponding to the request processing queue, directly obtain the current target data processing request in the request storage unit, and send the target data processing request to the request processing queue. Specifically, before obtaining the target data processing request from the request processing queue, it also includes:

[0105] In a case where it is determined that there is no target data processing request in the request processing queue, determining the request storage unit corresponding to the request processing queue;

[0106] The target data processing request is obtained from the request storage unit, and the target data processing request is sent to the request processing queue.

[0107] Continuing with the above example, when the server determines that there is no batch (merged IO request) to be written to the partition queue, it determines the local batch corresponding to the partition queue, obtains the merged IO request from the local batch, and stores the IO request in the partition queue, so as to facilitate the subsequent storage of the batch (merged IO request) in the partition queue to the cloud disk, thereby avoiding the problem of data processing requests stored in the request storage unit being lost due to the low number of initial data processing requests.

[0108] Furthermore, in the embodiments provided in this specification, each topic corresponds to multiple partition queues. In this case, when the server processes the target data in the partition queue and requests to store the cloud disk, it will loop through the partition queues, select writable batches from the multiple partition queues, and write them to the cloud disk, thereby improving the writing efficiency of the request through the parallel processing of multiple partition queues. Specifically, the request processing queue includes at least two;

[0109] Accordingly, obtaining the target data processing request from the request processing queue includes:

[0110] When it is determined that the target data processing request exists in at least two request processing queues, the target data processing request is obtained from the at least two request processing queues.

[0111] Using the above example, the server will loop through the partition queues. When it is determined that there are batches that need to be written to the cloud disk in multiple partition queues, it will select the batches that can be written and write them to the cloud disk.

[0112] In the embodiment provided in this specification, due to the low number of initial data processing requests, there may be a situation where there are no target data processing requests that need to be stored in the request storage module in the request processing queue, further resulting in the loss of the data processing requests stored in the request storage unit. Based on this, the request processing queue includes at least two;

[0113] Accordingly, obtaining the target data processing request from the request processing queue includes:

[0114] In a case where it is determined that there is no target data processing request in at least two request processing queues, respectively determining a request storage unit corresponding to each request processing queue;

[0115] The target data processing request is obtained from the request storage unit, and the target data processing request is sent to the request processing queue.

[0116] Continuing with the above example, when the server determines that all partition queues have no writable batches (merged IO requests), it determines the local batch corresponding to each partition queue, obtains the merged IO requests from the local batch, and stores the IO requests in the partition queue, so as to facilitate the subsequent storage of the batches (merged IO requests) in the partition queue to the cloud disk, thereby avoiding the problem of data processing requests stored in the request storage unit being lost due to the low number of initial data processing requests.

[0117] In the embodiment provided in this specification, the process of obtaining the target data processing request from the request storage unit when there is no target data processing request in the request processing queue is to avoid the problem of data processing requests stored in the request storage unit being lost due to the low number of initial data processing requests. Therefore, when obtaining the target data processing request from the request storage unit, it is necessary to determine whether the creation time of the target data processing request is greater than the preset storage time threshold, and obtain the target data processing request if it is greater than the preset storage time threshold, so as to avoid the problem of further write amplification caused by obtaining a smaller target data processing request. Specifically, obtaining the target data processing request from the request storage unit and sending the target data processing request to the request processing queue includes:

[0118] Determining the target data processing request and the target time corresponding to the target data processing request from the request storage unit;

[0119] Calculating a time parameter between the target time and the creation time, and obtaining the target data processing request when the time parameter is greater than a preset storage time threshold;

[0120] The target data processing request is sent to the request processing queue.

[0121] The target time may be understood as the time when the initial data processing requests are merged for the first time to obtain the target data processing request, or the earliest receiving time among the receiving times of multiple initial data processing requests that are merged to obtain the target data processing request.

[0122] The time parameter can be understood as the time difference between the target time and the current time. The preset storage time threshold can be set according to the actual application scenario, and this specification does not make specific restrictions on this. For example, the preset storage time threshold can be 1 minute, 10 seconds, etc.

[0123] Using the above example, when the server determines that there is no batch (merged IO request) to be written to all partition queues, it determines whether the local batch corresponding to the partition queue meets the write condition, that is, determines the receiving time of each IO request in the batch, and selects the earliest time from the receiving time. The time difference between the time and the current time is calculated. If the time difference is greater than the preset storage time threshold (such as 1 minute), the merged IO request is obtained from the local batch and stored in the partition queue, thereby avoiding the problem of data processing requests stored in the request storage unit being lost due to the low number of initial data processing requests, and avoiding the problem of write amplification caused by obtaining smaller target data processing requests.

[0124] In one embodiment provided in this specification, after storing the target data processing request based on the request processing queue, the method further includes:

[0125] The request storage unit storing the target data processing request is cleared.

[0126] Specifically, after completing the storage of the target data processing request, in order to save cache resources, the request storage unit storing the target data processing request will be cleared. For example, after obtaining a writable batch and initiating a write IO request to sequentially write to the disk, the server will recycle the batch into the memory pool.

[0127] The request processing method provided in this specification stores the initial data processing request in the request storage unit corresponding to the request processing queue, and merges the initial data processing request to obtain the target data processing request, and when the current status information of the request storage unit meets the preset storage condition, the target data processing request is stored through the request processing queue, thereby avoiding the write amplification phenomenon caused by a large amount of unused storage space in the cache, and further saving storage resources.

[0128] In conjunction with FIG5, the request processing method provided in this specification is further described by taking the application of the request processing method provided in this specification in the scenario of storing messages in batches in a partition queue through and merging as an example. Among them, FIG5 shows a processing flow chart of a request processing method provided in an embodiment of this specification, which includes Figure 5A and Figure 5B The request processing method provided in this specification is composed of two core subsystems: Commit Buffer and Accumulate Service. Commit Buffer is responsible for: partition parallel computing. The Commit Buffer process specifically includes the following steps.

[0129] Step 502: Receive an IO request.

[0130] Specifically, the server receives an IO request sent by a user.

[0131] Step 504: Determine queue partitions.

[0132] Specifically, the server selects a partition queue for the IO request.

[0133] Step 506: Determine whether a local batch exists.

[0134] Specifically, the server determines whether there is a local batch in the partition queue. If so, step 514 is executed; if not, step 508 is executed.

[0135] Step 508: Determine the memory pool management module.

[0136] Specifically, when the server determines that there is no local batch in the partition queue, it determines the memory pool management module configured by the server itself.

[0137] Step 510: Obtain a memory pool.

[0138] Specifically, the server pre-allocates an area from the memory pool through the memory pool management module.

[0139] In actual applications, in order to quickly allocate the corresponding local batch to the partition queue, the memory pool management module will pre-allocate a storage area for the partition queue from the memory. When a local batch application is received later, a sub-area of ​​the appropriate size can be allocated from the storage area for the partition queue as the local batch.

[0140] Step 512: Apply for batch.

[0141] Specifically, the server applies for a new local batch from the memory pool management module according to the identification information of the partition queue and the size of the IO request.

[0142] After receiving the application, the memory pool management module can allocate an area large enough to accommodate the IO request as a local batch for the partition queue applying for a new local batch from the memory area pre-allocated for all partition queues.

[0143] Step 514: Perform pre-calculation.

[0144] Specifically, the server pre-calculates the received IO request. The pre-calculation includes but is not limited to data local integrity verification, security verification, etc., which are not specifically limited in this specification. Moreover, the pre-calculation can be implemented in any way, which is not specifically limited in this specification.

[0145] Step 516: Serialization is performed.

[0146] Specifically, the server performs serialization processing on the received IO request, wherein the serialization processing can be implemented in any manner, and this specification does not impose any specific limitation on this.

[0147] Step 518: Merge the request.

[0148] Specifically, the server performs parallel computing in local batches and merges IO requests in parallel.

[0149] The parallel merging may be implemented in any manner that can achieve request merging, and this specification does not impose any specific limitation on this.

[0150] For example, all IO requests currently stored in the local batch are packaged and processed, and when a new request is written into the local batch, the new request can be repackaged with the historically packaged IO, thereby merging the IO requests in the local batch.

[0151] Alternatively, a logical address that needs to be operated in the IO request data storage module is determined, and a plurality of IO requests with consecutively connected logical addresses are merged into one request, thereby realizing request merging.

[0152] Step 520: FIFO entry.

[0153] Specifically, when the server determines that the local batch meets the write conditions, it sends the merged IO requests in the local batch to the FIFO queue.

[0154] Step 522: Restart executing step 502.

[0155] Specifically, after the server completes request merging and queuing, it will continue to execute the Commit Buffer process when receiving an IO request.

[0156] The Accumulate Service process specifically includes the following steps.

[0157] Step 524: Perform queue polling.

[0158] Specifically, the server loops through all partition queues.

[0159] Step 526: Determine the partition queue.

[0160] Specifically, the server detects each partition queue while looping through all partition queues.

[0161] Step 528: Determine whether a batch exists.

[0162] Specifically, the server determines whether there is a batch that needs to be written to disk in each partition queue. If so, step 534 is executed; if not, step 530 is executed.

[0163] Step 530: Determine whether the local batch meets the write condition.

[0164] Specifically, if the server determines that there is no batch to be written in the partition queue, it determines whether the local batch corresponding to the partition queue meets the writing condition. If so, step 532 is executed; if not, step 524 is executed.

[0165] The write condition may be satisfied by: the server determines the receiving time of each IO request in the batch, and selects the earliest time from the receiving time, calculates the time difference between the time and the current time, and determines that the local batch satisfies the write condition when the time difference is greater than a preset storage time threshold (such as 1 minute).

[0166] In actual applications, the local batch is not satisfied and the next partition queue is traversed.

[0167] Step 532: FIFO entry.

[0168] Specifically, when the server determines that the local batch meets the write condition, it obtains the merged IO request from the local batch and sends it to the FIFO queue (i.e., the partition queue). In other words, when the local batch meets the write condition, it pulls the local batch in the reverse direction and enters the FIFO queue.

[0169] Step 534: Get batch.

[0170] Specifically, the server obtains batches from the partition queue.

[0171] Step 536: Merge the request.

[0172] Specifically, the server will obtain batches (merged IO requests) from the partition queue for merge processing.

[0173] Step 538: Write to disk.

[0174] Specifically, the server writes the merged batch to disk.

[0175] Step 540: Recycle the batch.

[0176] Specifically, after obtaining a writable batch and initiating a write IO request to sequentially write to the disk, the server will recycle the batch into the memory pool.

[0177] Step 542: Restart executing step 524.

[0178] Specifically, after the server finishes writing the batch to disk, it will continue to poll the queue and continue to execute the Accumulate Service process.

[0179] The request processing method provided in this specification can realize functions such as partitioned parallel computing, pre-merging IO requests, and batch storage through the execution process of Commit Buffer and the execution process of AccumulateService; specifically, the request processing method provided in this specification builds a partitioned cache queue through a memory pool and a local batch to realize high-performance parallel computing. Through pre-computation of the partitioned cache queue, the benefits of parallel computing are obtained while not occupying disk IO resources, thus realizing high-performance parallel merging. And through the FIFO queue, the Accumulate Service obtains the merged IO requests in a single thread, ensuring sequential writes while batch storage significantly reduces write amplification. This greatly reduces IOPS while significantly reducing the phenomenon of write amplification, which not only saves IO bandwidth, but also significantly improves the performance of message storage.

[0180] Corresponding to the above method embodiment, this specification also provides a request processing device embodiment, Figure 6 FIG. 1 shows a schematic diagram of a request processing device provided by an embodiment of the present specification. Figure 6 As shown, the device comprises:

[0181] A determination module 602 is configured to determine a corresponding request processing queue for the received initial data processing request, and determine a request storage unit corresponding to the request processing queue;

[0182] A merging module 604 is configured to store the initial data processing request in the request storage unit, and merge the initial data processing request in the request storage unit to obtain a target data processing request;

[0183] The sending queue module 606 is configured to send the target data processing request to the request processing queue when it is determined that the current state information of the request storage unit meets the preset storage condition;

[0184] The storage module 608 is configured to store the target data processing request based on the request processing queue.

[0185] Optionally, the determining module 602 is further configured to:

[0186] Determining a request type of the received initial data processing request, and determining a queue type corresponding to the request type;

[0187] Determine at least two request processing queues corresponding to the queue type, and respectively determine current status information of the at least two request processing queues;

[0188] Based on the current state information, a corresponding request processing queue is determined for the initial data processing request from the at least two request processing queues.

[0189] Optionally, the determining module 602 is further configured to:

[0190] After determining that the request processing queue does not have a corresponding request storage unit, or

[0191] When the request storage unit corresponding to the request processing queue does not meet the request storage condition, a request is acquired based on the attribute information of the request processing queue and the attribute information generating unit of the initial data processing request;

[0192] sending the unit acquisition request to a unit allocation module;

[0193] The unit allocation module obtains the request storage unit allocated to the request processing queue from the preset to-be-allocated module in response to the unit acquisition request.

[0194] Optionally, the merging module 604 is further configured to:

[0195] Preprocessing the initial data processing request to obtain a processed initial data processing request;

[0196] The processed initial data processing request is stored in the request storage unit.

[0197] Optionally, the merging module 604 is further configured to:

[0198] When it is determined that at least two initial data processing requests are stored in the request storage unit, the at least two initial data processing requests are merged to obtain a target data processing request.

[0199] Optionally, the storage module 608 is further configured to:

[0200] A target data processing request is obtained from the request processing queue, and the target data processing request is stored in a request storage module.

[0201] Optionally, the request processing device further includes an acquisition module configured to:

[0202] In a case where it is determined that there is no target data processing request in the request processing queue, determining the request storage unit corresponding to the request processing queue;

[0203] The target data processing request is obtained from the request storage unit, and the target data processing request is sent to the request processing queue.

[0204] Optionally, the request processing queues include at least two;

[0205] Accordingly, the storage module 608 is further configured to:

[0206] When it is determined that the target data processing request exists in at least two request processing queues, the target data processing request is obtained from the at least two request processing queues.

[0207] Optionally, the acquisition module is configured to:

[0208] In a case where it is determined that there is no target data processing request in at least two request processing queues, respectively determining a request storage unit corresponding to each request processing queue;

[0209] The target data processing request is obtained from the request storage unit, and the target data processing request is sent to the request processing queue.

[0210] Optionally, the acquisition module is configured to:

[0211] Determining the target data processing request and the target time corresponding to the target data processing request from the request storage unit;

[0212] Calculating a time parameter between the target time and the creation time, and obtaining the target data processing request when the time parameter is greater than a preset storage time threshold;

[0213] The target data processing request is sent to the request processing queue.

[0214] Optionally, the request processing device further includes a clearing module configured to:

[0215] The request storage unit storing the target data processing request is cleared.

[0216] The request processing device provided in this specification stores the initial data processing request in the request storage unit corresponding to the request processing queue, and merges the initial data processing request to obtain the target data processing request, and when the current status information of the request storage unit meets the preset storage condition, the target data processing request is stored through the request processing queue, thereby avoiding the write amplification phenomenon caused by a large amount of unused storage space in the cache, and further saving storage resources.

[0217] The above is a schematic scheme of a request processing device of this embodiment. It should be noted that the technical scheme of the request processing device and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the request processing device can be found in the description of the technical scheme of the request processing method described above.

[0218] Figure 7 The block diagram of a computing device 700 according to an embodiment of the present specification is shown. The components of the computing device 700 include but are not limited to a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and the database 750 is used to store data.

[0219] The computing device 700 also includes an access device 740 that enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a World Wide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0220] In one embodiment of the present specification, the above components of the computing device 700 and Figure 7 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 7 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0221] The computing device 700 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. The computing device 700 may also be a mobile or stationary server.

[0222] The processor 720 is used to execute the following computer executable instructions, which, when executed by the processor 720, implement the steps of the above-mentioned request processing method.

[0223] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the computing device can be found in the description of the technical scheme of the request processing method described above.

[0224] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which can implement the steps of the above-mentioned request processing method when executed by a processor.

[0225] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the storage medium can be found in the description of the technical scheme of the request processing method described above.

[0226] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned request processing method.

[0227] The above is a schematic scheme of a computer program of this embodiment. It should be noted that the technical scheme of the computer program and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the computer program can be found in the description of the technical scheme of the request processing method described above.

[0228] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0229] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0230] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0231] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0232] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A request processing method, comprising: Determine a corresponding request processing queue for the received initial data processing request, and determine a request storage unit corresponding to the request processing queue; storing the initial data processing request in the request storage unit, and merging the initial data processing requests in the request storage unit to obtain a target data processing request; When it is determined that the current state information of the request storage unit meets the preset storage condition, sending the target data processing request to the request processing queue; Obtain a target data processing request from the request processing queue, and store the target data processing request in a request storage module, wherein the request processing queue includes at least two, and obtaining the target data processing request from the request processing queue includes: upon determining that there are target data processing requests in at least two request processing queues, obtaining the target data processing request from the at least two request processing queues.

2. The request processing method according to claim 1, wherein determining a corresponding request processing queue for the received initial data processing request comprises: Determining a request type of the received initial data processing request, and determining a queue type corresponding to the request type; Determine at least two request processing queues corresponding to the queue type, and respectively determine current status information of the at least two request processing queues; Based on the current state information, a corresponding request processing queue is determined for the initial data processing request from the at least two request processing queues.

3. The request processing method according to claim 1, wherein the step of determining the request storage unit corresponding to the request processing queue comprises: After determining that the request processing queue does not have a corresponding request storage unit, or When the request storage unit corresponding to the request processing queue does not meet the request storage condition, a request is acquired based on the attribute information of the request processing queue and the attribute information generating unit of the initial data processing request; sending the unit acquisition request to a unit allocation module; The unit allocation module obtains the request storage unit allocated to the request processing queue from the preset to-be-allocated module in response to the unit acquisition request.

4. The request processing method according to claim 1, wherein storing the initial data processing request in the request storage unit comprises: Preprocessing the initial data processing request to obtain a processed initial data processing request; The processed initial data processing request is stored in the request storage unit.

5. The request processing method according to claim 1, wherein the merging process of the initial data processing requests in the request storage unit to obtain the target data processing request comprises: When it is determined that at least two initial data processing requests are stored in the request storage unit, the at least two initial data processing requests are merged to obtain a target data processing request.

6. The request processing method according to claim 1, before obtaining the target data processing request from the request processing queue, further comprising: In the case of determining that there is no target data processing request in the request processing queue, determining the request storage unit corresponding to the request processing queue; The target data processing request is obtained from the request storage unit, and the target data processing request is sent to the request processing queue.

7. The request processing method according to claim 1, before obtaining the target data processing request from the request processing queue, further comprising: In a case where it is determined that there is no target data processing request in at least two request processing queues, respectively determining a request storage unit corresponding to each request processing queue; The target data processing request is obtained from the request storage unit, and the target data processing request is sent to the request processing queue.

8. The request processing method according to any one of claims 6 or 7, wherein obtaining the target data processing request from the request storage unit and sending the target data processing request to the request processing queue comprises: Determining the target data processing request and the target time corresponding to the target data processing request from the request storage unit; Calculate a time parameter between the target time and the creation time, and obtain the target data processing request when the time parameter is greater than a preset storage time threshold; The target data processing request is sent to the request processing queue.

9. The request processing method according to claim 1, after obtaining the target data processing request from the request processing queue and storing the target data processing request in the request storage module, further comprising: The request storage unit storing the target data processing request is cleared.

10. A request processing device, comprising: a determination module configured to determine a corresponding request processing queue for the received initial data processing request, and determine a request storage unit corresponding to the request processing queue; a merging module, configured to store the initial data processing request in the request storage unit, and perform merging processing on the initial data processing request in the request storage unit to obtain a target data processing request; a sending queue module, configured to send the target data processing request to the request processing queue when determining that the current state information of the request storage unit meets a preset storage condition; A storage module is configured to obtain a target data processing request from the request processing queue and store the target data processing request in the request storage module, wherein the request processing queue includes at least two, and obtaining the target data processing request from the request processing queue includes: upon determining that there are target data processing requests in at least two request processing queues, obtaining the target data processing request from the at least two request processing queues.

11. A computing device comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the request processing method described in any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the request processing method according to any one of claims 1 to 9.

Images