Request processing method and device, equipment and storage medium

Abstract

The invention relates to a request processing method and device, equipment and a storage medium. The request processing method and device are used for a request processing subsystem in a distributed block storage system. And a driving module realized based on a UBLK framework is deployed in the request processing subsystem. The method comprises the following steps: receiving a data processing request for accessing a first target block device issued by a target application by using a driving module in a request processing subsystem, and forwarding the request to a data storage subsystem; the data processing request indicates the data storage subsystem to determine metadata of a first target block device and target data needing to be processed according to the data processing request in the first target node device, and the target data is processed according to the metadata of the first target block device to obtain a data processing result; a data processing result is returned to the request processing subsystem; and receiving a data processing result, and sending the data processing result to the target application by using the driving module. By adopting the method, the block device request of the application program can be efficiently processed.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a request processing method, apparatus, device and storage medium. Background Art

[0002] Block devices are a type of computer storage device. Using block devices to store data can improve the efficiency of data reading and writing. In view of this, the distributed storage system on computer devices can simulate block devices to improve the data processing performance of computer devices.

[0003] In the related art, it is necessary to implement a gateway layer in the distributed storage system to parse and convert various protocol requests. However, this increases the path and time for the system to process and respond to various requests, resulting in an increase in the delay time for the system to process requests. Summary of the invention

[0004] Based on this, it is necessary to provide a request processing method, apparatus, device and storage medium that can efficiently process block device requests of applications in response to the above technical problems.

[0005] In a first aspect, the present application provides a request processing method. A request processing subsystem in a distributed block storage system; the distributed block storage system includes the request processing subsystem and a data storage subsystem; a driver module based on the UBLK framework is deployed in the request processing subsystem; the method includes:

[0006] The driver module in the request processing subsystem is used to receive a data processing request for accessing a first target block device issued by a target application, and the data processing request is forwarded to the data storage subsystem; the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, and process the target data according to the metadata of the first target block device to obtain a data processing result; and the data processing result is returned to the request processing subsystem; the data processing result is received, and the data processing result is sent to the target application by using the driver module.

[0007] In one embodiment, the request processing subsystem is also deployed with a request analysis module and a first communication module; the driver module in the request processing subsystem is used to receive a data processing request for accessing a first target block device issued by a target application, and forward the data processing request to the data storage subsystem, including: using the driver module to send the data processing request to the request analysis module; using the request analysis module to split the data processing request to obtain multiple sub-processing requests, and sending each sub-processing request as the data processing result to the first communication module; wherein each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; and using the first communication module to forward each sub-processing request to the data storage subsystem.

[0008] In one embodiment, the data storage subsystem includes multiple storage processing modules, each storage processing module is deployed in a different cluster node device; the use of the first communication module to forward each sub-processing request to the data storage subsystem includes: using the first communication module to determine the first target node device from the multiple cluster node devices according to the first preset positioning rule, and forwarding each sub-processing request to the storage processing module of the first target node device.

[0009] In a second aspect, the present application further provides a request processing method for a data storage subsystem in a distributed block storage system; the distributed block storage system includes a request processing subsystem and the data storage subsystem; a driver module based on the UBLK framework is deployed in the request processing subsystem; the method includes:

[0010] A data processing request sent by the request processing subsystem is received; the data processing request is a request for accessing a first target block device issued by a target application received by the driver module in the request processing subsystem; in the first target node device, metadata of the first target block device and target data to be processed are determined according to the data processing request, and the target data is processed according to the metadata of the first target block device to obtain a data processing result; and the data processing result is returned to the request processing subsystem; the data processing result is used to instruct the request processing subsystem to send the data processing result to the target application through the driver module.

[0011] In one of the embodiments, a second communication module and a storage service module are deployed in the data storage subsystem; the receiving the data processing request sent by the request processing subsystem includes: using the second communication module to receive the data processing request, and sending the data processing request to the storage service module; wherein the data processing request includes multiple sub-processing requests, and each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; determining the metadata of the first target block device and the target data to be processed according to the data processing request, and processing the target data according to the metadata of the first target block device to obtain a data processing result, including: using the storage service module to parse each sub-processing request, determining the metadata of the first target block device and the target data block corresponding to each sub-processing request; and processing each target data block according to the metadata of the first target block device to obtain a processing result for each sub-processing request as the data processing result.

[0012] In one of the embodiments, a metadata management module is also deployed in the storage processing module; the method also includes: using the storage service module to return the data processing result to the second communication module; using the second communication module, after receiving the data processing result, based on the metadata of the first target block device, updating the access status information of the first target block device recorded in the metadata management module; and forwarding the data processing result to the request processing subsystem.

[0013] In a third aspect, the present application further provides a request processing device, which is used in a request processing subsystem in a distributed block storage system; the distributed block storage system includes the request processing subsystem and a data storage subsystem; a driver module based on the UBLK framework is deployed in the request processing subsystem; the device includes:

[0014] The request processing module is used to use the driver module in the request processing subsystem to receive a data processing request for accessing a first target block device issued by a target application, and forward the data processing request to the data storage subsystem; the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed in the first target node device according to the data processing request, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem;

[0015] The result processing module is used to receive the data processing result and send the data processing result to the target application by using the driving module.

[0016] In one embodiment, the request processing subsystem is also deployed with a request analysis module and a first communication module; the request processing module is specifically used to: use the driver module to send the data processing request to the request analysis module; use the request analysis module to split the data processing request to obtain multiple sub-processing requests, and send each sub-processing request as the data processing result to the first communication module; wherein each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; and use the first communication module to forward each sub-processing request to the data storage subsystem.

[0017] In one embodiment, the data storage subsystem includes multiple storage processing modules, each storage processing module is deployed in a different cluster node device; the request processing module is specifically used to: use the first communication module to determine the first target node device from the multiple cluster node devices according to the first preset positioning rule, and forward each sub-processing request to the storage processing module of the first target node device.

[0018] In a fourth aspect, the present application further provides a request processing device for a data storage subsystem in a distributed block storage system; the distributed block storage system includes a request processing subsystem and the data storage subsystem; a driver module based on the UBLK framework is deployed in the request processing subsystem; the device includes:

[0019] A request receiving module, used for receiving a data processing request sent by the request processing subsystem; the data processing request is a request for accessing a first target block device sent by a target application received by the driver module in the request processing subsystem;

[0020] The result forwarding module is used to determine the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem; the data processing result is used to instruct the request processing subsystem to send the data processing result to the target application through the driver module.

[0021] In one of the embodiments, a second communication module and a storage service module are deployed in the data storage subsystem; a request receiving module is specifically used to: use the second communication module to receive the data processing request, and send the data processing request to the storage service module; wherein the data processing request includes multiple sub-processing requests, and each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; a result forwarding module is specifically used to: use the storage service module to parse each sub-processing request, determine the metadata of the first target block device and the target data block corresponding to each sub-processing request; and process each target data block according to the metadata of the first target block device, and obtain a processing result for each sub-processing request as the data processing result.

[0022] In one of the embodiments, a metadata management module is also deployed in the storage processing module; the device also includes a data update module, which is used to: use the storage service module to return the data processing result to the second communication module; use the second communication module, after receiving the data processing result, to update the access status information of the first target block device recorded in the metadata management module according to the metadata of the first target block device; and forward the data processing result to the request processing subsystem.

[0023] In a fifth aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the methods described in the first aspect when executing the computer program.

[0024] In a sixth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any one of the methods described in the first aspect above.

[0025] In a seventh aspect, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the method described in any one of the above-mentioned first aspects are implemented.

[0026] The above-mentioned request processing method, device, equipment and storage medium, the request processing method is used for the request processing subsystem in the distributed block storage system; the distributed block storage system includes a request processing subsystem and a data storage subsystem; a driver module based on the UBLK framework is deployed in the request processing subsystem; in this method, the driver module in the request processing subsystem can be used to receive the data processing request for accessing the first target block device issued by the target application, and forward the data processing request to the data storage subsystem; the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, and process the target data according to the metadata of the first target block device to obtain the data processing result; and return the data processing result to the request processing subsystem; receive the data processing result, and use the driver module to send the data processing result to the target application. In this way, by directly using UBLK on the local host to provide block device services, additional gateway layers and protocol conversions are avoided, and the delay of the request processing path is greatly reduced, so that the block device requests of the application are efficiently processed in the distributed block storage system, and the system performance is significantly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0028] Figure 1 A schematic diagram of the structure of a distributed block storage system in one embodiment;

[0029] Figure 2 A schematic diagram of a request processing method in one embodiment;

[0030] Figure 3 A flowchart of another request processing method in one embodiment;

[0031] Figure 4 A schematic diagram of the structure of another distributed block storage system in one embodiment;

[0032] Figure 5 A schematic diagram of a process for processing a data processing request in one embodiment;

[0033] Figure 6 A schematic diagram of a process for determining a data processing result in one embodiment;

[0034] Figure 7 A schematic diagram of a process flow of a reorganization processing result in one embodiment;

[0035] Figure 8 A schematic diagram of a flow chart of processing a control command in one embodiment;

[0036] Fig. 9 It is a structural diagram of a distributed block storage system based on UBLK in an embodiment;

[0037] Fig.10 A flowchart of a process of processing a data processing request in one embodiment;

[0038] Fig.11 A flowchart of a process for processing a block device control command in one embodiment;

[0039] Fig.12 is a structural block diagram of a request processing device in one embodiment;

[0040] Fig.13 is a structural block diagram of another request processing device in one embodiment;

[0041] Fig.14 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0042] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are described in detail below in conjunction with the accompanying drawings. It should be understood that many specific details are set forth in the following description to facilitate a full understanding of the present application, but the present application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present application, so the present application is not limited by the specific embodiments disclosed below.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0044] It can be understood that the “connection” in the following embodiments should be understood as “electrical connection”, “communication connection”, etc. if the connected circuits, modules, units, etc. have electrical signals or data transmission between each other.

[0045] It can be understood that “at least one” means one or more, “plurality” means two or more, and “at least part of an element” means part or all of an element.

[0046] When used herein, the singular forms "a", "an", and "said / the" may also include plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "include / comprise" or "have" and the like specify the presence of stated features, wholes, steps, operations, components, parts, or combinations thereof, but do not exclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof. At the same time, the term "and / or" used in this specification includes any and all combinations of the relevant listed items.

[0047] With the rapid development of cloud computing and big data, distributed block storage technology is increasingly used in data centers. This technology improves data availability, reliability, and performance by distributing data on multiple physical or virtual storage devices. In cloud-native scenarios, block devices are usually provided to containers through containerization protocols. A common method is to use the volume function of the container runtime to mount block devices on the host into the container, so that the container can access and use these block devices.

[0048] At present, the main schemes for simulating block devices on hosts in distributed block storage systems are: compatible with existing network transmission block device protocol schemes; for example, iSCSI, NBD, and NVMe-oF protocols. This type of scheme has the following disadvantages: it is necessary to implement a gateway layer in the distributed storage system to parse and convert various protocol commands, which increases the request processing path, resulting in increased request processing latency, and may make gateway resources a system bottleneck.

[0049] In view of this, an embodiment of the present application proposes a UBLK-based distributed block storage system to create an efficient data path for a user space block device driver to provide high-performance block device services on a local host.

[0050] The request processing method provided in the embodiment of the present application can be applied to Figure 1 In the distributed block storage system shown. The distributed block storage system includes a request processing subsystem and a data storage subsystem; a driver module based on the UBLK framework is deployed in the request processing subsystem. The request processing subsystem and the data storage subsystem can be, but are not limited to, composed of various personal computers and / or servers, etc., wherein the server can be implemented as an independent server or a server cluster composed of multiple servers.

[0051] In one embodiment, Figure 2 As shown, a request processing method is shown, which is used in a request processing subsystem in a distributed block storage system. The method includes:

[0052] Step 201: Utilize a driver module in a request processing subsystem to receive a data processing request for accessing a first target block device issued by a target application, and forward the data processing request to a data storage subsystem.

