Request processing method, apparatus, device, and storage medium

Abstract

The application relates to a request processing method, device and equipment and a storage medium, which are used for a request processing subsystem in a distributed block storage system; a driving module based on a UBLK framework is arranged in the request processing subsystem. The method comprises the following steps: receiving a data processing request for accessing a first target block device, which is issued by a target application, by using the driving module in the request processing subsystem, and forwarding the request to a data storage subsystem; the data processing request instructs the data storage subsystem to determine metadata of the first target block device and target data required to be processed in a first target node device according to the data processing request, to process the target data according to the metadata of the first target block device, and to obtain a data processing result; 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 driving module. The method can efficiently process a block device request of an application program.

Description

Request processing methods, apparatus, devices and storage media Technical Field

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

[0002] Block devices are a type of computer storage device, and using block devices to store data can improve data read and write efficiency. Therefore, distributed storage systems on computer devices can simulate block devices to enhance the data processing performance of the computer.

[0003] In related technologies, a gateway layer needs to be implemented in the distributed storage system to parse and transform various protocol requests. However, this increases the path and time for the system to process and respond to various requests, resulting in increased latency in request processing. Summary of the Invention

[0004] Therefore, it is necessary to provide a request processing method, apparatus, device, and storage medium that can efficiently process block device requests from applications, addressing the aforementioned technical problems.

[0005] Firstly, this application provides a request processing method. A request processing subsystem is 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 deploys a driver module implemented based on the UBLK framework; the method includes:

[0006] The driver module in the request processing subsystem receives a data processing request from the target application to access the first target block device and forwards the request to the data storage subsystem. The data processing request instructs 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, process the target data according to the metadata of the first target block device, and obtain the data processing result. The data processing result is then returned to the request processing subsystem. The driver module receives the data processing result and sends it to the target application.

[0007] In one embodiment, the request processing subsystem further includes a request analysis module and a first communication module. The method of receiving a data processing request from a target application to access a first target block device via the driver module within the request processing subsystem, and forwarding the data processing request to the data storage subsystem, includes: 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 into 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 of which is deployed in different cluster node devices. The method of forwarding each sub-processing request to the data storage subsystem using the first communication module includes: using the first communication module to determine a first target node device from the multiple cluster node devices according to a first preset positioning rule, and forwarding each sub-processing request to the storage processing module of the first target node device.

[0009] Secondly, this application also 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; the request processing subsystem deploys a driver module implemented based on the UBLK framework; the method includes:

[0010] The system receives a data processing request sent by the request processing subsystem. The data processing request is a request to access a first target block device issued by a target application and received by the driver module in the request processing subsystem. In the first target node device, the system determines the metadata of the first target block device and the target data to be processed according to the data processing request, processes the target data according to the metadata of the first target block device, and obtains a data processing result. The system then returns 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.

[0011] In one embodiment, the data storage subsystem is equipped with a second communication module and a storage service module. Receiving a data processing request from the request processing subsystem includes: receiving the data processing request using the second communication module and sending the data processing request to the storage service module. The data processing request includes multiple sub-processing requests, each sub-processing request requesting the data storage subsystem to process a target data block. The target data block is a portion of the target data. Determining the metadata of the first target block device and the target data to be processed based on the data processing request, and processing the target data based on the metadata of the first target block device to obtain a data processing result, includes: parsing each sub-processing request using the storage service module to determine 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 based on the metadata of the first target block device to obtain a processing result for each sub-processing request, which is used as the data processing result.

[0012] In one embodiment, the storage processing module is further equipped with a metadata management module; 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.

[0013] Thirdly, this application also provides a request processing apparatus for 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; the request processing subsystem deploys a driver module implemented based on the UBLK framework; the apparatus includes:

[0014] The request processing module is used to receive a data processing request from the target application to access the first target block device using the driver module in the request processing subsystem, and forward the data processing request to the data storage subsystem. The data processing request instructs 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, process the target data according to the metadata of the first target block device, obtain the 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 using the driver module.

[0016] In one embodiment, the request processing subsystem further includes a request analysis module and a first communication module. Specifically, the request processing module is configured to: send the data processing request to the request analysis module using the driver module; split the data processing request using the request analysis module 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 forward each sub-processing request to the data storage subsystem using the first communication module.

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

