Request processing method, apparatus and electronic device

Abstract

The application provides a request processing method and device and electronic equipment, receiving a data read-write request sent by a target device, and then determining a request type of the data read-write request, the request type including an internal request event and a service request event; if the request type of the data read-write request is the internal request event, the data read-write request is sent to a first read-write queue, and the data read-write request in the first read-write queue is processed based on a request processing performance index corresponding to the service request event in a specified time period. This method can put requests of different request types into different read-write queues to distinguish and isolate requests of different request types and reduce the influence between requests of different request types. Meanwhile, the request processing speed of the internal request event is dynamically adjusted according to the request processing performance index of the service request event, thereby reducing the influence of the internal request event on the service request event and ensuring the processing performance of the service request event.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a request processing method, apparatus, and electronic device. Background Technology

[0002] In cloud gaming, to facilitate the management of game updates, multiple cloud gaming instances need to access the same storage requirement, which is typically achieved using distributed storage. Distributed storage usually stores data in multiple replicas, meaning that a data shard is stored on multiple shard servers.

[0003] In related technologies, when the main thread of a sharding server receives an IO (Input / Output) request, it places the IO request into a read / write queue so that the sharding server processes the IO requests in the queue sequentially. IO requests are typically divided into business IO and internal IO. Internal IO refers to internal read / write requests generated when expanding storage or migrating and synchronizing replicas due to disk or node failures. Business IO refers to data read / write requests that require processing business logic. If the read / write queue contains a large number of unprocessed IO requests, internal IO can easily overwhelm business IO, leading to poor business IO read / write performance and thus affecting the gaming experience. Summary of the Invention

[0004] The purpose of this invention is to provide a request processing method, apparatus, and electronic device to reduce the impact of internal I / O on the read and write performance of business I / O.

[0005] In a first aspect, the present invention provides a request processing method, the method comprising: receiving a data read / write request sent by a target device; determining the request type of the data read / write request based on the data read / write request; wherein the request type includes: internal request event and business request event; if the request type of the data read / write request is an internal request event, sending the data read / write request to a first read / write queue, and processing the data read / write request in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period, thereby obtaining a processing result.

[0006] Secondly, the present invention provides a request processing apparatus, comprising: a request receiving module for receiving data read / write requests sent by a target device; a type determining module for determining the request type of the data read / write request based on the data read / write request; wherein the request type includes: internal request events and business request events; and a request processing module for sending the data read / write request to a first read / write queue if the request type of the data read / write request is an internal request event, and processing the data read / write requests in the first read / write queue based on the request processing performance indicators corresponding to the business request events within a specified time period to obtain a processing result.

[0007] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the above-described request processing method.

[0008] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions that, when invoked and executed by a processor, cause the processor to implement the above-described request processing method.

[0009] The embodiments of the present invention bring the following beneficial effects:

[0010] This invention provides a request processing method, apparatus, and electronic device. First, a sharding server receives data read / write requests sent by a target device. Then, based on the data read / write requests, the request type is determined, including internal request events and business request events. If the request type is an internal request event, the request is sent to a first read / write queue. Based on the request processing performance metrics corresponding to business request events within a specified time period, the data read / write requests in the first read / write queue are processed to obtain the processing result. This method can place requests of different types into different read / write queues to distinguish and isolate requests of different types, reducing the impact between requests of different types. Simultaneously, this method dynamically adjusts the request processing speed of internal request events based on the request processing performance metrics of business request events, thereby reducing the impact of internal request events on business request events and ensuring the processing performance of business request events.

[0011] Other features and advantages of the invention will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0012] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0013] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0014] Figure 1A diagram illustrating the relationship between the cloud gaming system and the MFS distributed storage provided in this embodiment of the invention;

[0015] Figure 2 A flowchart of a request processing method provided in an embodiment of the present invention;

[0016] Figure 3 A flowchart of another request processing method provided in an embodiment of the present invention;

[0017] Figure 4 This is a schematic diagram illustrating how a sharding server processes I / O requests according to an embodiment of the present invention.

[0018] Figure 5 This is a schematic diagram of the structure of a request processing device provided in an embodiment of the present invention;