[0053] The request processing subsystem is used to connect with the target application and can receive various block device requests issued by the target application. Specifically, since the data processing request issued by the target application is for the block device, and the request processing subsystem is in the distributed block storage system, a driver module is deployed in the request processing subsystem. The driver module is implemented based on the UBLK framework, where UBLK (User Block Device Driver) is a general framework for implementing block device logic in user mode. Its purpose is to move the virtual block driver to the user space and create an efficient data path for the user space block device driver to provide high-performance block device services on the local host.

[0054] Based on this, since the driver module implements the processing logic of the block device, it can receive various requests for the block device issued by the target application, and can also return the processing results of various requests to the target application. Therefore, the driver module in the request processing subsystem can be used to receive the data processing request for accessing the first target block device issued by the target application. In this way, the request processing subsystem can forward the obtained data processing request to the data storage subsystem.

[0055] Among them, the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed in the first target node device according to the data processing request, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem.

[0056] Here, the data storage subsystem is used to manage storage data. It can be deployed on multiple server devices to form a cluster, and each server is a cluster node, that is, a node device. Each node device is a local host and can be used to store data. In this way, the data storage subsystem uses each node device to distribute and store various data. In order to improve the performance of the entire distributed block storage system, a high-performance block device service is provided on the local host in an embodiment of the present application. In other words, in an embodiment of the present application, the distributed block storage system simulates the data of the storage block device, which can receive a processing request for the block device, and access the distributed block storage system based on the request, thereby utilizing the high performance of the block device.

[0057] Since there are multiple node devices, and the data processing request does not access all of the node devices, a first target node device needs to be determined from them. Optionally, there are one or more first target node devices.

[0058] Optionally, the data processing request is a write request for requesting to write the target data to the first target block device; or, the data processing request may also be a read request for requesting to read the target data from the first target block device. It is understandable that the data of each block device is stored in each node device.

[0059] The data storage subsystem receives the data processing request in the first target node device, and determines the metadata of the first target block device and the target data to be processed according to the data processing request.

[0060] Here, if the data processing request is a write request, the data processing request includes the metadata and target data of the first target block device, and in the data storage subsystem, various types of data are stored in association with the metadata of the corresponding block device, so the metadata of the first target block device and the target data can be stored in association for subsequent access. If the data processing request is a read request, the data processing request includes the metadata of the first target block device and the read address of the target data, so the target data can be read based on the metadata of the first target block device and the read address.

[0061] Accordingly, after processing the target data, a data processing result can be obtained. Exemplarily, if it is a write request, the data processing result may include whether the write is successful and / or the address of the written target data, etc., which are not fully illustrated here. If it is a read request, the data processing result may include the read target data.

[0062] Optionally, the metadata of the first target block device includes one or more of a name of the first target block device, a block device size, a sector size, and a snapshot.

[0063] Step 202, receiving the data processing result, and using the driver module to send the data processing result to the target application.

[0064] Since the request processing subsystem can be connected to the target application through the driver module, the data storage subsystem returns the data processing result to the request processing subsystem, and then returns it to the target application through the driver module.

[0065] In one embodiment, Figure 3 Another request processing method is shown, which is used for a data storage subsystem in a distributed block storage system; the method comprises:

[0066] Step 301: Receive a data processing request sent by a request processing subsystem.

[0067] The data processing request is a request for accessing the first target block device issued by the target application and received by the driver module in the request processing subsystem.

[0068] Step 302: In the first target node device, metadata of the first target block device and target data to be processed are determined according to the data processing request, and the target data is processed according to the metadata of the first target block device to obtain a data processing result; and the data processing result is returned to the request processing subsystem. The data processing result is used to instruct the request processing subsystem to send the data processing result to the target application through the driver module.

[0069] The request processing method applied to the distributed block storage system can use the driver module in the request processing subsystem to receive the data processing request for accessing the first target block device issued by the target application, and forward the data processing request to the data storage subsystem; the data storage subsystem determines the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, and processes the target data according to the metadata of the first target block device to obtain the data processing result; and returns the data processing result to the request processing subsystem; receives the data processing result, and uses the driver module to send the data processing result to the target application. In this way, by directly using UBLK on the local host to provide block device services, additional gateway layers and protocol conversions are avoided, and the delay of the request processing path is greatly reduced, so that the block device requests of the application are efficiently processed in the distributed block storage system, and the system performance is significantly improved. The data access speed is improved, the computing and network resources of the local host are fully utilized, and the block storage capability with fast response is provided for the application.

[0070] Providing high-performance block device services on the local host through UBLK has the following advantages: 1. Drivers can be written in a variety of programming languages. 2. Libraries that are not available in the kernel can be used. 3. Debugging can be done using tools familiar to application developers. 4. Driver crashes will not cause kernel crashes. 5. Errors in user-mode code have less impact on system security. 6. Can be installed and updated independently of the kernel. 7. Block devices can be easily simulated based on user-specified parameters / settings for testing / debugging purposes. In addition, UBLK's workload can be undertaken by any local host process that submits I / O requests to UBLK block devices or kernel file systems based on UBLK block devices, making it very suitable for cloud-native scenarios.

[0071] In an optional implementation, Figure 4A structural diagram of another distributed block storage system is shown. The request processing subsystem is also deployed with a request analysis module, a first communication module and a control command module; the data storage subsystem includes multiple storage processing modules, each storage processing module is deployed in a different cluster node device; the data storage subsystem is deployed with a second communication module and a storage service module, in other words, each storage processing module includes a second communication module, a storage service module and a metadata management module.

[0072] It should be noted that the distributed block storage system and the modules therein can be implemented through software algorithms and deployed in computer devices such as servers for operation.

[0073] In the embodiment of the present application, based on the first communication module and the second communication module, data forwarding can be performed between the two subsystems. A storage processing module is deployed in each cluster node device, so that each cluster node device has the ability to process data processing requests, improving the efficiency and convenience of request processing. In addition, based on the control command module, the control command for the block device issued by the target application can be processed. The method is explained below based on this.

[0074] In one embodiment, Figure 5 A schematic diagram of a process for processing a data processing request is shown. The driver module in the request processing subsystem receives a data processing request for accessing a first target block device issued by a target application, and forwards the data processing request to the data storage subsystem, including:

[0075] Step 501: Use the driver module to send the data processing request to the request analysis module.

[0076] The driver module is communicatively connected to the request analysis module, so that the transmission of the request can be realized.

[0077] Optionally, the target application and the data processing subsystem are both deployed in a computer device.

[0078] Optionally, the target application of the computer device sends a data processing request, which is received by the driver module and forwarded to the request analysis module after passing through the Block Layer. The Block Layer is an abstract layer in the Linux kernel used to manage block device I / O operations. It is between the file system and the block device driver and is responsible for converting the file system's I / O requests into operations that the block device can understand; its main function is to convert the upper-layer file system requests into read and write operations of the lower-layer storage device.

[0079] Step 502: Use the request analysis module to split the data processing request to obtain multiple sub-processing requests, and send each sub-processing request as a data processing result to the first communication module.

[0080] Each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data.

[0081] Exemplarily, each sub-processing request may be used by the data storage subsystem to determine metadata of a first target block device corresponding to the sub-processing request and a target data block to be processed.

[0082] For example, the data processing request is a write request, which includes metadata of the first target block device and target data. Then, after splitting the data processing request, the target data is split into multiple target data blocks. For each sub-processing request, each sub-processing request is still a write request, and each sub-processing request includes metadata of the first target block device and a corresponding target data block.

[0083] For another example, the data processing request is a read request, which includes the metadata of the first target block device and the read address of the target data to be read. Then, after the data processing request is split, the read address of the target data is split into the read addresses of multiple target data blocks. For each sub-processing request, each sub-processing request is still a read request, and each sub-processing request includes the metadata of the first target block device and the read address of the corresponding target data block.

[0084] Of course, the sub-processing request may also include other information, which is not fully illustrated here.

[0085] Optionally, a splitting rule is preset in the request analysis module, so that the data processing request is split into multiple sub-processing requests according to the shard size and shard boundary set by the splitting rule, and all the sub-processing requests are sent to the first communication module as data processing results.

[0086] Step 503: forward each sub-processing request to the data storage subsystem using the first communication module.

[0087] The request processing subsystem is connected to the data storage subsystem through the first communication module to achieve communication between the two, so the first communication module can be used to forward each sub-processing request to the data storage subsystem.

[0088] In the embodiment of the present application, the request processing subsystem can be installed and updated independently of the kernel of the computer device, which has higher flexibility and maintainability. In addition, the user can easily simulate the block device in the computer device according to the specified parameters and settings for testing and debugging purposes, which improves the scalability and convenience of the system. The data processing request is split and forwarded based on the request processing subsystem, which improves the processing efficiency of the request.

[0089] In one embodiment, as mentioned above, the data storage subsystem includes multiple storage processing modules, and each storage processing module is deployed in a different cluster node device. Based on this, each sub-processing request is forwarded to the data storage subsystem using the first communication module, including: using the first communication module, according to the first preset positioning rule, determining the first target node device from the multiple cluster node devices, and forwarding each sub-processing request to the storage processing module of the first target node device.

[0090] Optionally, the first preset positioning rule may be a rule determined based on a polling method or a rule determined based on a hash query method, which is not fully exemplified here.

[0091] According to the first preset positioning rule, a first target node device can be determined from the cluster. The first target node device has a storage processing module deployed therein, and thus can receive each sub-processing request.

[0092] In this way, the first target node device for processing the data processing request can be efficiently determined based on the preset positioning rule, thereby ensuring the reliability and efficiency of the request processing.

[0093] In one embodiment, as mentioned above, a second communication module and a storage service module are deployed in the data storage subsystem. Figure 6 A schematic diagram of a process for determining a data processing result is shown. Receiving a data processing request sent by a request processing subsystem includes:

[0094] Step 601: Utilize the second communication module to receive a data processing request, and send the data processing request to the storage service module.

[0095] As mentioned above, the data processing request includes multiple sub-processing requests, and each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data.

[0096] Here, it is the second communication module in the first target node device that receives the data processing request.

[0097] It is understandable that each cluster node device has a second communication module, and each second communication module is connected to the first communication module in the request processing subsystem to achieve communication and data forwarding between the two subsystems. Therefore, the first target node device receives the data processing request using the second communication module.

[0098] In the storage processing module of the first target node device, the second communication module is connected to the storage service module, so the data processing request is further sent to the storage service module.

[0099] Step 602, using the storage service module to parse each sub-processing request, determine the metadata of the first target block device and the target data block corresponding to each sub-processing request; and process each target data block according to the metadata of the first target block device to obtain a processing result for each sub-processing request as a data processing result.

[0100] Each subprocessing request can be parsed.

[0101] For example, if each sub-processing request is a write request, the metadata and target data block of the first target block device in each sub-processing request can be determined after parsing to obtain multiple target data blocks. It can be understood that the metadata of the first target data block device in each sub-processing request is the same. In this way, the metadata and target data block of each first target block device can be written to the storage area of ​​the first target node device.

[0102] For another example, if each sub-processing request is a read request, metadata of the first target block device and the read address of the target data block in each sub-processing request are obtained after parsing. In this way, the storage location of the target data block can be located based on the read address, and the target data block corresponding to the first target block device in the location can be determined based on the metadata, so as to read the target data block.

[0103] Exemplarily, the storage service module may perform write / read operations on each target data block simultaneously.

[0104] In this way, by processing each target data block at the same time, the processing efficiency of the target data is greatly improved, the data access speed is improved, and the computing and storage resources of the node device are fully utilized.

[0105] In one embodiment, the method further includes: using the storage service module to return the data processing result to the second communication module; using the second communication module, after receiving the data processing result, updating the access status information of the first target block device recorded in the metadata management module according to the metadata of the first target block device; and forwarding the data processing result to the request processing subsystem.

[0106] Optionally, if it is a write request, the data processing result may indicate a write success or a write failure, and may also include the address of the data after writing. If it is a read request, the data processing result may include the read target data, or indicate a read failure if the read fails.