[0018] Fourthly, this application also provides a request processing apparatus 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; the request processing subsystem deploys a driver module implemented based on the UBLK framework; the apparatus includes:

[0019] The request receiving module is used to receive the data processing request sent by the request processing subsystem; the data processing request is a request to access the first target block device issued by the target application and received by the driver module in the request processing subsystem.

[0020] The result forwarding module is used in the first target node device to determine the metadata of the first target block device and the target data to be processed according to the data processing request, and to process the target data according to the metadata of the first target block device to obtain the data processing result; and to 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 embodiment, the data storage subsystem is equipped with a second communication module and a storage service module. The request receiving module is specifically configured to: receive the data processing request using the second communication module 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 requests 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 is specifically configured to: parse each sub-processing request using the storage service module, 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 the processing result for each sub-processing request, which is used as the data processing result.

[0022] In one embodiment, the storage processing module further includes a metadata management module; the device also includes a data update module, configured to: return the data processing result to the second communication module using the storage service module; 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 using the second communication module; and forward the data processing result to the request processing subsystem.

[0023] Fifthly, this application also provides a computer device, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described in any of the first aspects above.

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

[0025] In a seventh aspect, this application also provides a computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0026] The aforementioned request processing method, apparatus, device, and storage medium are used in a request processing subsystem of a 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 receives a data processing request from a target application to access a first target block device and forwards the request to the data storage subsystem. The data processing request instructs the data storage subsystem to determine the metadata of the first target block device and the target data to be processed based on the request, process the target data according to the metadata of the first target block device, obtain the data processing result, and return the data processing result to the request processing subsystem. The driver module then sends the data processing result to the target application. By directly using UBLK to provide block device services on the local host, additional gateway layers and protocol conversions are avoided, significantly reducing the latency of the request processing path. This allows for efficient processing of application block device requests in the distributed block storage system, significantly improving system performance. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

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

[0029] Figure 2 is a flowchart of a request processing method in one embodiment;

[0030] Figure 3 is a flowchart illustrating another request processing method in one embodiment;

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

[0032] Figure 5 is a flowchart illustrating the process of handling a data processing request in one embodiment;

[0033] Figure 6 is a flowchart illustrating the process of determining the data processing result in one embodiment;

[0034] Figure 7 is a flowchart illustrating the recombination process results in one embodiment;

[0035] Figure 8 is a flowchart illustrating the processing of control commands in one embodiment;

[0036] Figure 9 is a schematic diagram of the structure of a distributed block storage system based on UBLK in one embodiment;

[0037] Figure 10 is a flowchart illustrating the processing procedure of a data processing request in one embodiment;

[0038] Figure 11 is a flowchart illustrating the processing of block device control commands in one embodiment;

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

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

[0041] Figure 14 is an internal structure diagram of a computer device in one embodiment. Detailed Implementation

[0042] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that many specific details are set forth in the following description in order to provide a full understanding of this application, but this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of this application. Therefore, this application is not limited to the specific embodiments disclosed below.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0044] It is understood that the term "connection" in the following embodiments should be understood as "electrical connection," "communication connection," etc., if the connected circuits, modules, units, etc., have electrical signal or data transmission with each other.

[0045] It is understandable that "at least one" refers to one or more, and "multiple" refers to two or more. "At least a part of an element" refers to part or all of an element.

[0046] When used herein, the singular forms of “a,” “an,” and “the” may also include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “comprising / including” or “having,” etc., specify the presence of the stated features, wholes, steps, operations, components, parts, or combinations thereof, but do not preclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof. Meanwhile, the term “and / or” as used in this specification includes any and all combinations of the associated listed items.

[0047] With the rapid development of cloud computing and big data, distributed block storage technology is being used more and more widely in data centers. This technology improves data availability, reliability, and performance by distributing data across multiple physical or virtual storage devices. In cloud-native scenarios, block devices are typically provided to containers through containerization protocols. A common approach is to leverage the volume functionality of container runtimes to mount block devices from the host machine into the container, enabling the container to access and use these block devices.

[0048] Currently, the main approach for simulating block devices on the host in distributed block storage systems is to be compatible with existing network transport block device protocols, such as iSCSI, NBD, and NVMe-oF. This approach has the following drawbacks: it requires a gateway layer to be implemented in the distributed storage system to parse and convert various protocol commands, which increases the request processing path, leading to increased latency and potentially making gateway resources a system bottleneck.