[0019] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0022] In cloud gaming, to facilitate the management of game updates, multiple cloud gaming instances need to share the same storage requirements, which are typically achieved using distributed storage. Distributed storage usually stores data in multiple replicas; that is, a data shard is stored across multiple shard servers. For example... Figure 1 The diagram shows the relationship between the cloud gaming system and the distributed storage system using MFS (Moose File System).

[0023] Figure 1The cloud gaming system uses virtual machines as instances, and the disk uses the qcow2 file from QEMU. The MFS storage client presents a view consistent with the local file system through fuse, and this qcow2 disk file is stored within MFS. A file is split into multiple chunks (also called data shards) at the MFS level and stored on a chunkserver. Within the virtual machine, cloud gaming I / O (which is equivalent to data reading and writing within the game, such as loading the game map) is sent to the disk, converted by the virtual machine into the corresponding qcow2 file, and then enters MFS. MFS finds the chunk containing the I / O range and initiates a read request to the corresponding chunkserver; this is the path of the game I / O.

[0024] As a distributed storage system, multiple replicas are typically stored for high availability and performance reasons, such as... Figure 1 A chunk of data is stored across multiple chunkservers. When expanding storage capacity, in order to maintain capacity balance among chunkservers, or to keep the number of replicas within a set limit in the event of disk or node failures, internal I / O traffic such as replica migration and replica synchronization will be generated.

[0025] For example, when a distributed storage file has two replicas, all data chunks are stored twice. These data chunks ultimately need to be stored on disk. When some disks fail or a chunkserver crashes, only a single replica of the data chunk remains available. To ensure high availability, the data chunk needs to be copied to another disk or chunkserver. This is the internal I / O generated by the storage itself. Similarly, when expanding storage by adding new chunkservers or disks, to utilize the new disks and balance space utilization, data from other disks needs to be synchronized to the new disks, which generates a large amount of internal I / O.

[0026] The aforementioned internal I / O can be categorized differently based on their function; for example, I / O caused by capacity expansion is called balancing I / O, and synchronization due to missing replicas is called repair I / O. However, a very clear distinction is not necessary here, as they are all internal I / O generated by the storage itself, which is different from business I / O actively initiated by upper-layer business processes.

[0027] In related technologies, when the main thread of a sharding server receives an IO request, it does not distinguish between internal IO and business IO, and uniformly puts the IO request into a read / write queue so that the sharding server processes the IO requests in the read / write queue sequentially. In this approach, business IO requests and internal IO requests are not differentiated or isolated, leading to mutual interference; furthermore, it is impossible to observe and distinguish between business traffic and internal IO traffic; simultaneously, when storage is expanded or some nodes fail, triggering a large number of balancing operations, if the business IO pressure is high at this time, the balancing IO can easily squeeze out business IO, resulting in poor business IO performance and thus affecting the gaming experience.

[0028] To address the aforementioned problems, embodiments of the present invention provide a request processing method, apparatus, and electronic device. This technology can be applied to data read / write request processing scenarios. To facilitate understanding of the embodiments of the present invention, a request processing method disclosed in this embodiment will first be described in detail. This method is applied to a sharded server (also referred to as a server-side component) in a distributed storage system, such as... Figure 2 As shown, the method includes the following specific steps:

[0029] Step S202: Receive data read / write requests sent by the target device.

[0030] In practical implementation, the target device sending data read / write requests can be collectively referred to as the client. This target device can be an internal service management device or an external terminal device. The internal service management device is typically the Master server in a distributed storage system. The Master server's main function is to store metadata information and manage the multiple shard servers within the distributed system. The external terminal device can be a mobile terminal (e.g., a mobile phone, tablet computer), or a computer.

[0031] The aforementioned data read / write requests can be requests to read data from data shards on a sharding server, such as a request to load a game map; or they can be requests to write data to data shards on a sharding server, such as a request to record player rankings. The specific type of data read / write request can be determined based on user needs and is not specifically limited here.

[0032] Step S204: Based on the data read / write request, determine the request type of the data read / write request; wherein, the request type includes: internal request event and business request event.

[0033] In practical implementation, since internal request events (equivalent to the aforementioned internal I / O) and business request events (equivalent to the aforementioned business I / O) have different request characteristics, the request type of a data read / write request can be distinguished as either an internal request event or a business request event based on the request characteristics. These request characteristics can include the request source and / or the request size. Typically, internal request events are sent by internal service management devices and have a larger request size; business request events are sent by external terminal devices and have a smaller request size.