[0107] Exemplarily, the metadata management module records the access status information of each block device. The access status information of the first target block device recorded in the metadata management module is updated as follows: when the data processing result guarantees that the read is successful or the write is successful, the access status information of the first target block device is updated to be currently successfully accessed. For example, the time of the current successful access may be updated, which is not fully illustrated here.

[0108] In addition, the second communication module can also forward the data processing result to the first communication module of the request processing subsystem to achieve result forwarding.

[0109] Optionally, the metadata management module records metadata of multiple block devices, and the metadata of block devices includes one or more of the name of the block device, the size of the block device, the sector size, and the snapshot. In addition, the metadata management module can also record metadata of each cluster node device, and the metadata of the cluster node device includes one or more of the IP address, name, and topology of the cluster node device, which are not fully illustrated here.

[0110] In this way, the distributed block storage system can record the access information for each block device in a timely manner, ensuring a complete record of the entire access process, and facilitating the call and query of the upper-level system.

[0111] In one embodiment, Figure 7 A schematic diagram of a process of reorganizing a processing result is shown. Receiving a data processing result and sending the data processing result to a target application using a driver module includes:

[0112] Step 701: Utilize the first communication module to receive the data processing result, and send the data processing result to the request analysis module.

[0113] The data processing result includes the processing result of each sub-processing request;

[0114] Step 702: Using the request analysis module, the processing results of each sub-processing request are reorganized according to a preset reorganization rule, and the reorganized processing results are sent to the driving module.

[0115] It is understandable that the processing efficiency of the data processing request can be improved by splitting and processing. When the processing results of the respective processing requests are received, the processing results need to be reorganized to merge and obtain a complete data processing result.

[0116] Optionally, the preset reorganization rule is opposite to the preset splitting rule. Based on the reverse logic of the splitting, the processing results of the respective processing requests are reorganized.

[0117] Exemplarily, if it is a write request, the processing result of each sub-processing request is a successful write, and the write address of each target data block is spliced, then the write address of each target data block is spliced, and the data processing result includes the spliced ​​complete address and the successful write result.

[0118] Exemplarily, if it is a read request, the processing results of each sub-processing request include each target data block, and each target data block is spliced ​​to obtain the target data, and the data processing result includes the target data.

[0119] Step 703: Use the driver module to send the reorganized processing result to the target application.

[0120] In this way, the UBLK framework is used to implement block device logic in user mode, so that the local host can efficiently provide block device services, improve data access speed, and make full use of the host's computing and storage resources.

[0121] In one embodiment, Figure 8 A schematic diagram of a process for processing a control command is shown. The method also includes:

[0122] Step 801: Use a control command module to receive a control command for a second target block device issued by a target application, determine metadata of the second target block device according to the control command, and send the metadata and control command of the second target block device to a first communication module.

[0123] The control command module receives a series of control commands sent by the target application to create, mount, delete block devices, etc. The persistence of the local host block device status depends on the metadata management module of the distributed block storage.

[0124] The control command is, for example, at least one of a create command, a delete command, a capacity expansion command, a mount command, a stop command, and a restore command. Each control command will update the status information of the corresponding block device in the distributed block storage system.

[0125] Optionally, for the mount command, stop command and resume command, in addition to updating the status information of the block device, corresponding operations need to be performed in the request processing subsystem on the computer device.

[0126] The control command module may parse the received control command to obtain metadata of the second target block device that the control command needs to control, and then forward all data to the first communication module.

[0127] Step 802: using the first communication module, according to the second preset positioning rule, determine the second target node device from multiple cluster node devices, and forward the metadata and control command of the second target block device to the storage processing module of the second target node device.

[0128] Optionally, the second preset positioning rule may be a rule determined based on a polling method or a rule determined based on a hash query method, which is not fully exemplified here.

[0129] According to the second preset positioning rule, a second target node device can be determined from the cluster. A storage processing module is deployed in the second target node device, so the control command can be received.

[0130] The metadata of the second target block device and the control command are used to instruct the storage processing module to process the metadata of the second target block device according to the control command and the metadata of the second target block device.

[0131] Exemplarily, if the control command is a create command, the storage processing module can create metadata of the second target block device in the second target node device according to the control command. Here, the actual second target block device is not directly created, but the process of creating the second target block device is simulated, and the metadata of the second target block device is stored so that the data storage subsystem can know that there is metadata of the newly added block device.

[0132] In one embodiment, the method further includes: using a second communication module to receive metadata and control commands of a second target block device sent by a request processing subsystem, and sending the metadata and control commands of the second target block device to a metadata management module; using the metadata management module to process the metadata of the second target block device according to the control command and the metadata of the second target block device.

[0133] That is, the metadata management module is specifically utilized to simulate and execute the control process of the second target block device, so as to synchronously update the metadata of the second target block device.

[0134] In this way, when the subsequent target application sends a data processing request for the second target block device, the distributed block storage system can also ensure that the data processing request of the second target block device can be processed normally.

[0135] In one embodiment, the method further includes: using the metadata management module to process the metadata of the second target block device according to the control command and the metadata of the second target block device, to obtain the processing result of the control command; and using the second communication module to forward the processing result of the control command to the first communication module.

[0136] In one embodiment, the method further includes: using the first communication module to receive the execution result of the control command returned by the storage processing module, and sending the execution result to the control command module; using the control command module, when the execution result indicates that the metadata management module successfully executes the control command, processing the second target block device in the request processing subsystem according to the control command.

[0137] The execution result may indicate whether the execution is successful or not. For example, if the control command is a create command, the execution result may be a create success or a create failure.

[0138] If the execution result is successful, the corresponding processing must also be performed in the request processing subsystem.

[0139] Exemplarily, also taking the creation command as an example, when the execution result indicates that the metadata management module successfully executes the control command, a second target block device is created in the request processing subsystem according to the control command. In this way, the upper system of the distributed block storage system can call the second target block device, enriching the functions of the distributed block storage system.

[0140] Optionally, when the control command is a mount command, a stop command or a resume command, after executing the control command, the control command module also asynchronously notifies the drive module to perform a corresponding operation to achieve synchronization.