[0049] In view of this, embodiments of this application propose a UBLK-based distributed block storage system to create an efficient data path for user-space block device drivers, thereby providing high-performance block device services on the local host.

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

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

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

[0053] The request processing subsystem interfaces with the target application and can receive various requests for block devices issued by the target application. Specifically, since the data processing requests issued by the target application are for block devices, and this request processing subsystem is part of a distributed block storage system, a driver module is deployed in the request processing subsystem. The driver module is implemented based on the UBLK framework. UBLK (User Block Device Driver) is a general framework for implementing block device logic in user space. Its purpose is to move the virtual block driver to 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 block device processing logic, it can receive various requests for the block device from the target application and return the processing results of these requests to the target application. Therefore, the driver module in the request processing subsystem can be used to receive data processing requests from the target application to access the first target block device. In this way, the request processing subsystem can forward the received data processing requests to the data storage subsystem.

[0055] 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, process the target data according to the metadata of the first target block device, obtain the data processing result, and return the data processing result to the request processing subsystem.

[0056] Here, the data storage subsystem is used to manage and store data. It can be deployed on multiple server devices to form a cluster, with each server being a cluster node, or a node device. Each node device is a local host and can be used to store data. In this way, the data storage subsystem utilizes the distributed storage of various types of data across the node devices. To improve the performance of the entire distributed block storage system, this embodiment provides high-performance block device services on the local host. In other words, in this embodiment, the distributed block storage system simulates the storage of data on block devices; it can receive processing requests for block devices and access the distributed block storage system based on these requests, thereby utilizing the high performance of the block devices.

[0057] Since there are multiple node devices, and the data processing request does not access all of them, it is necessary to determine the first target node device. Optionally, the first target node device can be one or more.

[0058] Optionally, the data processing request can be a write request, used to request the writing of the target data to the first target block device; or, the data processing request can also be a read request, used to request the reading of the target data from the first target block device. It is understood 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 based on the data processing request.

[0060] Here, if the data processing request is a write request, then the data processing request includes the metadata of the first target block device and the target data. In the data storage subsystem, various types of data are stored in association with the metadata of their corresponding block devices. Therefore, 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, then the data processing request includes the metadata of the first target block device and the read address of the target data. Therefore, 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. For example, if it is a write request, the data processing result may include whether the write was successful and / or the address of the target data written, etc., although this is not a complete example. If it is a read request, the data processing result may include the target data that was read.

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

[0063] Step 202: Receive the data processing results and use the driver module to send the data processing results to the target application.

[0064] Since the request processing subsystem can interface with the target application through the driver module, the data storage subsystem returns the data processing results to the request processing subsystem, which then returns them to the target application through the driver module.

[0065] In one embodiment, Figure 3 illustrates another request processing method for a data storage subsystem in a distributed block storage system; the method includes:

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

[0067] The data processing request is a request to access 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, the metadata of the first target block device and the target data to be processed are determined according to the data processing request. The target data is then processed according to the metadata of the first target block device to obtain the data processing result. The data processing result is then 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 aforementioned request processing method applied to a distributed block storage system utilizes a driver module in the request processing subsystem to receive data processing requests from the target application to access a first target block device, and forwards these requests to the data storage subsystem. The data storage subsystem, within the first target node device, determines the metadata of the first target block device and the target data to be processed based on the data processing request, processes the target data according to the metadata of the first target block device, obtains the data processing result, and returns the data processing result to the request processing subsystem. The system then receives the data processing result and uses the driver module to send it to the target application. By directly using UBLK to provide block device services on the local host, additional gateway layers and protocol conversions are avoided, significantly reducing latency in the request processing path. This allows for efficient processing of application block device requests in the distributed block storage system, significantly improving system performance. It also enhances data access speed, fully utilizes the computing and network resources of the local host, and provides applications with fast-response block storage capabilities.

[0070] Providing high-performance block device services on a local host using UBLK offers the following advantages: 1. Drivers can be written in multiple programming languages. 2. Libraries not available in the kernel can be used. 3. Debugging can be performed using tools familiar to application developers. 4. Driver crashes do not cause kernel crashes. 5. Errors in user-space code have a smaller impact on system security. 6. Installation and updates can be performed independently of the kernel. 7. Block devices can be easily simulated based on user-specified parameters / settings for testing / debugging purposes. Furthermore, UBLK workloads can be handled by any local host process submitting I / O requests to UBLK block devices or kernel file systems based on UBLK block devices, making it highly suitable for cloud-native scenarios.