[0034] In practical implementation, when expanding storage capacity, to maintain capacity balance among sharded servers, or in the event of disk or node failures, and to keep the number of replicas within a set limit, internal request events such as replica migration and replica synchronization will be generated. These business request events are typically user-initiated requests, such as game map loading requests sent by players through their terminal devices. Therefore, in games, the processing performance of these business request events can impact the player's gaming experience.

[0035] Step S206: If the request type of the data read / write request is an internal request event, the data read / write request is sent to the first read / write queue, and the data read / write request in the first read / write queue is processed based on the request processing performance index corresponding to the business request event within the specified time period to obtain the processing result.

[0036] The first read / write queue mentioned above only contains data read / write requests with the request type of internal request events. The processing speed of these requests is dynamically determined based on the performance metrics of the business request events within a specified time period. Typically, when the performance metrics of the business request events decrease within a specified time period, the processing speed of data read requests in the first read queue is limited to improve the overall performance of the business request events. These performance metrics are related to request load, request processing latency, and request throughput. The specific time period can be set according to development needs; for example, it could be 5 minutes or 10 minutes prior to the current time.

[0037] Specifically, data read / write requests of the request type "business request event" can be placed in the second read / write queue, thereby placing data read / write requests of different request types into different read queues. This isolates data read / write requests of different request types and prevents them from interfering with each other.

[0038] This invention provides a request processing method that first receives data read / write requests from a target device via a sharding server; then, based on the data read / write requests, determines the request type, which includes internal request events and business request events; if the request type is an internal request event, the data read / write request is sent to a first read / write queue, and the data read / write requests in the first read / write queue are processed based on the request processing performance indicators corresponding to business request events within a specified time period to obtain the processing result. This method can place requests of different request types into different read / write queues to distinguish and isolate requests of different request types, reducing the impact between requests of different request types; at the same time, this method dynamically adjusts the request processing speed of internal request events according to the request processing performance indicators of business request events, thereby reducing the impact of internal request events on business request events and ensuring the processing performance of business request events.

[0039] This invention also provides another request processing method, which is implemented based on the above embodiments. This method focuses on describing the specific process of determining the request type of a data read / write request based on the data read / write request (specifically implemented through step S304 below); and the specific process of sending the data read / write request to a first read / write queue if the request type is an internal request event, and processing the data read / write requests in the first read / write queue based on the request processing performance indicators corresponding to the business request events within a specified time period to obtain the processing result (specifically implemented through steps S314-S316 below); such as Figure 3 As shown, the method includes the following specific steps:

[0040] Step S302: Receive data read / write request sent by the target device.

[0041] Step S304: Determine the request type of the data read / write request based on the request source and size of the data read / write request; wherein, the request type includes: internal request event and business request event.

[0042] In practical implementation, the source of the aforementioned requests refers to the device sending the data read / write requests. Internal request events are sent by internal service management devices, and the size of the requests corresponding to these internal request events is a specified size, which can be determined based on development needs; for example, the specified size could be 64MB. Business request events are sent by external terminal devices, and the size of the requests corresponding to these business request events is less than a preset threshold, which can be set based on development needs; for example, the preset threshold could be 4MB.

[0043] In practical applications, internal request events typically correspond to requests of the entire shard size (64MB) and originate from the master server; while business request events usually correspond to requests no larger than 4MB, with requests exceeding 4MB being split into multiple requests. Therefore, by combining the request size and the request source, it is generally possible to determine whether a data read / write request is a business request event or an internal request event.

[0044] Step S306: Calculate the request processing latency, request processing load, and request throughput corresponding to the above data read and write requests to obtain the request processing performance indicators of the data read and write requests.

[0045] In practical implementation, based on the time of receiving data read / write requests and the data that needs to be processed, the processing latency, request load, and request throughput corresponding to each data read / write request can be statistically determined. Based on these parameters, the request processing performance metrics for data read / write requests can be determined.

[0046] Step S308: Determine whether the request type of the above data read / write request is a business request event; if yes, proceed to step S310; if not, proceed to step S314.

[0047] In practical implementation, before processing data read and write requests, it is necessary to determine whether the request type is a business request event or an internal request event, so as to send requests of different request types to different read and write queues, thereby distinguishing and isolating different requests.

[0048] Step S310: Send the above data read / write request to the second read / write queue.

