A data redundancy method and device for distributed key-value storage based on block data duplication

Abstract

The application discloses a kind of data redundancy method and device based on block data copy distributed key-value storage, belong to computer storage technical field.The data redundancy method includes: receiving the key-value request of user, the hash value of the key corresponding to key-value request is calculated, the corresponding primary copy key-value storage instance is determined according to hash value, and key-value request is forwarded to the corresponding primary copy key-value storage instance;Key-value index interface is called by key-value storage instance, and key-value request is converted into block device read-write request;Block device read-write request is submitted to block device drive engine, and it is judged whether block device read-write request is write request or read request;If it is write request, then generate copy and write on local and remote copy disk;If it is read request, then corresponding block data is read from local or remote copy disk.Implementation reduces CPU overhead, and the beneficial effect of improving system performance and maintainability.

Description

Technical Field

[0001] This invention belongs to the field of computer storage technology, and more specifically, relates to a data redundancy method and apparatus for distributed key-value storage based on block data replication. Background Technology

[0002] Key-value storage is an important form of modern data storage. Its core idea is to store data as key-value pairs (KV) in a key-value index, allowing for quick retrieval of the corresponding value by key. Key-value indexes can be implemented in various ways, such as Log-Structured Merge Tree (LSM-tree), B+Tree, Hash Index, and Skip List. Each implementation has its own advantages and disadvantages and is suitable for different application scenarios.

[0003] Key-value indexes essentially translate key-value requests into requests to the underlying file system or block device. In modern computer systems, file systems and block devices are two core abstractions for persistent data storage. Block devices provide low-level access to storage hardware, while file systems are a high-level abstraction built on top of block devices, designed to provide users and applications with a more intuitive and structured way of organizing data. Block devices use fixed-size logical blocks (such as 512 bytes or 4KB) as the smallest unit of read and write operations, providing a linear address space through logical block addresses (LBAs). This abstraction shields the complexity of the hardware, providing a stable interface to upper-level systems. However, directly manipulating block devices is too complex for applications. To address this issue, file systems were introduced on top of block devices. File systems provide users with a simple and unified read / write interface and data view by organizing files and directories, managing metadata, and coordinating data block allocation.

[0004] To support large-scale applications, key-value stores are typically deployed in a distributed architecture, distributing data across multiple nodes to form a distributed key-value storage system. To ensure system service availability and data reliability, distributed key-value storage systems usually employ a replication-based data redundancy mechanism, storing the same data on different nodes. This way, if one node fails or loses data, other nodes can still provide service and guarantee no data loss.

[0005] Existing data redundancy mechanisms based on replication are all implemented using key-value replication. Specifically, after a client receives a write key-value request from a user, it first sends the request to the primary replica key-value store instance via Remote Procedure Call (RPC). The primary replica key-value store instance then replicates the key-value request into k-1 copies (where k is a preset replication factor) and distributes them to the corresponding k-1 secondary replica key-value store instances via RPC. Each key-value store instance maintains its own key-value index structure and writes to disk independently.

[0006] However, existing technologies suffer from overhead issues with RPC-based key-value copy mechanisms, including increased index space, redundant calculations in background tasks, and inefficient foreground writes. Summary of the Invention

[0007] To address the shortcomings of related technologies, the present invention aims to provide a data redundancy method and apparatus for distributed key-value storage based on block data replication, which aims to solve the overhead problems of existing RPC-based key-value replication mechanisms, including index space amplification, redundant calculation of background tasks, and inefficient foreground writes.

[0008] To achieve the above objectives, in a first aspect, the present invention provides a data redundancy method for distributed key-value storage based on block data replication, comprising: S100: Receive a user's key-value request, calculate the hash value of the key corresponding to the key-value request, determine the corresponding primary replica key-value storage instance based on the hash value, and forward the key-value request to the corresponding primary replica key-value storage instance. S200: The key-value storage instance calls the key-value index interface to convert the key-value request into a block device read / write request; S300: Submit the block device read / write request to the block device driver engine and determine whether the block device read / write request is a write request or a read request; if it is a write request, generate a copy and write it to the local and remote copy disks; if it is a read request, read the corresponding block data from the local or remote copy disk.