[0071] In one alternative implementation, Figure 4 illustrates the structure of another distributed block storage system. The request processing subsystem also includes a request analysis module, a first communication module, and a control command module; the data storage subsystem comprises multiple storage processing modules, each deployed on different cluster node devices; the data storage subsystem also includes 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 distributed block storage systems and their modules can be implemented using software algorithms and deployed on computer devices such as servers.

[0073] In this embodiment, the first and second communication modules enable data forwarding between the two subsystems. Each cluster node device is equipped with a storage processing module, giving each node the ability to process data processing requests, thus improving processing efficiency and convenience. Furthermore, the control command module allows for the processing of control commands issued by the target application to specific block devices. The method will be described below based on this.

[0074] In one embodiment, Figure 5 illustrates a flowchart for processing a data processing request. The request processing subsystem receives a data processing request from a target application to access a first target block device, 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 and the request analysis module communicate with each other, thus enabling the transmission of requests.

[0077] Optionally, both the target application and the data processing subsystem are deployed on computer equipment.

[0078] Optionally, data processing requests issued by the target application of the computer device are received by the driver module and forwarded to the request analysis module after passing through the Block Layer. The Block Layer is an abstraction layer in the Linux kernel used to manage block device I / O operations. It sits between the file system and the block device driver and is responsible for translating file system I / O requests into operations that the block device can understand. Its main function is to translate upper-layer file system requests into lower-layer storage device read and write operations.

[0079] Step 502: The data processing request is split and processed by the request analysis module to obtain multiple sub-processing requests, and each sub-processing request is sent to the first communication module as the data processing result.

[0080] 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.

[0081] For example, each subprocessing request can be used by the data storage subsystem to determine the metadata of the first target block device corresponding to the subprocessing request and the target data block to be processed.

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

[0083] For example, a 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. After splitting the data processing request, the read address of the target data is divided into read addresses of multiple target data blocks. 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, sub-processing requests may include other information, which are not fully exemplified here.

[0085] Optionally, the request analysis module has preset splitting rules, which split the data processing request into multiple sub-processing requests according to the splitting size and splitting boundary set by the splitting rules, and send all sub-processing requests as data processing results to the first communication module.

[0086] Step 503: Use the first communication module to forward each subprocessing request to the data storage subsystem.

[0087] The request processing subsystem interfaces with the data storage subsystem through the first communication module to enable communication between the two. Therefore, the first communication module can be used to forward each subprocessing request to the data storage subsystem.

[0088] In this embodiment, the request processing subsystem can be installed and updated independently of the computer device's kernel, offering greater flexibility and maintainability. Furthermore, users can easily simulate block devices within the computer device based on specified parameters and settings for testing and debugging purposes, enhancing the system's scalability and convenience. The request processing subsystem enables the splitting and forwarding of data processing requests, improving request processing efficiency.

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

[0090] Optionally, the first preset positioning rule can be a rule determined based on polling or a rule determined based on hash lookup, but not all of them are fully exemplified here.

[0091] According to the first preset positioning rule, the first target node device can be determined from the cluster. The first target node device has a storage processing module deployed in it, so it can receive various sub-processing requests.

[0092] In this way, the first target node device for processing the data processing request can be efficiently determined based on preset positioning rules, ensuring the reliability and efficiency of 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. Based on this, Figure 6 illustrates a flowchart for determining a data processing result. Receiving a data processing request sent by the request processing subsystem includes:

[0094] Step 601: Receive the data processing request using the second communication module and send the data processing request to the storage service module.

[0095] As mentioned above, a data processing request includes multiple sub-processing requests, and 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.

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

[0097] Understandably, each cluster node device has a second communication module, which interfaces with 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 uses the second communication module to receive data processing requests.