[0049] Step S312: According to the data reading rules corresponding to the second read / write queue, retrieve the data read / write request from the second read / write queue, process the data read / write request, and return the processing result to the target device.

[0050] The above data read / write rules can be set according to R&D needs. For example, data read / write requests in the second read / write queue can be read according to the first-in-first-out principle, or data read / write requests in the second read / write queue can be read according to a preset priority.

[0051] In practical implementation, each data read / write request carries parameters such as the size of the request, the fragment identifier of the target data fragment containing the accessed data, and the start and end positions of the accessed data within the target data fragment. The fragment identifier indicates the target data fragment among multiple data fragments contained in the fragment server; this fragment server is one of multiple fragment servers in the distributed storage system. For example, in MFS distributed storage, fragment identifiers (also called chunk IDs) are divided using a fixed 64MB partition. The target device queries the master to determine which fragment server contains the target data fragment corresponding to the fragment identifier, and then sends the data read / write request from the target device to that fragment server.

[0052] Based on the above description, the steps for processing data read / write requests retrieved from the second read / write queue can be implemented through the following steps 10-12:

[0053] Step 10: Determine the target data fragment based on the fragment identifier indicated by the data read / write request.

[0054] The aforementioned fragment identifier is unique and can uniquely identify the identity of a data fragment.

[0055] Step 11: Based on the start and end positions indicated by the data read / write request, read the target data from the target data fragment or write the target data into the target data fragment to obtain the request processing result.

[0056] In practice, a data read / write request can be either a write request or a read request. If the data read / write request is a read request, the target data will be read from the target data segment according to the start and end positions indicated by the data read / write request. If the data read / write request is a write request, the write request will carry the target data and then write the target data into the target data segment according to the start and end positions indicated by the data read / write request.

[0057] Step 12: Return the above request processing result to the target device.

[0058] Step S314: Send the above data read / write requests to the first read / write queue, and adjust the processing speed of the data read / write requests in the first read / write queue according to the request processing performance indicators corresponding to the business request events within the specified time period.

[0059] In practice, step S314 can be implemented through steps 20-23 as follows:

[0060] Step 20: Send the data read / write request to the first read / write queue.

[0061] Step 21: If the performance index of the request processing corresponding to the business request event drops for the first time, the processing concurrency of data read and write requests in the first read and write queue will be reduced.

[0062] Step 22: If the processing concurrency drops to a specified value and the request processing performance index corresponding to the business request event decreases, the processing throughput of data read and write requests in the first read and write queue and the number of input / output operations per second (IPOS) will be limited.

[0063] Step 23: If the performance metrics of the request processing corresponding to the business request event increase, the processing throughput, IPOS, and processing concurrency of data read and write requests in the first read and write queue will be increased.

[0064] To facilitate understanding of steps 20-23 above, we will use internal request event data read / write requests as internal IO and business request event data read / write requests as business IO as an example. For internal IO rate limiting, IO performance metrics such as business IO load (equivalent to the aforementioned request processing load), IO latency (equivalent to the aforementioned request processing delay duration), and throughput (equivalent to the aforementioned request processing performance metrics) are collected over a period of time as the basis for rate limiting. Initially, internal IO will have a maximum concurrency level set. When business IO performance metrics begin to decline, the internal IO pipeline will limit the concurrency level. When the internal IO concurrency level is 1 and the business IO performance metrics are still declining, then throughput and IOPS will be limited, and these limits will be further increased as business IO performance continues to decline. When business IO performance metrics begin to improve, internal IO throughput and IOPS will be gradually reduced until concurrency is increased. Therefore, the internal IO speed is always in a dynamic equilibrium process until it reaches a relative balance with business IO, minimizing the impact on business IO while ensuring the completion of internal IO.

[0065] The above method dynamically limits the rate of internal I / O, minimizing its impact on business I / O and ensuring a smooth gaming experience. At the same time, it improves internal I / O performance when business I / O traffic is low, speeds up data balancing and synchronization, and ensures storage stability.

[0066] Step S316: Process the data read / write requests in the first read / write queue based on the adjusted processing speed, obtain the processing result, and return the processing result to the target device.