[0009] Optionally, step S100 specifically includes: S110, Receive key-value requests generated by users through the key-value interface; S120. Calculate the hash value of the key corresponding to the key-value request using a hash function; S130. Perform modulo operation on the calculated hash value, and determine the primary replica key-value storage instance corresponding to the key-value request based on the modulo result; encapsulate the key-value request into an RPC message using RPC technology, and forward it to the RPC server of the node where the corresponding primary replica key-value storage instance is located.

[0010] Optionally, step S200 specifically includes: S210. The RPC server parses the RPC message, extracts the target key value, and calls the key value index interface in the storage instance of the target key value. S220. Submit the key value request to the key value index through the key value index interface, and convert the key value request into a read / write request for the block device through the key value index; The key-value index uses B+ Tree, learned index, LSM-tree, Trie, Radix Tree, HashTable, append-only log index, or hybrid index; the key-value index adopts the method of directly managing the block device LBA space.

[0011] Optionally, when the key-value index uses an LSM-tree, step S220 specifically includes: S221. When the block device read / write request is a write request, the key-value request is first written to the write-ahead log (WAL) and then written to the Memtable located in memory. When the Memtable reaches a set threshold, its content is refreshed to an SSTable and persisted. S222. When the block device read / write request is a read request, check if a key-value pair for the key exists in the Memtable. If it exists, return the result directly; if it does not exist, continue searching the SSTable at each level. In the key-value persistence writing process of the front end in S221, distributed write caching technology is used to write key-value data to the local memory buffer, and at the same time, it is synchronously copied to the pre-configured memory buffer of the remote node through RDMA technology.

[0012] Optional, also includes: In the background, the key-value index uses a merge operation to reclaim invalid data and keep the data ordered; during the merge process, the new SSTable generated generates a block data copy by calling the interface of the block device driver engine.

[0013] Optionally, step S300 specifically includes: S310. Submit the block device read / write request to the block device driver engine and determine whether the block device read / write request is a write request or a read request; if it is a write request, proceed to S320; if it is a read request, proceed to S330. S320. The block device driver engine replicates and sends write requests to all configured replica block devices according to the pre-configured replica policy. S330. If it is a read request, the block device driver engine detects the current access load of all block device nodes that store the key value replica, and selects the replica node with the lightest load as the data source based on the load balancing algorithm, and sends a read request to it.

[0014] Optionally, for reading and writing to the remote replica disk, NVMe-oF technology is used as the underlying remote block device access protocol.

[0015] In a second aspect, the present invention also provides a data redundancy apparatus for a distributed key-value store based on block data replicas, used to perform the data redundancy method for a distributed key-value store based on block data replicas as described in any one aspect, comprising: The first module is used to receive a user's key-value request, calculate the hash value of the key corresponding to the key-value request, determine the corresponding primary replica key-value storage instance based on the hash value, and forward the key-value request to the corresponding primary replica key-value storage instance. The second module is used to call the key-value index interface through the key-value storage instance to convert the key-value request into a block device read / write request; The third module is used to submit the block device read / write request to the block device driver engine, and determine whether the block device read / write request is a write request or a read request; if it is a write request, a copy is generated and written to the local and remote copy disks; if it is a read request, the corresponding block data is read from the local or remote copy disk.

[0016] Compared with the prior art, the above-described technical solutions conceived in this invention can achieve the following beneficial effects: 1. This invention provides a data redundancy method for distributed key-value storage based on block data replicas. It replaces the original data redundancy scheme based on key-value replicas with data redundancy achieved by block data replicas. The block data replica approach avoids the index space amplification problem caused by maintaining redundant key-value replicas in the remote key-value index, reduces the additional CPU overhead caused by repeated calculations, effectively optimizes the performance loss introduced by the multi-layer software stack during the front-end write process, and improves system performance and maintainability.