[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: 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 to obtain the processing result for each sub-processing request, which is used as the data processing result.

[0100] It can parse each sub-processing request.

[0101] For example, if each sub-processing request is a write request, then after parsing, the metadata and target data blocks of the first target block device in each sub-processing request can be determined, resulting in 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. Thus, the metadata and target data blocks of each first target block device can be written to the storage area of ​​the first target node device.

[0102] For example, if each sub-processing request is a read request, then after parsing, the metadata of the first target block device and the read address of the target data block in each sub-processing request can be obtained. 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 at that location can be determined based on the metadata, thereby reading the target data block.

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

[0104] This significantly improves the efficiency of processing target data by processing each target data block simultaneously. It also increases data access speed and fully utilizes the computing and storage resources of the node devices.

[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, for a write request, the data processing result can indicate whether the write was successful or failed, and may also include the address of the data after the write. For a read request, the data processing result includes the target data read, or indicates that the read failed if it failed.

[0107] For example, the metadata management module records the access status information of each block device. Updating the access status information of the first target block device recorded in the metadata management module involves updating it to "accessed successfully" if the data processing result guarantees successful reading or writing. For example, the time of successful access could be updated, but this is not fully illustrated here.

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

[0109] Optionally, the metadata management module records metadata for multiple block devices. The metadata for a block device includes one or more of the following: block device name, block device size, sector size, and snapshot. Additionally, the metadata management module can also record metadata for each cluster node device. The metadata for a cluster node device includes one or more of the following: cluster node device IP address, name, and topology, etc. (A complete example is not provided here.)

[0110] In this way, the distributed block storage system can record access information for each block device in a timely manner, ensuring a complete record of the entire access process, which facilitates calls and queries from upper-layer systems.

[0111] In one embodiment, Figure 7 illustrates a flowchart of a data reassembly process. Receiving the data processing result and sending it to the target application using the driver module includes:

[0112] Step 701: Receive the data processing result using the first communication module and send the data processing result to the request analysis module.

[0113] The data processing results include the processing results of each sub-processing request;

[0114] Step 702: Using the request analysis module, the processing results of each sub-processing request are reassembled according to the preset reassembly rules, and the reassembled processing results are sent to the driver module.

[0115] Understandably, splitting and processing data requests can improve processing efficiency. Once the processing results of each request are received, they need to be reassembled and merged to obtain a complete data processing result.

[0116] Optionally, the preset recombination rule is the reverse of the preset splitting rule. Based on the reverse logic of splitting, the processing results of each request are recombined.

[0117] For example, if it is a write request, the processing result of each sub-processing request is write success and the write address of each target data block. Then, the write addresses of each target data block are concatenated, and the data processing result includes the concatenated complete address and the write success result.

[0118] For example, if it is a read request, the processing result of each sub-processing request includes each target data block. By concatenating the target data blocks, the target data is obtained, and the data processing result includes the target data.

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

[0120] In this way, by implementing block device logic in user space using the UBLK framework, 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 illustrates a flowchart for processing control commands. The method further includes:

[0122] Step 801: Receive control commands issued by the target application for the second target block device using the control command module, determine the metadata of the second target block device based on the control commands, and send the metadata of the second target block device and the control commands to the first communication module.

[0123] The control command module receives a series of control commands from the target application, such as creating, mounting, and deleting block devices. The persistence of the local host block device state relies on the distributed block storage's metadata management module.

[0124] Control commands include at least one of the following: create, delete, expand, mount, stop, and resume. Each control command updates the status information of the corresponding block device in the distributed block storage system.

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

[0126] The control command module can parse the received control commands to obtain the metadata of the second target block device to be controlled by the control command, and then forward all data to the first communication module.

[0127] Step 802: Using the first communication module, the second target node device is determined from multiple cluster node devices according to the second preset positioning rule, and the metadata and control commands of the second target block device are forwarded to the storage processing module of the second target node device.

[0128] Optionally, the second preset positioning rule can be a rule determined based on polling or a rule determined based on hash query, but not all of them are fully exemplified here.

[0129] According to the second preset positioning rule, the second target node device can be determined from the cluster. The second target node device has a storage processing module deployed in it, so it can receive control commands.

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

[0131] For example, if the control command is a create command, the storage processing module can create the 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 created directly, 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 is aware that there is a newly added block device metadata.

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

[0133] In other words, the metadata management module is used to simulate the control processing of the second target block device in order to synchronously update the metadata of the second target block device.

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

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

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

[0137] The execution result indicates whether the execution was successful or not. For example, if the control command is a create command, the execution result can be either creation successful or creation failed.

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

[0139] For example, again taking the creation command as an example, if the execution result indicates that the metadata management module has successfully executed 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-layer system of the distributed block storage system can call this second target block device, enriching the functionality of the distributed block storage system.

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

[0141] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0142] Based on the same inventive concept, this application also provides a distributed block storage system for implementing the request processing method described above. The solution provided by this distributed block storage system is similar to the implementation described in the above method; therefore, the specific limitations in one or more distributed block storage system embodiments provided below can be found in the limitations of the request processing method described 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 data processing requests for accessing the first target block device issued by the target application using the driver module, and forward the data processing requests to the data storage subsystem.

[0145] The data storage subsystem is used in the first target node device to determine the metadata of the first target block device and the target data to be processed according to the data processing request, 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.

[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 further includes a request analysis module and a first communication module; a driver module is used to send a data processing request to the request analysis module; the request analysis module is used to split the data processing request and send the split data processing request to the first communication module; the first communication module is used to forward the split data processing request to the data storage subsystem.

[0148] In one embodiment, the request analysis module is used to split the data processing request into multiple sub-processing requests according to a preset splitting rule based on the target data to be processed in the data processing request, and to 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 the target data block; 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 different cluster node devices; a first communication module is used to determine a first target node device from the 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 split data processing request and send the split data processing request 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; and to process each target data block according to the metadata of the first target block device to obtain the processing result for each sub-processing request, which is used as the data processing result.

[0151] In one embodiment, the storage processing module further includes a metadata management module; the storage service module is also configured to return the data processing result to the second communication module; the second communication module is also configured to, after receiving the data processing result, 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 is also configured to forward the data processing result to the first communication module.

[0152] In one embodiment, the first communication module is further configured to send the data processing result to the request analysis module; the request analysis module is further configured to reassemble the processing results of each sub-processing request according to a preset reassembly rule, and send the reassembled processing result to the driver module; the driver module is configured to send the reassembled processing result to the target application.

[0153] In one embodiment, the request processing subsystem further includes a control command module; the control command module is used to receive a control command issued by the target application for the second target block device, determine the metadata of the second target block device according to the control command, and send the metadata of the second target block device and the control command 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 of the second target block device and the control command to the storage processing module of the second target node device.

[0154] In one embodiment, the second communication module is used to receive the 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 commands and the metadata of the second target block device.

[0155] In one embodiment, the first communication module is further configured 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 configured to process the second target block device in the request processing subsystem according to the control command if the execution result indicates that the metadata management module has successfully executed the control command.

[0156] For ease of understanding, the following description uses a complete embodiment to illustrate a UBLK-based distributed block storage system provided in this application. As shown in Figure 9, the UBLK-based distributed block storage system is the same as the distributed block storage system described above, including a client subsystem and a distributed block storage cluster subsystem. The client subsystem is the same as the request processing subsystem described above, and the distributed block storage cluster subsystem is the same as the data storage subsystem described above. The client subsystem and the distributed block storage cluster subsystem communicate and connect using a custom protocol.

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

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

[0159] User-mode driver module: It splits the IO requests issued by the kernel driver module according to the fragment size and fragment boundary and then 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 sent by the local host application, such as creating, mounting, and deleting block devices.

[0161] Communication protocol module: Receives IO requests from the user-space 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-space driver module.

[0162] Communication protocol module: Receives IO requests from the client subsystem and delivers them to the storage service module; it 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 information such as block device size and cluster node IP.

[0164] Storage service module: Writes write I / O requests to disk; reads data from read I / O requests.

[0165] Figure 10 illustrates the processing flow of a data processing request issued by an application:

[0166] 1. I / O requests issued by applications on the local host are received by the kernel driver module and forwarded to the user-space driver module after passing through the Block Layer.

[0167] 2. The user-space driver module receives I / O requests from the kernel driver module and processes them using its specific block service logic. Specifically, the user-space driver module is responsible for splitting the I / O requests according to the fragment size and fragment boundaries, and then passing the split I / O requests 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 IO requests to that server. The rules can be round-robin or hash-based, and the form is not limited.

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

[0170] 5. The storage service module handles I / O requests, writing / reading data from the disk. Upon 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-space driver module receives all the split IO processing results, reassembles the IO according to the IO splitting rules, and returns it to the kernel driver module.

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

[0175] 10. The application harvests the results of I / O processing.

[0176] Figure 11 illustrates the processing flow of block device control commands issued by the application:

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

[0178] Each control command updates the status information of the corresponding block device in the distributed storage cluster subsystem. Mounting, stopping, and resuming not only require updating the block device's status information but also necessitate executing the corresponding operations on the kernel driver module on the local host.

[0179] 2. The control command module receives and parses control commands, generates corresponding block device metadata information, and transmits 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 rules and transmits control commands and metadata. The rules can be round-robin or hash-based, and the format is not limited.

[0181] 4. The communication protocol module of the distributed block storage cluster subsystem receives control commands 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 results.

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

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

[0185] 8. The control command module retrieves the return results of control commands and metadata. If the return result is a failure, it returns to the local application that the control command failed to execute; otherwise, it executes the corresponding control command. For example, if the block device creation control command is executed, the corresponding block device will be created in the client subsystem.

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

[0187] This application aims to provide a high-performance distributed block storage system that enables local hosts to efficiently provide block device services, thereby meeting the ever-growing and changing storage demands in cloud computing and big data environments and addressing the shortcomings of current distributed block storage technologies. Specifically, it focuses on improving the ability of local hosts to provide block device services and optimizing the performance of the distributed block device system, including the following aspects:

[0188] Improving System Performance: Existing distributed block storage solutions require a gateway layer in the distributed storage system, which increases I / O path latency and leads to performance degradation. In this embodiment, by directly using UBLK to provide block device services on the local host, the additional gateway layer and protocol conversion are avoided, significantly reducing I / O path latency and thus significantly improving system performance.

[0189] High-efficiency local host block device services: By implementing block device logic in user space using the UBLK framework, the virtual block driver is moved to user space, creating an efficient data path for the user-space block device driver. This enables the local host to efficiently provide block device services, improving data access speed and fully utilizing the host's computing and storage resources. It eliminates the dependence on custom clients or compatible network transport protocols, simplifying client driver development and management, and reducing system complexity.

[0190] Simplified 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 for client kernel modules are lowered. User-space driver development can utilize various programming languages ​​and tools, simplifying the development and debugging process and enhancing system flexibility.

[0191] Improved system stability and security: Crashes in user-mode drivers do not lead to kernel crashes, thus improving system stability. At the same time, errors in user-mode code have a smaller impact on system security, enhancing overall system security.

[0192] Enhanced flexibility and maintainability: User-space block device drivers can be installed and updated independently of the kernel, offering greater flexibility and maintainability. Furthermore, users can easily simulate block devices with specified parameters and settings for testing and debugging purposes, improving system scalability and convenience.

[0193] Based on the same inventive concept, this application also provides a request processing apparatus for implementing the request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more request processing apparatus embodiments provided below can be found in the limitations of the request processing method described above, and will not be repeated here.

[0194] In one embodiment, as shown in FIG12, a request processing apparatus 1200 is provided, comprising: 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 the first target block device issued by the target application using the 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, process the target data according to the metadata of the first target block device, obtain the 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 results and send the data processing results to the target application using the driver module.

[0197] In one embodiment, the request processing subsystem further includes a request analysis module and a first communication module. The request processing module 1201 is specifically configured to: send a data processing request to the request analysis module using the driver module; split the data processing request using the request analysis module 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 a target data block; the target data block is a part of the target data; and forward each sub-processing request to the data storage subsystem using the first communication module.

[0198] In one embodiment, the data storage subsystem includes multiple storage processing modules, each of which is deployed in different cluster node devices; the request processing module 1201 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.

[0199] In one embodiment, as shown in FIG13, another request processing apparatus is provided. The request processing apparatus 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 to access the first target block device issued by the target application and received by the driver module in the request processing subsystem.

[0201] The result forwarding module 1302 is used in the first target node device to determine the metadata of the first target block device and the target data to be processed according to the data processing request, and to process the target data according to the metadata of the first target block device to obtain the data processing result; and to 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 embodiment, the data storage subsystem is equipped with a second communication module and a storage service module. The request receiving module 1301 is specifically configured to: receive a data processing request using the second communication module 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 requests the data storage subsystem to process a target data block; the target data block is a portion of the target data; the result forwarding module 1302 is specifically configured to: parse each sub-processing request using the storage service module, 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 the processing result for each sub-processing request, which serves as the data processing result.

[0203] In one embodiment, the storage processing module further includes a metadata management module; the apparatus also includes a data update module for: returning the data processing result to the second communication module using the storage service 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.

[0204] Each module in the aforementioned request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0205] In one embodiment, a computer device, which may be a server, is provided, and its internal structure can be as shown in Figure 14. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes non-volatile storage media and internal memory. The non-volatile storage media stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device stores request processing data. The I / O interfaces of the computer device are used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a request processing method.

[0206] Those skilled in the art will understand that the structure shown in Figure 14 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or may combine certain components, or may have different component arrangements.

[0207] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0208] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0209] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0210] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media 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), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0211] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A request processing method, characterized in that, A request processing subsystem for a distributed block storage system; the distributed block storage system includes the request processing subsystem and a data storage subsystem; the request processing subsystem includes a request analysis module; The request processing subsystem deploys a driver module based on the UBLK framework. The method includes: receiving a data processing request from a target application to access a first target block device using the driver module in the request processing subsystem, and forwarding the data processing request to the data storage subsystem; the data processing request instructs 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 returning the data processing result to the request processing subsystem; wherein, the request analysis module splits the data processing request into multiple sub-processing requests according to the shard size and shard boundary set by the preset splitting rules, so as to send all sub-processing requests to the data storage subsystem; 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; receiving the data processing result, and sending the data processing result to the target application using the driver module.