[0141] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0142] Based on the same inventive concept, the embodiment of the present application also provides a distributed block storage system for implementing the request processing method involved above. The implementation solution provided by the distributed block storage system to solve the problem is similar to the implementation solution recorded in the above method, so the specific limitations in one or more distributed block storage system embodiments provided below can refer to the limitations on the request processing method above, and will not be repeated here.

[0143] In one embodiment, a distributed block storage system is provided, the system comprising:

[0144] The request processing subsystem is used to receive, by using the driver module, a data processing request for accessing the first target block device issued by the target application, and forward the data processing request to the data storage subsystem;

[0145] The data storage subsystem is used to determine the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem;

[0146] The request processing subsystem is also used to send the data processing results to the target application through the driver module.

[0147] In one embodiment, the request processing subsystem also includes a request analysis module and a first communication module; a driving module, used to send the data processing request to the request analysis module; the request analysis module, used to split the data processing request and send the split data processing request to the first communication module; the first communication module, used to forward the split data processing request to the data storage subsystem.

[0148] In one embodiment, a request analysis module is used to split a data processing request into multiple sub-processing requests according to a preset splitting rule based on the target data to be processed by the data processing request, and use the multiple sub-processing requests as the split data processing requests; wherein each sub-processing request is used to request the data storage subsystem to process a target data block; and the target data block is a part of the target data.

[0149] In one embodiment, the data storage subsystem includes multiple storage processing modules, each of which is deployed in a different cluster node device; a first communication module is used to determine a first target node device from multiple cluster node devices according to a first preset positioning rule, and forward the split data processing request to the storage processing module of the first target node device.

[0150] In one embodiment, the storage processing module includes a second communication module and a storage service module; the second communication module is used to receive the data processing request after splitting and send the data processing request after splitting to the storage service module; the storage service module is used to parse each sub-processing request to obtain the metadata of the first target block device and the target data block corresponding to each sub-processing request; according to the metadata of the first target block device, each target data block is processed to obtain the processing result for each sub-processing request as the data processing result.

[0151] In one embodiment, the storage processing module also includes a metadata management module; the storage service module is also used to return the data processing result to the second communication module; the second communication module is also used to update the access status information of the first target block device recorded in the metadata management module according to the metadata of the first target block device after receiving the data processing result; and it is also used to forward the data processing result to the first communication module.

[0152] In one embodiment, the first communication module is also used to send the data processing results to the request analysis module; the request analysis module is also used to reorganize the processing results of each sub-processing request according to a preset reorganization rule, and send the reorganized processing results to the driving module; the driving module is used to send the reorganized processing results to the target application.

[0153] In one embodiment, the request processing subsystem also includes a control command module; the control command module is used to receive a control command for a second target block device issued by a target application, determine the metadata of the second target block device according to the control command, and send the metadata and control command of the second target block device to the first communication module; the first communication module is used to determine the second target node device from multiple cluster node devices according to a second preset positioning rule, and forward the metadata and control command of the second target block device to the storage processing module of the second target node device.

[0154] In one embodiment, the second communication module is used to receive metadata and control commands of the second target block device, and send the metadata and control commands of the second target block device to the metadata management module; the metadata management module is used to process the metadata of the second target block device according to the control command and the metadata of the second target block device.

[0155] In one embodiment, the first communication module is further used to receive the execution result of the control command returned by the second communication module, and send the execution result to the control command module; the control command module is further used to process the second target block device in the request processing subsystem according to the control command when the execution result indicates that the metadata management module successfully executes the control command.

[0156] For ease of understanding, a UBLK-based distributed block storage system provided by the present application is described below with a complete embodiment. Fig. 9 As shown, the distributed block storage system based on UBLK is the same as the above distributed block storage system, which includes a client subsystem and a distributed block storage cluster subsystem. The client subsystem is the same as the request processing subsystem above, and the distributed block storage cluster subsystem is the same as the data storage subsystem above. The client subsystem and the distributed block storage cluster subsystem use a custom protocol for communication and connection.

[0157] The client subsystem is used to generate and forward data processing requests (hereinafter referred to as IO requests) and send control commands for block devices. It includes a kernel driver module (such as the driver module mentioned above), a user-mode driver module (such as the request analysis module mentioned above), a control command module (such as the control command module mentioned above), and a communication protocol module (such as the first communication module mentioned above). The distributed block storage cluster subsystem consists of N servers, providing metadata management services and storage services to the outside world. Each server includes a storage service module (such as the storage service module mentioned above), a communication protocol module (such as the second communication module mentioned above), and a metadata management module (such as the metadata management module mentioned above).

[0158] Kernel driver module: processes the IO requests issued by the application and delivers them to the user-mode driver module; it can also collect the IO results submitted by the user-mode driver module and deliver them to the application.

[0159] User-mode driver module: splits the IO requests sent by the kernel driver module according to the slice size and slice boundary and sends them to the communication protocol module; it can also collect the IO requests completed by the communication protocol module and return them to the kernel driver module.

[0160] Control command module: receives a series of control commands such as creating, mounting, and deleting block devices sent by the local host application.

[0161] Communication protocol module: receives IO requests issued by the user-state driver module and sends the requests to the corresponding distributed block storage system nodes according to the rules; it can also collect IO requests completed by the distributed block storage system and return them to the user-state driver module.

[0162] Communication protocol module: receives IO requests issued by the client subsystem and delivers them to the storage service module; can also collect IO requests completed by the storage service module and return them to the client subsystem module.

[0163] Metadata management service module: stores block device metadata and cluster metadata, including block device size, cluster node IP and other information.

[0164] Storage service module: writes write IO requests to disk and reads read IO request data.

[0165] like Fig.10 The following figure shows the process of sending a data processing request by an application:

[0166] 1. The IO request sent by the application of the local host is received by the kernel driver module after passing through the Block Layer and forwarded to the user-mode driver module.

[0167] 2. The user-mode driver module receives the IO request passed by the kernel driver module and uses its specific block service logic to process the IO request. Specifically, the user-mode driver module is responsible for splitting the IO according to the slice size and slice boundary, and then passing the split IO request to the communication protocol module.