[0017] 2. This invention provides a data redundancy method for distributed key-value storage based on block data replicas. The distributed key-value storage system directly manages the LBA space of the block device in the key-value index, bypassing the file semantic organization of data in traditional file systems, thereby reducing the additional latency caused by file system processing. Simultaneously, this method supports remote nodes directly identifying block data replicas without relying on file system metadata synchronization, further improving system performance and maintainability. A distributed write cache design is introduced into the key-value index, effectively solving the problem of mismatch between the granularity of key-value requests and the sector size of the block device, avoiding the performance degradation caused by directly exposing the block interface to key-value requests, and improving the efficiency and resource utilization of the write path. Attached Figure Description

[0018] Figure 1 This invention provides an overall flowchart of a data redundancy method for distributed key-value storage based on block data replicas.

[0019] Figure 2 This invention provides an overall architecture diagram of distributed key-value storage in a data redundancy method based on block data replicas. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0021] The following description, in conjunction with a preferred embodiment, illustrates the content involved in the above embodiments.

[0022] like Figure 1 As shown, this invention provides a data redundancy method for distributed key-value storage based on block data replication, comprising: S100: Receive a user's key-value request, calculate the hash value of the key corresponding to the key-value request, determine the corresponding primary replica key-value storage instance based on the hash value, and forward the key-value request to the corresponding primary replica key-value storage instance. S200: The key-value storage instance calls the key-value index interface to convert the key-value request into a block device read / write request; S300: Submit the block device read / write request to the block device driver engine and determine whether the block device read / write request is a write request or a read request; if it is a write request, generate a copy and write it to the local and remote copy disks; if it is a read request, read the corresponding block data from the local or remote copy disk.

[0023] To address the shortcomings of existing technologies, this invention provides a data redundancy method for distributed key-value storage based on block data replicas. It improves the structure of the key-value index engine itself by removing the underlying file system and adding a new NVMe-oF driver layer for handling NVMe-oF requests and load balancing. The original key-value replica-based data redundancy scheme is replaced with block data replicas for data redundancy. Figure 2 As shown, the block device LBA space is directly managed in the key-value index to support remote nodes in quickly identifying block data replicas. The conversion efficiency of key-value-based replicas is much lower than that of block data-based replicas. Implementing replicas at the block layer eliminates the need to maintain key-value replicas on multiple nodes' key-value indexes, thus avoiding the aforementioned problems of key-value index space amplification and redundant computation within the index. Writing replicas directly at the block layer, compared to sending key-value replicas via RPC, bypasses the processing of the RPC, key-value index, and file system software stack, thereby solving the performance limitations of the foreground write operations. Furthermore, the use of distributed write caching technology avoids performance degradation caused by key-value write requests directly calling the block device interface.

[0024] The key-value store client receives key-value requests from users and forwards them to the designated primary replica key-value store instance using a consistent hashing algorithm based on the key in the request, thus resolving consistency conflicts among multiple clients. After being forwarded to the designated key-value store instance, the key-value request is processed to calculate the key-value index, transforming the request into a read / write request for the block device. Based on the replica configuration and the calculation results of algorithms such as load balancing, read / write operations are performed on the local or remote replica disk device.

[0025] Optionally, step S100 specifically includes: S110, Receive key-value requests generated by users through the key-value interface; S120. Calculate the hash value of the key corresponding to the key-value request using a hash function; S130. Perform modulo operation on the calculated hash value, and determine the primary replica key-value storage instance corresponding to the key-value request based on the modulo result; encapsulate the key-value request into an RPC message using RPC technology, and forward it to the RPC server of the node where the corresponding primary replica key-value storage instance is located.

[0026] Users send key-value requests to the key-value client for processing by calling the key-value interface provided by the key-value storage client. Commonly used hash functions include, but are not limited to: MD5, SHA-1, MurmurHash, and CityHash.

[0027] In different embodiments, consistent hashing algorithms can be adopted according to different application scenario requirements. This embodiment uses MurmurHash as an example to illustrate how the hash value of the requested key is calculated using the Murmurhash hash function. The consistent hashing algorithm then determines which primary replica key-value storage instance the key should be sent to. Consistent hashing is an algorithm used in distributed scenarios to determine forwarding nodes and their service programs, resolving consistency conflicts in multi-client requests while achieving load balancing as much as possible. A simplified implementation of consistent hashing involves taking the modulo of the hash value with the total number of service programs to be forwarded, and then forwarding the request to the corresponding node and its service program based on the modulo result.