2. The method according to claim 1, characterized in that, The request processing subsystem further includes a request analysis module and a first communication module. The step of receiving a data processing request from a target application to access a first target block device using the driver module in the request processing subsystem, and forwarding the data processing request to the data storage subsystem, includes: 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 into multiple sub-processing requests, and sending each sub-processing request as the data processing result to the first communication module; and using the first communication module to forward each sub-processing request to the data storage subsystem.

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

4. A request processing method, characterized in that, A data storage subsystem for a distributed block storage system; the distributed block storage system includes a request processing subsystem for performing the request processing method as described in any one of claims 1 to 3 and the data storage subsystem; The request processing subsystem deploys a driver module based on the UBLK framework; the method includes: receiving a data processing request sent by the request processing subsystem; the data processing request is a request to access a first target block device issued by a target application and received by the driver module in the request processing subsystem; in the first target node device, 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; and returning 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.

5. The method according to claim 4, characterized in that, The data storage subsystem is equipped with a second communication module and a storage service module. Receiving a data processing request from the request processing subsystem includes: receiving the data processing request using the second communication module 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 requests the data storage subsystem to process a target data block; the target data block is a portion of the target data; determining the metadata of the first target block device and the target data to be processed based on the data processing request, and processing the target data based on the metadata of the first target block device to obtain a data processing result includes: parsing each sub-processing request using the storage service module to determine 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 based on the metadata of the first target block device to obtain a processing result for each sub-processing request, which is used as the data processing result.