[0067] In the specific implementation, according to the adjusted processing speed, data read / write requests are retrieved from the first read / write queue. Then, based on the fragment identifier indicated by the retrieved data read / write request, the target data fragment is determined. Next, according to the start and end positions indicated by the data read / write request, the target data is read from the target data fragment or written to the target data fragment to obtain the processing result. Finally, the processing result is returned to the target device.

[0068] In practical applications, the aforementioned sharding server typically includes a network pipeline layer, an I / O distribution layer, a business I / O pipeline layer, an internal I / O pipeline layer, and a backend I / O pipeline layer, such as... Figure 4 The diagram shown is a schematic of a sharding server processing I / O requests according to an embodiment of the present invention. Figure 4 The IO request in the middle is equivalent to the data read and write request mentioned above. Figure 4 The client in this context is equivalent to the target device mentioned above. When the sharding server receives an I / O request from the client through the network pipeline layer, it parses the I / O request to obtain parsed data. This parsed data includes: the request size carried by the I / O request, the shard identifier of the target data shard where the accessed target data is located, the start and end positions of the accessed target data in the target data shard, the request source, and whether the I / O request is a read request or a write request, etc.

[0069] Then, the network pipeline layer sends the IO requests and parsed data to the IO distribution layer. The IO distribution layer analyzes the IO latency, IO load, and other factors of the current IO requests to obtain IO performance metrics. This IO distribution layer can also categorize IO requests into internal IO and business IO based on their source and size. The corresponding IO performance metrics for internal and business IO are then distributed to the first read / write queue in the internal IO pipeline layer, and business IO is distributed to the second read / write queue in the business IO pipeline layer. The business IO pipeline layer processes the business IO, while the internal IO pipeline layer dynamically adjusts its concurrency and limits the speed at which internal IO is sent to the backend IO pipeline layer based on the IO performance metrics of business IO over a period of time.

[0070] Figure 4 In this context, the backend refers to the disk, which is the final layer that actually completes the I / O data reading. This design is primarily for scalability, meaning only the last layer needs to know where the data is actually stored. For example, this actual data could be stored in a database, on a remote end, or used by the sharded server itself for forwarding, but currently it's stored on the disk. After the backend completes the reading, it returns the request processing result to the previous layer. This is a stack-based processing method, where processing is done layer by layer, and the result is finally sent to the client through the network pipeline layer.

[0071] The aforementioned request processing method can separate internal I / O from business I / O, apply different strategies to different types of I / O, and monitor I / O metrics such as traffic and latency for different I / O types. Simultaneously, this approach dynamically limits the rate of internal I / O to minimize its impact on business I / O, ensuring a smooth gaming experience. Furthermore, when business I / O traffic is low, it improves internal I / O performance, accelerates data balancing and synchronization, and guarantees the stability of distributed storage.

[0072] Compared with the above method embodiments, this embodiment of the invention also provides a request processing apparatus, such as... Figure 5 As shown, the device includes:

[0073] The request receiving module 50 is used to receive data read / write requests sent by the target device.

[0074] The type determination module 51 is used to determine the request type of the data read / write request based on the data read / write request; wherein the request type includes: internal request event and business request event.

[0075] The request processing module 52 is used to send the data read / write request to the first read / write queue if the request type of the data read / write request is an internal request event, and to process the data read / write request in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period, and obtain the processing result.

[0076] The aforementioned request processing device first receives data read / write requests sent by the target device through a sharding server. Then, based on the data read / write requests, it determines the request type, which includes internal request events and business request events. If the request type is an internal request event, the data read / write request is sent to a first read / write queue. Based on the request processing performance metrics corresponding to business request events within a specified time period, the device processes the data read / write requests in the first read / write queue to obtain the processing result. This method can place requests of different types into different read / write queues to differentiate and isolate requests of different types, reducing the impact between requests of different types. Simultaneously, this method dynamically adjusts the request processing speed of internal request events based on the request processing performance metrics of business request events, thereby reducing the impact of internal request events on business request events and ensuring the processing performance of business request events.

[0077] Specifically, the request processing module 52 is further configured to: if the request type of the data read / write request is a business request event, send the data read / write request to the second read / write queue; and retrieve the data read / write request from the second read / write queue according to the data reading rules corresponding to the second read / write queue, so as to process the data read / write request.