[0028] For example, the primary replica key-value instance is calculated using a modulo operation. Assume there are currently 3 physical nodes, each running 2 key-value storage instances, and each key-value storage instance maintaining a key-value index. These key-value storage instances are pre-numbered, starting from 0: the storage instances on the first physical node are numbered 0 and 1; the key-value storage instances on the second physical node are numbered 2 and 3, and so on. The hash value obtained after hashing the user key-value is 2^17. Taking the modulo of 2^17 with 6 yields 1, so it is sent to the key-value storage instance numbered 1, which is the second key-value storage instance on the first physical node.

[0029] Optionally, step S200 specifically includes: S210. The RPC server parses the RPC message, extracts the target key value, and calls the key value index interface in the storage instance of the target key value. S220. Submit the key value request to the key value index through the key value index interface, and convert the key value request into a read / write request for the block device through the key value index; The key-value index uses B+ Tree, learned index, LSM-tree, Trie, Radix Tree, HashTable, append-write log index, or hybrid index; the key-value index adopts the method of directly managing the block device LBA space.

[0030] Furthermore, key-value indexes can employ different algorithms based on the needs of different application scenarios. For example, B+ Tree or learned indexes can be used in scenarios with frequent reads, while LSM-tree can be used in scenarios with frequent writes.

[0031] After the key-value index interface is invoked, the key-value index module will process it according to its internal logic. This process involves converting the key-value request into an access request to the block device and then submitting it. The specific processing logic may differ depending on the type of key-value index. The internal organization of the key-value index is designed to directly maintain the mapping relationship between key values ​​and block device LBAs (Logical Block Addresses).

[0032] Traditional key-value index implementations typically organize persistent data through a file system for ease of deployment and sharing of storage resources with other applications. This involves mapping key-value pairs to files, with the file system managing the underlying block device space. However, this design introduces processing overhead from the file system itself, impacting performance. Furthermore, when using block-based data replication for redundancy, the file system cannot recognize these replicas because they are generated at the block level, bypassing the file system. Consequently, the key-value index structure built on the file system cannot recognize or recover this data.

[0033] To address the aforementioned issues and improve the identifiability and effectiveness of replica data, especially in scenarios where remote nodes need to recover the index from replicas, the system has adjusted the organization of the key-value index. It now directly records the mapping between key values ​​and block device LBA addresses. This mapping is achieved through a block device address space management algorithm. Specifically, when the key-value index is an LSM-tree, WAL writes allocate address space via append writes, metadata allocates address space via a circular log queue, and SSTable allocates address space via a free list. This approach avoids dependence on the file system, allowing remote nodes to identify replicas and recover the complete key-value index without file system intervention.

[0034] Optionally, when the key-value index uses an LSM-tree, step S220 specifically includes: S221. When the block device read / write request is a write request, the key-value request is first written to the write-ahead log (WAL) and then written to the Memtable located in memory. When the Memtable reaches a set threshold, its content is refreshed to an SSTable and persisted. S222. When the block device read / write request is a read request, check if a key-value pair for the key exists in the Memtable. If it exists, return the result directly; if it does not exist, continue searching the SSTable at each level. In the key-value persistence writing process of the front end in S221, distributed write caching technology is used to write key-value data to the local memory buffer, and at the same time, it is synchronously copied to the pre-configured memory buffer of the remote node through RDMA technology.

[0035] In this embodiment, taking an LSM-tree key-value index as an example, when a key-value write request is submitted, it is first written to the Write-Ahead Log (WAL), and then written to the MemTable located in memory. When the MemTable reaches a set threshold, its contents are flushed to an SSTable file and persisted.