6. The method according to claim 5, characterized in that, The data storage subsystem also includes a metadata management module; 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.

7. A request processing apparatus, characterized in that, A request processing subsystem for a distributed block storage system; the distributed block storage system includes the request processing subsystem and a data storage subsystem. The request processing subsystem deploys a driver module based on the UBLK framework. The device includes: a request processing module, used to receive a data processing request from a target application to access a first target block device using the driver module in the request processing subsystem, and forward the data processing request to the data storage subsystem; the data processing request instructs 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 to return the data processing result to the request processing subsystem; wherein; the request analysis module uses a preset splitting rule to split the data processing request into multiple sub-processing requests according to the shard size and shard boundaries, and sends all sub-processing requests to the data storage subsystem; each sub-processing request requests the data storage subsystem to process a target data block; the target data block is a part of the target data; and a result processing module, used to receive the data processing result and send the data processing result to the target application using the driver module.

8. A request processing apparatus, characterized in that, A data storage subsystem for a distributed block storage system; the distributed block storage system includes a request processing subsystem for performing the request processing method as described in any one of claims 1 to 3 and the data storage subsystem; The request processing subsystem deploys a driver module based on the UBLK framework; the device includes: a request receiving module, used to receive a data processing request sent by the request processing subsystem; the data processing request is a request to access a first target block device issued by a target application and received by the driver module in the request processing subsystem; a result forwarding module, used in the first target node device to determine the metadata of the first target block device and the target data to be processed 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 to 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, it implements the steps of the method according to any one of claims 1 to 6.

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

Images