[0168] 3. The communication protocol module connects to a server in the distributed block storage cluster subsystem according to the rules and transmits the IO request to the server. The rules can be polling or hashing, and the form is not limited.

[0169] 4. The communication protocol module in the connected server receives the IO request and sends the IO request to the storage service module.

[0170] 5. The storage service module processes the IO request and writes / reads the data on the disk. After completion, it returns the result to the communication protocol module.

[0171] 6. The communication protocol module receives the IO processing result from the storage service module, updates the metadata information of the data block in the IO request from the metadata management service, and returns the result to the client subsystem.

[0172] 7. The client subsystem communication protocol module receives the IO processing result and returns it.

[0173] 8. The user-mode driver module receives all split IO processing results, reorganizes the IO according to the IO splitting rules, and returns them to the kernel driver module.

[0174] 9. The kernel driver module receives the IO processing results from the user-mode driver module and returns them to the application.

[0175] 10. The application harvests the IO processing results.

[0176] like Fig.11 The following figure shows the process of sending block device control commands by the application:

[0177] 1. The application sends block device control commands. Control commands include create, delete, expand, mount, stop, and restore.

[0178] Each control command will update the status information of the corresponding block device in the distributed storage cluster subsystem. In addition to updating the status information of the block device, mounting, stopping, and restoring also require the kernel driver module on the local host to perform corresponding operations.

[0179] 2. The control command module receives and parses the control command, generates metadata information of the corresponding block device, and passes it to the communication protocol module of the local host.

[0180] 3. The communication protocol module connects to a server in the distributed block storage cluster subsystem according to the rules and transmits control commands and metadata. The rules can be polling or hashing, in any form.

[0181] 4. The communication protocol module of the distributed block storage cluster subsystem receives the control command and metadata and passes them to the metadata management module.

[0182] 5. The metadata management module updates / deletes / creates the acquired metadata according to the control command type and returns the metadata processing result.

[0183] 6. The communication protocol module returns the metadata processing result.

[0184] 7. The communication protocol module of the client subsystem obtains the metadata processing result and returns it to the control command module.

[0185] 8. The control command module obtains the return result of the control command and metadata. If the return result is failure, it returns to the local application that the control command execution failed; otherwise, it executes the corresponding control command, such as the create block device control command, and creates the corresponding block device in the client subsystem.

[0186] 9. When the control command is mount / stop / restore, the control command module asynchronously notifies the kernel driver module to perform the corresponding operation.

[0187] The embodiments of the present application are intended to provide a high-performance distributed block storage system, which enables the local host to efficiently provide block device services, thereby meeting the growing and changing storage needs in cloud computing and big data environments, and addressing the shortcomings of current distributed block storage technologies. In particular, the focus is on improving the ability of the local host to provide block device services and optimizing the performance of the distributed block device system, specifically including the following aspects:

[0188] Improve system performance: The existing distributed block storage solutions need to implement a gateway layer in the distributed storage system, which increases the latency of the IO path and causes performance degradation. In the embodiment of the present application, by directly using UBLK on the local host to provide block device services, the additional gateway layer and protocol conversion are avoided, the latency of the IO path is greatly reduced, and the system performance is significantly improved.

[0189] Efficient local host block device service: The UBLK framework is used to implement block device logic in user mode, thereby moving the virtual block driver to user space and creating an efficient data path for the user space block device driver, so that the local host can efficiently provide block device services, improve data access speed, and make full use of the host's computing and storage resources. It eliminates the reliance on custom clients or compatible network transmission protocols, simplifies the development and management of client drivers, and reduces the complexity of the system.

[0190] Simplify client driver development and management: By moving block device drivers to user space, the complexity of kernel development is reduced, and the high quality requirements of client kernel modules are lowered. User-mode driver development can use a variety of programming languages ​​and tools, which simplifies the development and debugging process and enhances the flexibility of the system.

[0191] Improve system stability and security: User-mode driver crashes will not cause kernel crashes, thus improving system stability. At the same time, errors in user-mode code have less impact on system security, thus enhancing system security.

[0192] Enhanced flexibility and maintainability: User-mode block device drivers can be installed and updated independently of the kernel, which provides greater flexibility and maintainability. In addition, users can easily simulate block devices based on specified parameters and settings for testing and debugging purposes, improving the scalability and convenience of the system.

[0193] Based on the same inventive concept, the embodiment of the present application also provides a request processing device for implementing the request processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more request processing device embodiments provided below can refer to the limitations on the request processing method above, and will not be repeated here.

[0194] In one embodiment, Fig.12 As shown, a request processing device is provided, and the request processing device 1200 includes: a request processing module 1201 and a result processing module 1202, wherein:

[0195] The request processing module 1201 is used to receive a data processing request for accessing a first target block device issued by a target application using a driver module in the request processing subsystem, and forward the data processing request to the data storage subsystem; the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed in the first target node device according to the data processing request, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem;

[0196] The result processing module 1202 is used to receive the data processing result and send the data processing result to the target application using the driver module.

[0197] In one of the embodiments, the request processing subsystem is also deployed with a request analysis module and a first communication module; the request processing module 1201 is specifically used to: use the driver module to send the data processing request to the request analysis module; use the request analysis module to split the data processing request to obtain multiple sub-processing requests, and send each sub-processing request as a data processing result to the first communication module; wherein each sub-processing request is used to request the data storage subsystem to process the target data block; the target data block is a part of the target data; and use the first communication module to forward each sub-processing request to the data storage subsystem.

[0198] In one embodiment, the data storage subsystem includes multiple storage processing modules, each storage processing module is deployed in a different cluster node device; the request processing module 1201 is specifically used to: use the first communication module to determine the first target node device from multiple cluster node devices according to the first preset positioning rule, and forward each sub-processing request to the storage processing module of the first target node device.

[0199] In one embodiment, Fig.13 As shown, another request processing device is provided, the request processing device 1300 includes: a request receiving module 1301 and a result forwarding module 1302, wherein:

[0200] The request receiving module 1301 is used to receive a data processing request sent by the request processing subsystem; the data processing request is a request for accessing a first target block device sent by a target application received by a driver module in the request processing subsystem;