[0078] In specific implementation, the aforementioned data read / write request carries the size of the data read / write request, the fragment identifier of the target data fragment where the accessed target data is located, and the start and end positions of the accessed target data within the target data fragment; wherein, the fragment identifier is used to indicate the target data fragment among the multiple data fragments contained in the fragment server; the fragment server is one of the multiple fragment servers contained in the distributed storage system; the aforementioned request processing module 52 is further configured to: determine the target data fragment based on the fragment identifier indicated by the data read / write request; read the target data from the target data fragment or write the target data into the target data fragment according to the start and end positions indicated by the data read / write request, thereby obtaining the request processing result; and return the request processing result to the target device.

[0079] Furthermore, the aforementioned type determination module 51 is used to: determine the request type of the data read / write request based on the request source and size of the data read / write request; wherein, the internal request event is sent by the internal service management device, and the size of the request corresponding to the internal request event is a specified size; the business request event is sent by the external terminal device, and the size of the request corresponding to the internal request event is less than a preset threshold.

[0080] In a specific implementation, the above device also includes an index determination module, which is used to: after determining the request type of the data read and write request based on the data read and write request, to statistically analyze the request processing latency, request processing load and request throughput corresponding to the data read and write request, and obtain the request processing performance index of the data read and write request.

[0081] Furthermore, the aforementioned request processing module 52 is used to: adjust the processing speed of data read and write requests in the first read and write queue according to the request processing performance index corresponding to the business request event within a specified time period; process the data read and write requests in the first read and write queue based on the adjusted processing speed, obtain the processing result, and return the processing result to the target device.

[0082] In practical applications, the aforementioned request processing module 52 is further configured to: if the request processing performance index corresponding to the business request event initially decreases, reduce the processing concurrency of data read / write requests in the first read / write queue; if the processing concurrency drops to a specified value and the request processing performance index corresponding to the business request event decreases, limit the processing throughput and IPOS of data read / write requests in the first read / write queue; if the request processing performance index corresponding to the business request event increases, increase the processing throughput, IPOS, and processing concurrency of data read / write requests in the first read / write queue.

[0083] The request processing apparatus provided in this embodiment of the invention has the same implementation principle and technical effects as the request processing method embodiment. For the sake of brevity, any parts not mentioned in the apparatus embodiment can be referred to the corresponding content in the foregoing method embodiment.

[0084] This invention also provides an electronic device, such as... Figure 6 As shown, the electronic device includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, which executes the machine-executable instructions to implement the above-described request processing method.

[0085] Specifically, the above request processing method includes: receiving a data read / write request sent by the target device; determining the request type of the data read / write request based on the data read / write request; wherein the request type includes: internal request event and business request event; if the request type of the data read / write request is an internal request event, sending the data read / write request to the first read / write queue, and processing the data read / write request in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period to obtain the processing result.

[0086] The above request processing method can place requests of different request types into different read / write queues to distinguish and isolate requests of different request types, thereby reducing the impact between requests of different request types. At the same time, this method will dynamically adjust the request processing speed of internal request events based on the request processing performance indicators of business request events, thereby reducing the impact of internal request events on business request events and ensuring the processing performance of business request events.

[0087] In an optional embodiment, the method further includes: if the request type of the data read / write request is a business request event, sending the data read / write request to the second read / write queue; and retrieving the data read / write request from the second read / write queue according to the data reading rules corresponding to the second read / write queue, so as to process the data read / write request.

[0088] In an optional embodiment, the data read / write request carries the size of the data read / write request, the fragment identifier of the target data fragment where the accessed target data is located, and the start and end positions of the accessed target data within the target data fragment; wherein, the fragment identifier is used to indicate the target data fragment among the multiple data fragments contained in the fragment server; the fragment server is one of the multiple fragment servers contained in the distributed storage system; the steps of processing the data read / write request include: determining the target data fragment based on the fragment identifier indicated by the data read / write request; reading the target data from the target data fragment or writing the target data into the target data fragment according to the start and end positions indicated by the data read / write request to obtain the request processing result; and returning the request processing result to the target device.

[0089] In an optional embodiment, the step of determining the request type of a data read / write request based on the data read / write request includes: determining the request type of the data read / write request according to the request source and size of the data read / write request; wherein, the internal request event is sent by the internal service management device, and the size of the request corresponding to the internal request event is a specified size; the business request event is sent by the external terminal device, and the size of the request corresponding to the business request event is less than a preset threshold.