[0036] Specifically, for writing to the WAL, the data is first written to the distributed write cache. Once the write cache is full (the block device sector size is reached), the block device driver engine interface is called. For writing to the SSTable, since the data is already a large block of data assembled from the Memtable, the block device driver engine interface is called directly. For read operations, the system first checks if a key-value pair with the given key exists in the Memtable. If it exists, the result is returned directly; otherwise, the system continues searching each level of the SSTable.

[0037] Throughout the process, write requests are gradually transformed into file system write operations, and finally into write requests to the block device, which are then written to the physical disk.

[0038] Furthermore, a distributed write caching technique is introduced during the key-value persistent writing process in the key-value index processing (for LSM-trees, this is the WAL writing process). There is a granularity mismatch between the data size of the key-value itself (averaging about 100 bytes in Meta's actual production environment) and the sector size of the block device (typically 4KB). Since the sector size of the block device is the smallest unit of writing, if each key-value write request calls the block interface individually for persistence, it will cause performance and space efficiency issues. Writing according to sector alignment will result in a significant waste of storage space. Writing directly at the size of the key-value itself requires a "read-modify-write" mechanism, introducing additional latency and degrading overall write performance. Therefore, when a key-value write request needs to be written to disk, the system prioritizes writing it to a buffer maintained internally by the key-value index. Only when the accumulated data in the buffer reaches the block device sector size will the block interface be called uniformly to complete the batch write, thereby improving storage efficiency while reducing the performance loss caused by write amplification. Simultaneously, to ensure the high reliability of the distributed key-value storage system, this write cache adopts a distributed design. In other words, key-value data is not only written to the local memory buffer, but also synchronously copied to the pre-configured memory buffer on the remote node through RDMA technology, thereby enhancing the system's disaster recovery capabilities and data consistency assurance.

[0039] The advantages of using distributed write caching technology during foreground persistent writes of key-value indexes are as follows: First, this technology avoids the problem of calling the block device interface separately for each key-value write request, thus avoiding the performance degradation caused by the mismatch between the key-value data granularity and the block device sector size. Second, since the write cache is based on memory media, its read and write speeds are faster than traditional persistent storage devices, effectively improving foreground write performance. Furthermore, distributed write caching reduces the risk of single points of failure by replicating write data to memory buffers on multiple nodes. Even if one node loses power or fails, other nodes can still retain cached data, enhancing the system's disaster recovery capabilities and data consistency guarantees.

[0040] Optional, also includes: In the background, the key-value index uses a merge operation to reclaim invalid data and keep the data ordered; during the merge process, the new SSTable generated generates a block data copy by calling the interface of the block device driver engine.

[0041] Some key-value index internal operations can trigger write amplification, meaning a single user write request may trigger multiple write operations to the block device. For example, LSM-tree indexes rely on compaction operations to reclaim invalid data and maintain data order. During compaction, data from the old SSTable may be rewritten into the new SSTable, leading to write amplification. These additional write operations must also adhere to data redundancy mechanisms: by calling the block device driver engine's interface, the driver engine generates data block replicas and writes them to both local and remote replica disks.

[0042] Optionally, step S300 specifically includes: S310. Submit the block device read / write request to the block device driver engine and determine whether the block device read / write request is a write request or a read request; if it is a write request, proceed to S320; if it is a read request, proceed to S330. S320. The block device driver engine replicates and sends write requests to all configured replica block devices according to the pre-configured replica policy. S330. If it is a read request, the block device driver engine detects the current access load of all block device nodes that store the key value replica, and selects the replica node with the lightest load as the data source based on the load balancing algorithm, and sends a read request to it.

[0043] In this embodiment, to achieve efficient read and write operations to the remote replica disk, NVMe over Fabrics (NVMe-oF) technology is used as the underlying remote block device access protocol. NVMe-oF is a protocol standard specifically designed for accessing remote NVMe storage devices. Its design goal is to retain the high-performance characteristics of the native NVMe protocol in a network environment while extending its capabilities for distributed storage systems. By supporting multiple underlying network architectures such as RDMA, TCP, or FC, NVMe-oF enables cross-node, low-latency, and high-bandwidth block device access. In traditional systems, remote block device access typically relies on shared storage solutions such as iSCSI, NFS, or file system-based solutions. While these solutions achieve remote data access, they are not designed for modern high-speed storage hardware and have significant limitations in protocol processing, transmission efficiency, and concurrency capabilities, often becoming system performance bottlenecks. Especially in distributed key-value storage scenarios with high concurrency and low latency requirements, traditional access methods struggle to fully utilize the underlying hardware performance. In contrast, NVMe-oF has significant advantages in several aspects. First, it employs a lightweight protocol stack and an efficient command submission / completion queue mechanism, continuing the high-performance design of native NVMe, and minimizing data overhead during transmission through mechanisms such as zero-copy and user-space access. Second, NVMe-oF supports multi-channel concurrent access, fully leveraging multi-core processor resources to improve system throughput. Therefore, in this design, the block device driver engine accesses remote replica disks via NVMe-oF channels, enabling write or read requests derived from key-value indexes to be efficiently transmitted to remote nodes at the block level. This ensures consistency and reliability while achieving low latency and high performance requirements for cross-node data replica access.

[0044] The advantages of using NVMe-oF as the underlying remote block device access method are twofold. First, it employs a lightweight protocol stack and an efficient command submission / completion queue mechanism, continuing the high-performance design of local NVMe, and minimizing data overhead during transmission through mechanisms such as zero-copy and user-space access. Second, NVMe-oF supports multi-channel concurrent access, fully utilizing multi-core processor resources and improving system throughput.

[0045] This invention replaces the original key-value replica-based data redundancy scheme with block data replicas. This block-data replica approach avoids the index space amplification problem caused by maintaining redundant key-value replicas in the remote key-value index, reduces the additional CPU overhead from redundant calculations, and effectively optimizes the performance loss introduced by the multi-layered software stack during foreground writes. The distributed key-value storage system directly manages the block device LBA space in the key-value index, bypassing the file semantic organization of data in the traditional file system, thereby reducing the additional latency caused by file system processing. Simultaneously, this approach allows remote nodes to directly identify block data replicas without relying on file system metadata synchronization, further improving system performance and maintainability. It solves the overhead problems of existing RPC-based key-value replica mechanisms, including index space amplification, redundant background task calculations, and inefficient foreground writes. It achieves the beneficial effects of reducing performance loss, reducing latency, and improving system performance and maintainability.

[0046] Example 2 The present invention also provides a data redundancy apparatus for a distributed key-value store based on block data replicas, used to perform the data redundancy method for a distributed key-value store based on block data replicas as described in any one of Embodiments 1, comprising: The first module is used to receive a user's key-value request, calculate the hash value of the key corresponding to the key-value request, determine the corresponding primary replica key-value storage instance based on the hash value, and forward the key-value request to the corresponding primary replica key-value storage instance. The second module is used to call the key-value index interface through the key-value storage instance to convert the key-value request into a block device read / write request; The third module is used to submit the block device read / write request to the block device driver engine, and determine whether the block device read / write request is a write request or a read request; if it is a write request, a copy is generated and written to the local and remote copy disks; if it is a read request, the corresponding block data is read from the local or remote copy disk.

[0047] The present invention provides a data redundancy device for distributed key-value storage based on block data replicas, which is used to execute a data redundancy method for distributed key-value storage based on block data replicas and has the same or similar beneficial effects.

[0048] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A data redundancy method for distributed key-value storage based on block data replication, characterized in that, include: S100: Receive a user's key-value request, calculate the hash value of the key corresponding to the key-value request, determine the corresponding primary replica key-value storage instance based on the hash value, and forward the key-value request to the corresponding primary replica key-value storage instance. S200: The key-value storage instance calls the key-value index interface to convert the key-value request into a block device read / write request; S300: Submit the block device read / write request to the block device driver engine and determine whether the block device read / write request is a write request or a read request; If it is a write request, a copy is generated and written to the local and remote copy disks; If it is a read request, the corresponding block data is read from the local or remote replica disk; Specifically, step S100 includes: S110, Receive key-value requests generated by users through the key-value interface; S120. Calculate the hash value of the key corresponding to the key-value request using a hash function; S130. Perform modulo operation on the calculated hash value, determine the primary replica key-value storage instance corresponding to the key-value request based on the modulo result; encapsulate the key-value request into an RPC message using RPC technology, and forward it to the RPC server of the node where the corresponding primary replica key-value storage instance is located; Step S200 specifically includes: S210. The RPC server parses the RPC message, extracts the target key value, and calls the key value index interface in the storage instance of the target key value. S220. Submit the key value request to the key value index through the key value index interface, and convert the key value request into a read / write request for the block device through the key value index; The key-value index uses B+ Tree, learned index, LSM-tree, Trie, Radix Tree, HashTable, append-only log index, or hybrid index; the key-value index adopts the method of directly managing the block device LBA space.

2. The method as described in claim 1, characterized in that, When the key-value index uses an LSM-tree, step S220 specifically includes: S221. When the block device read / write request is a write request, the key-value request is first written to the write-ahead log (WAL) and then written to the Memtable located in memory. When the Memtable reaches a set threshold, its content is refreshed to an SSTable and persisted. S222. When the block device read / write request is a read request, check if a key-value pair for the key exists in the Memtable. If it exists, return the result directly; if it does not exist, continue searching the SSTable at each level. In the key-value persistence writing process of the front end in S221, distributed write caching technology is used to write key-value data to the local memory buffer, and at the same time, it is synchronously copied to the pre-configured memory buffer of the remote node through RDMA technology.

3. The method as described in claim 2, characterized in that, Also includes: In the background, the key-value index uses a merge operation to reclaim invalid data and maintain data order. During the merge process, the resulting new SSTable calls the block device driver engine's interface to generate a copy of the block data.

4. The method as described in claim 1, characterized in that, Step S300 specifically includes: S310. Submit the block device read / write request to the block device driver engine and determine whether the block device read / write request is a write request or a read request; if it is a write request, proceed to S320; if it is a read request, proceed to S330. S320. The block device driver engine replicates and sends write requests to all configured replica block devices according to the pre-configured replica policy. S330. The block device driver engine detects the current access load of all block device nodes that store key-value replicas, and selects the replica node with the lightest load as the data source based on the load balancing algorithm, and sends a read request to it.

5. The method as described in claim 4, characterized in that, For reading and writing to remote replica disks, NVMe-oF technology is used as the underlying remote block device access protocol.

6. A data redundancy apparatus for distributed key-value storage based on block data replicas, used to execute the data redundancy method for distributed key-value storage based on block data replicas as described in any one of claims 1-5, characterized in that, include: The first module is used to receive a user's key-value request, calculate the hash value of the key corresponding to the key-value request, determine the corresponding primary replica key-value storage instance based on the hash value, and forward the key-value request to the corresponding primary replica key-value storage instance. Specifically, the first module performs the following steps: S110, Receive key-value requests generated by users through the key-value interface; S120. Calculate the hash value of the key corresponding to the key-value request using a hash function; S130. Perform modulo operation on the calculated hash value, determine the primary replica key-value storage instance corresponding to the key-value request based on the modulo result; encapsulate the key-value request into an RPC message using RPC technology, and forward it to the RPC server of the node where the corresponding primary replica key-value storage instance is located; The second module is used to call the key-value index interface through the key-value storage instance to convert the key-value request into a block device read / write request; The second module specifically performs the following steps: S210. The RPC server parses the RPC message, extracts the target key value, and calls the key value index interface in the storage instance of the target key value. S220. Submit the key value request to the key value index through the key value index interface, and convert the key value request into a read / write request for the block device through the key value index; The key-value index uses B+ Tree, learned index, LSM-tree, Trie, Radix Tree, HashTable, append-only log index, or hybrid index; the key-value index uses a method that directly manages the block device LBA space; The third module is used to submit the block device read / write request to the block device driver engine, and determine whether the block device read / write request is a write request or a read request; if it is a write request, a copy is generated and written to the local and remote copy disks; if it is a read request, the corresponding block data is read from the local or remote copy disk.

Images