[0201] The result forwarding module 1302 is used to determine the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem; the data processing result is used to instruct the request processing subsystem to send the data processing result to the target application through the driver module.

[0202] In one of the embodiments, a second communication module and a storage service module are deployed in the data storage subsystem; the request receiving module 1301 is specifically used to: use the second communication module to receive a data processing request, and send the data processing request to the storage service module; wherein the data processing request includes multiple sub-processing requests, and each sub-processing request is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; the result forwarding module 1302 is specifically used to: use the storage service module to parse each sub-processing request, determine the metadata of the first target block device and the target data block corresponding to each sub-processing request; and process each target data block according to the metadata of the first target block device, and obtain a processing result for each sub-processing request as a data processing result.

[0203] In one of the embodiments, a metadata management module is also deployed in the storage processing module; the device also includes a data update module, which is used to: use the storage service module to return the data processing result to the second communication module; use the second communication module, after receiving the data processing result, to update the access status information of the first target block device recorded in the metadata management module according to the metadata of the first target block device; and forward the data processing result to the request processing subsystem.

[0204] Each module in the above request processing device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0205] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.14 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store request processing data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a request processing method is implemented.

[0206] Those skilled in the art will understand that Fig.14 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0207] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0208] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0209] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0210] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0211] The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0212] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A request processing method, characterized in that: A request processing subsystem used in a distributed block storage system; the distributed block storage system includes the request processing subsystem and a data storage subsystem; A driver module based on the UBLK framework is deployed in the request processing subsystem; the method includes: The driver module in the request processing subsystem receives a data processing request for accessing a first target block device issued by a target application, and forwards the data processing request to the data storage subsystem; the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed in the first target node device according to the data processing request, and to process the target data according to the metadata of the first target block device to obtain a data processing result; and the data processing result is returned to the request processing subsystem; The data processing result is received, and the data processing result is sent to the target application by using the driver module.

2. The method according to claim 1, characterized in that: The request processing subsystem is further deployed with a request analysis module and a first communication module; the use of the driver module in the request processing subsystem to receive a data processing request for accessing a first target block device issued by a target application, and forwarding the data processing request to the data storage subsystem includes: Using the driving module to send the data processing request to the request analysis module; The request analysis module is used to split the data processing request to obtain multiple sub-processing requests, and each of the sub-processing requests is sent to the first communication module as the data processing result; wherein each of the sub-processing requests is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; Each of the sub-processing requests is forwarded to the data storage subsystem by using the first communication module.

3. The method according to claim 2, characterized in that The data storage subsystem includes a plurality of storage processing modules, each of which is deployed in a different cluster node device; and using the first communication module to forward each of the sub-processing requests to the data storage subsystem includes: The first communication module is used to determine a first target node device from the plurality of cluster node devices according to a first preset positioning rule, and each of the sub-processing requests is forwarded to a storage processing module of the first target node device.

4. A request processing method, characterized in that: A data storage subsystem used in a distributed block storage system; the distributed block storage system comprises a request processing subsystem and the data storage subsystem; A driver module based on the UBLK framework is deployed in the request processing subsystem; the method includes: receiving a data processing request sent by the request processing subsystem; the data processing request is a request for accessing a first target block device sent by a target application received by the driver module in the request processing subsystem; In the first target node device, the metadata of the first target block device and the target data to be processed are determined according to the data processing request, and the target data is processed according to the metadata of the first target block device to obtain a data processing result; and the data processing result is returned to the request processing subsystem; the data processing result is used to instruct the request processing subsystem to send the data processing result to the target application through the driver module.

5. The method according to claim 4, characterized in that The data storage subsystem is provided with a second communication module and a storage service module; the receiving of the data processing request sent by the request processing subsystem comprises: Utilize the second communication module to receive the data processing request, and send the data processing request to the storage service module; wherein the data processing request includes a plurality of sub-processing requests, and each of the sub-processing requests is used to request the data storage subsystem to process a target data block; the target data block is a part of the target data; The step of determining the metadata of the first target block device and the target data to be processed according to the data processing request, and processing the target data according to the metadata of the first target block device to obtain a data processing result includes: The storage service module is used to parse each of the sub-processing requests to determine the metadata of the first target block device and the target data block corresponding to each of the sub-processing requests; and each of the target data blocks is processed according to the metadata of the first target block device to obtain a processing result for each of the sub-processing requests as the data processing result.

6. The method according to claim 5, characterized in that The data storage subsystem is also equipped with a metadata management module; the method further comprises: Using the storage service module to return the data processing result to the second communication module; After receiving the data processing result, using the second communication module, the access status information of the first target block device recorded in the metadata management module is updated according to the metadata of the first target block device; and the data processing result is forwarded to the request processing subsystem.

7. A request processing device, characterized in that: A request processing subsystem used in a distributed block storage system; the distributed block storage system includes the request processing subsystem and a data storage subsystem; The request processing subsystem is deployed with a driver module based on the UBLK framework; the device includes: A request processing module is used to use the driver module in the request processing subsystem to receive a data processing request for accessing a first target block device issued by a target application, and forward the data processing request to the data storage subsystem; the data processing request is used to instruct the data storage subsystem to determine the metadata of the first target block device and the target data to be processed in the first target node device according to the data processing request, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem; The result processing module is used to receive the data processing result and send the data processing result to the target application by using the driving module.

8. A request processing device, characterized in that: A data storage subsystem used in a distributed block storage system; the distributed block storage system comprises a request processing subsystem and the data storage subsystem; The request processing subsystem is deployed with a driver module based on the UBLK framework; the device includes: A request receiving module, used for receiving a data processing request sent by the request processing subsystem; the data processing request is a request for accessing a first target block device sent by a target application received by the driver module in the request processing subsystem; A result forwarding module is used to determine the metadata of the first target block device and the target data to be processed according to the data processing request in the first target node device, and process the target data according to the metadata of the first target block device to obtain a data processing result; and return the data processing result to the request processing subsystem; the data processing result is used to instruct the request processing subsystem to send the data processing result to the target application through the driver module.

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

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

Images