[0090] In an optional embodiment, after the step of determining the request type of the data read / write request based on the data read / write request, the method further includes: statistically analyzing the request processing latency, request processing load, and request throughput corresponding to the data read / write request to obtain the request processing performance index of the data read / write request.

[0091] In an optional embodiment, the step of processing data read / write requests in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period to obtain the processing result includes: adjusting the processing speed of data read / write requests in the first read / write queue according to the request processing performance index corresponding to the business request event within the specified time period; processing the data read / write requests in the first read / write queue based on the adjusted processing speed to obtain the processing result, and returning the processing result to the target device.

[0092] In an optional embodiment, the step of adjusting the processing speed of data read / write requests in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period includes: if the request processing performance index corresponding to the business request event initially decreases, the processing concurrency of data read / write requests in the first read / write queue will be reduced; if the processing concurrency drops to a specified value and the request processing performance index corresponding to the business request event decreases, the processing throughput and number of input / output operations per second (IPOS) of data read / write requests in the first read / write queue will be limited; if the request processing performance index corresponding to the business request event increases, the processing throughput, IPOS, and processing concurrency of data read / write requests in the first read / write queue will be increased.

[0093] Furthermore, Figure 6 The electronic device shown also includes a bus 102 and a communication interface 103, with the processor 101, the communication interface 103 and the memory 100 connected via the bus 102.

[0094] The memory 100 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0095] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. Processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 100, and processor 101 reads information from memory 100 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0096] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned request processing method. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0097] Specifically, the above request processing method includes: receiving a data read / write request sent by the target device; determining the request type of the data read / write request based on the data read / write request; wherein the request type includes: internal request event and business request event; if the request type of the data read / write request is an internal request event, sending the data read / write request to the first read / write queue, and processing the data read / write request in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period to obtain the processing result.

[0098] The above request processing method can place requests of different request types into different read / write queues to distinguish and isolate requests of different request types, thereby reducing the impact between requests of different request types. At the same time, this method will dynamically adjust the request processing speed of internal request events based on the request processing performance indicators of business request events, thereby reducing the impact of internal request events on business request events and ensuring the processing performance of business request events.

[0099] In an optional embodiment, the method further includes: if the request type of the data read / write request is a business request event, sending the data read / write request to the second read / write queue; and retrieving the data read / write request from the second read / write queue according to the data reading rules corresponding to the second read / write queue, so as to process the data read / write request.

[0100] In an optional embodiment, the data read / write request carries the size of the data read / write request, the fragment identifier of the target data fragment where the accessed target data is located, and the start and end positions of the accessed target data within the target data fragment; wherein, the fragment identifier is used to indicate the target data fragment among the multiple data fragments contained in the fragment server; the fragment server is one of the multiple fragment servers contained in the distributed storage system; the steps of processing the data read / write request include: determining the target data fragment based on the fragment identifier indicated by the data read / write request; reading the target data from the target data fragment or writing the target data into the target data fragment according to the start and end positions indicated by the data read / write request to obtain the request processing result; and returning the request processing result to the target device.

[0101] In an optional embodiment, the step of determining the request type of a data read / write request based on the data read / write request includes: determining the request type of the data read / write request according to the request source and size of the data read / write request; wherein, the internal request event is sent by the internal service management device, and the size of the request corresponding to the internal request event is a specified size; the business request event is sent by the external terminal device, and the size of the request corresponding to the business request event is less than a preset threshold.

[0102] In an optional embodiment, after the step of determining the request type of the data read / write request based on the data read / write request, the method further includes: statistically analyzing the request processing latency, request processing load, and request throughput corresponding to the data read / write request to obtain the request processing performance index of the data read / write request.

[0103] In an optional embodiment, the step of processing data read / write requests in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period to obtain the processing result includes: adjusting the processing speed of data read / write requests in the first read / write queue according to the request processing performance index corresponding to the business request event within the specified time period; processing the data read / write requests in the first read / write queue based on the adjusted processing speed to obtain the processing result, and returning the processing result to the target device.

[0104] In an optional embodiment, the step of adjusting the processing speed of data read / write requests in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period includes: if the request processing performance index corresponding to the business request event initially decreases, the processing concurrency of data read / write requests in the first read / write queue will be reduced; if the processing concurrency drops to a specified value and the request processing performance index corresponding to the business request event decreases, the processing throughput and number of input / output operations per second (IPOS) of data read / write requests in the first read / write queue will be limited; if the request processing performance index corresponding to the business request event increases, the processing throughput, IPOS, and processing concurrency of data read / write requests in the first read / write queue will be increased.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal device, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0107] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A request processing method, characterized in that, The method includes: Receive data read / write requests sent by the target device; Based on the data read / write request, determine the request type of the data read / write request; wherein, the request type includes: internal request event and business request event; If the request type of the data read / write request is the internal request event, the data read / write request is sent to the first read / write queue, and the data read / write request in the first read / write queue is processed based on the request processing performance index corresponding to the business request event within a specified time period to obtain the processing result; wherein, the request processing performance index is related to the request processing load, the request processing latency, and the request throughput; The step of processing the data read / write requests in the first read / write queue based on the request processing performance metrics corresponding to the business request events within a specified time period to obtain the processing results includes: Based on the request processing performance metrics corresponding to the business request events within the specified time period, adjust the processing speed of the data read and write requests in the first read and write queue; The data read / write requests in the first read / write queue are processed based on the adjusted processing speed to obtain the processing result, and the processing result is returned to the target device.

2. The method according to claim 1, characterized in that, The method further includes: If the request type of the data read / write request is the business request event, the data read / write request is sent to the second read / write queue; According to the data reading rules corresponding to the second read / write queue, the data read / write request is retrieved from the second read / write queue to process the data read / write request.

3. The method according to claim 2, characterized in that, The data read / write request carries the size of the data read / write request, the shard identifier of the target data shard where the accessed target data is located, and the start and end positions of the accessed target data in the target data shard; wherein, the shard identifier is used to indicate the target data shard among the multiple data shards contained in the shard server; the shard server is one of the multiple shard servers contained in the distributed storage system; The steps for processing the data read / write request include: The target data fragment is determined based on the fragment identifier indicated by the data read / write request. Based on the start and end positions indicated by the data read / write request, the target data is read from the target data segment or written into the target data segment to obtain the request processing result; The request processing result is returned to the target device.

4. The method according to claim 1, characterized in that, The step of determining the request type of the data read / write request based on the data read / write request includes: The request type of the data read / write request is determined based on the request source and size of the data read / write request; The internal request event is sent by an internal service management device, and the size of the request corresponding to the internal request event is a specified size; the business request event is sent by an external terminal device, and the size of the request corresponding to the business request event is less than a preset threshold.

5. The method according to claim 1, characterized in that, After the step of determining the request type of the data read / write request based on the data read / write request, the method further includes: The request processing performance metrics for the data read / write requests are obtained by statistically analyzing the request processing latency, request processing load, and request throughput corresponding to the data read / write requests.

6. The method according to claim 1, characterized in that, The step of adjusting the processing speed of the data read / write requests in the first read / write queue according to the request processing performance indicators corresponding to the business request events within the specified time period includes: If the request processing performance index corresponding to the business request event drops for the first time, the processing concurrency of data read and write requests in the first read and write queue will be reduced. If the processing concurrency drops to a specified value and the request processing performance index corresponding to the business request event decreases, the processing throughput of data read and write requests in the first read and write queue and the number of input / output operations per second (IPOS) will be limited. If the request processing performance metrics corresponding to the business request event increase, the processing throughput, the IPOS, and the processing concurrency of data read and write requests in the first read and write queue will be increased.

7. A request processing apparatus, characterized in that, The device includes: The request receiving module is used to receive data read / write requests sent by the target device. The type determination module is used to determine the request type of the data read / write request based on the data read / write request; wherein, the request type includes: internal request event and business request event; The request processing module is configured to send the data read / write request to the first read / write queue if the request type of the data read / write request is the internal request event, and process the data read / write request in the first read / write queue based on the request processing performance index corresponding to the business request event within a specified time period to obtain the processing result; wherein, the request processing performance index is related to the request processing load, the request processing latency, and the request throughput. The request processing module is further configured to: adjust the processing speed of the data read / write requests in the first read / write queue according to the request processing performance index corresponding to the business request event within the specified time period; process the data read / write requests in the first read / write queue based on the adjusted processing speed, obtain the processing result, and return the processing result to the target device.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the request processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the request processing method according to any one of claims 1 to 6.

Images