Data access method and apparatus, storage node, and readable storage medium

Abstract

This invention relates to the field of distributed storage system technology, and provides a data access method, apparatus, storage node, and readable storage medium. The method includes: receiving a read request sent by a client, the read request including a desired read keyword for data to be read; determining a desired read sequence number for the data to be read based on the desired read keyword, the desired read sequence number being the sequence number of a write request to write the data to be read; determining a target asynchronous node from multiple asynchronous nodes based on the desired read sequence number, and returning the desired read sequence number and the target asynchronous node to the client, instructing the client to read the desired data from the target asynchronous node based on the desired read sequence number. This embodiment can improve the read performance of a distributed storage system while ensuring strong consistency.

Description

Technical Field

[0001] This invention relates to the field of distributed storage system technology, and more specifically, to a data access method, apparatus, storage node, and readable storage medium. Background Technology

[0002] To improve data disaster recovery and redundancy capabilities, expand the overall system throughput, or reduce data access latency, data access management protocols are typically used when designing distributed storage systems to replicate and store data across nodes, data centers, or even regions.

[0003] Improving the read performance of distributed storage systems while ensuring strong consistency is a problem that urgently needs to be solved by researchers in this field. Summary of the Invention

[0004] The purpose of this invention is to provide a data access method, apparatus, storage node, and readable storage medium that can improve the read performance of a distributed storage system while ensuring strong consistency.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] In a first aspect, the present invention provides a data access method applied to a synchronous node in a distributed storage system that performs data access synchronously. The synchronous node is communicatively connected to multiple asynchronous nodes that perform data access asynchronously. The synchronous node is also communicatively connected to a client. The method includes: receiving a read request sent by the client, the read request including a desired read keyword for data to be read; determining a desired read sequence number for the data to be read based on the desired read keyword, the desired read sequence number being the sequence number of a write request to write the data to be read; determining a target asynchronous node from the multiple asynchronous nodes based on the desired read sequence number; and returning the desired read sequence number and the target asynchronous node to the client, thereby instructing the client to read the data to be read from the target asynchronous node based on the desired read sequence number.

[0007] Optionally, the synchronization node stores at least one hash linked list, each hash linked list corresponding to a linked list number, and the step of determining the read sequence number of the data to be read based on the read keyword includes:

[0008] Perform a hash operation on the keyword to be read to obtain the hash value to be read;

[0009] The hash chain list whose chain number is equal to the hash value to be read is used as the hash chain list to be read. The hash chain list to be read includes at least one table entry. Each table entry includes a table entry key and a table entry number. The table entry number represents the sequence number of the write request to write data related to the table entry key.

[0010] The table entries in the hash chain that have the same key as the desired key are selected as the target table entries;

[0011] The largest entry number in the target table is used as the desired reading number.

[0012] Optionally, the synchronous node stores the synchronization sequence number of each asynchronous node, where the synchronization sequence number of each asynchronous node is the sequence number of the write request corresponding to the most recently written synchronous data of the asynchronous node, and the most recently written synchronous data is sent from the synchronous node to the asynchronous node. The step of determining the target asynchronous node from the multiple asynchronous nodes based on the desired sequence number includes:

[0013] The asynchronous nodes whose synchronization sequence number is greater than or equal to the sequence number to be read are determined as the initial selection nodes;

[0014] The target asynchronous node is determined from the initial selected nodes according to a preset strategy.

[0015] Optionally, the step of determining the target asynchronous node from the initially selected nodes according to a preset strategy includes:

[0016] If the preset strategy is a random selection strategy, then any one of the initial selection nodes is randomly selected as the target asynchronous node;

[0017] If the preset strategy is a statistical selection strategy, then the access latency of each of the initially selected nodes is obtained;

[0018] The initial node with the lowest access latency is selected as the target asynchronous node.

[0019] Optionally, the method further includes:

[0020] The client re-initiates the read request based on the rejection message returned by the target asynchronous node. The rejection message is returned to the client by the target asynchronous node because it determines that the current sequence number of the target asynchronous node is greater than the reference sequence number. The current sequence number of the target asynchronous node is the sequence number of the write request corresponding to the latest synchronous data written by the target asynchronous node. The latest synchronous data written by the target asynchronous node is sent to the target asynchronous node by the synchronous node. The reference sequence number is obtained from the client along with the desired read sequence number and represents the sequence number of the write request for the latest data written by the synchronous node at that time.

[0021] The desired data is read from the local machine according to the desired keyword, and the desired data is returned to the client.

[0022] Optionally, the method further includes:

[0023] Receive a write request sent by the client, the write request including the keyword to be written;

[0024] Generate the write sequence number corresponding to the write request;

[0025] Store the keyword to be written and the sequence number to be written.

[0026] Optionally, the synchronization node stores at least one hash linked list, each hash linked list corresponding to a linked list number, and the step of storing the keyword to be written and the sequence number to be written includes:

[0027] Perform a hash operation on the keyword to be written to obtain the hash value to be written;

[0028] The hash list whose linked list number is equal to the hash value to be written is taken as the hash list to be written;

[0029] Generate the table entries to be written based on the keywords to be written and the serial numbers to be written;

[0030] Insert the entry to be written into the hash list to be written.

[0031] Secondly, the present invention provides a data access device applied to a synchronous node in a distributed storage system that performs data access synchronously. The synchronous node is communicatively connected to multiple asynchronous nodes that perform data access asynchronously. The synchronous node is also communicatively connected to a client. The device includes: a receiving module for receiving a read request sent by the client, the read request including a desired read keyword for data to be read; a determining module for determining a desired read sequence number for the desired read data based on the desired read keyword, the desired read sequence number being the sequence number of a write request to write the desired read data; the determining module is further configured to determine a target asynchronous node from the multiple asynchronous nodes based on the desired read sequence number, and return the desired read sequence number and the target asynchronous node to the client, thereby instructing the client to read the desired read data from the target asynchronous node based on the desired read sequence number.

[0032] Thirdly, the present invention provides a storage node, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the data access method as described above.

[0033] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data access method as described above.

[0034] Compared with existing technologies, this embodiment determines the desired read sequence number based on the desired read keyword in the received read request by the synchronous node, and then determines the target asynchronous node based on the desired read sequence number. This allows the client to directly read the desired data from the target asynchronous node. Since the asynchronous node can also handle read requests, it can improve the read performance of the distributed storage system while ensuring strong consistency, which is more advantageous for read-intensive application scenarios. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram illustrating the principle of the ring replication protocol provided in an embodiment of the present invention.

[0037] Figure 2 This is a block diagram of a storage node provided in an embodiment of the present invention.

[0038] Figure 3 Example of a data access method flow provided in embodiments of the present invention Figure 1 .

[0039] Figure 4 This is a structural example diagram of the hash table provided in this embodiment.

[0040] Figure 5 Example of a data access method flow provided in embodiments of the present invention Figure 2 .

[0041] Figure 6 Example of a data access method flow provided in embodiments of the present invention Figure 3 .

[0042] Figure 7 This is a block diagram of a data access device provided in an embodiment of the present invention.

[0043] Icons: 10-First slave node; 20-Second slave node; 30-Master node; 40-Client; 50-Storage node; 51-Processor; 52-Memory; 53-Bus; 54-Communication interface; 100-Data access device; 110-Receive module; 120-Determine module; 130-Reread module; 140-Write module. Detailed Implementation

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

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

[0046] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0047] In the description of this invention, it should be noted that if terms such as "upper," "lower," "inner," or "outer" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of this invention is usually placed, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0048] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0049] It should be noted that, where there is no conflict, the features in the embodiments of the present invention can be combined with each other.

[0050] In distributed storage systems, a commonly used data replication management protocol is Chain Replication (CR). This protocol works by sequentially linking multiple data replica nodes into a linked list. The head node (HEAD) receives and processes all update requests, serializing them along the First-In-First-Out (FIFO) chain until the tail node (TAIL) receives and processes all query requests. Since only the TAIL node can handle read requests, it can easily become a bottleneck in read-intensive applications.

[0051] To improve read performance while maintaining strong consistency, another optimized protocol for chained replication is CRAQ (Chain Replication with Apportioned Queries). This protocol uses multi-version concurrency control to randomly distribute read requests to all linked list nodes, achieving linear scaling of read throughput with the size of the linked list. While all replica nodes can receive and process read requests with CRAQ, the multi-version concurrency control requires each node to track multiple versions of the state data for each object. Furthermore, it demands native support for multi-version concurrency control from the system, making it unsuitable for applications that require modification of existing systems. For example, implementing a distributed RocksDB database system using CRAQ would be complex and intrusive to the existing single-machine RocksDB database system.

[0052] In view of this, this embodiment provides a data access method, apparatus, storage node, and readable storage medium, which is simple to implement and can improve the read performance of a distributed storage system while ensuring strong consistency. This access method is also called 2PQ. Its main innovation is that, based on the ring replication protocol proposed in this embodiment, a single query operation is decomposed into two-stage operations: sequence number query and data reading. The asynchronous node to which the latest read data belongs is determined according to the sequence number, and then the required data is read from the asynchronous node according to the sequence number. Under the premise of ensuring strong consistency, the read throughput can be linearly expanded with the number of asynchronous nodes. It will be described in detail below.

[0053] This embodiment first describes the principle of the ring replication protocol. Please refer to... Figure 1 , Figure 1 This is a schematic diagram illustrating the principle of the ring replication protocol provided in an embodiment of the present invention. Figure 3 In this implementation, two storage nodes for data replicas are randomly selected as the Master node (Master Node 30) and the First Slave node (First Slave Node 10), respectively. As a preferred implementation, the Master node and the First Slave node can be located in the same data center or server room. The Master node and the First Slave node communicate using synchronous replication to maintain data synchronization. All other storage nodes for data replicas serve as Second Slave nodes (Second Slave Node 20). The Second Slave nodes can be located in different data centers or regions. The First Slave nodes communicate with each other using asynchronous replication to maintain data synchronization.

[0054] All Update requests are processed by the Master node. When the Master node receives an Update request from the Client, it first records the data in the replication log, then performs the modification operation in the background while simultaneously replicating it to the First Slave nodes. The Master node only replies to the Client's request after receiving a response from the First Slave nodes.

[0055] When the First Slave node receives an Update request from the Master node, it first records the replication log, and then replies to the Master node with a synchronization request response. Next, it executes the modification operation in the background and synchronizes it to all Second Slave nodes asynchronously.

[0056] When the Second Slave node receives an Update request from the First Slave node, it also records the replication log and then performs the modification operation in the background.

[0057] Second Slave nodes periodically send a Trim Log request to the Master node, which carries an identifier of the currently completed Update request. The Master node records the identifier of the latest replication log of all Second Slave nodes, then deletes the expired replication log locally, and includes the identifier of the replication log in the next synchronization request message sent to the First Slave.

[0058] Figure 1 In this system, the First Slave node and the Master node handle access requests sent by the client 40 synchronously, meaning they are nodes that access data synchronously. In other words, both the First Slave node and the Master node are synchronous nodes. The Second Slave node, on the other hand, handles access requests sent by the client 40 asynchronously, meaning it is a node that accesses data asynchronously.

[0059] Both the Master node and the First Slave node are communicatively connected to client 40 and can receive query requests sent by client 40. Client 40 can choose whether to send the query request to the Master node or the First Slave node according to preset rules. The Master node and the First Slave node have completely identical data replicas. When the Master node or the First Slave node receives a query request from client 40, it divides the process into two stages: sequence number query and data query. In the first stage, the Master node or the First Slave node determines the sequence number corresponding to the data to be read in the query request and the target Second Slave node and returns it to client 40. In the second stage, client 40 reads the data to be read from the target Second Slave node according to the sequence number.

[0060] based on Figure 1 This embodiment also provides a block diagram of a storage node, please refer to... Figure 2 , Figure 2 This is a block diagram of a storage node 50 provided in an embodiment of the present invention. The storage node 50 may be... Figure 1 The storage node 50 is either the first slave node 10 or the master node 30. The storage node 50 includes a processor 51, a memory 52, a bus 53, and a communication interface 54. The processor 51 and the memory 52 are connected via the bus 53. When the storage node 50 is the first slave node 10, the processor 51 communicates with the client 40 and the second slave node 20 via the communication interface 54. When the storage node 50 is the master node 30, the processor 51 communicates with the client 40 and the first slave node 10 via the communication interface 54.

[0061] Processor 51 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed through integrated logic circuits in the hardware of processor 51 or through software instructions. Processor 51 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), an On-Premises Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0062] The memory 52 is used to store programs, such as the data access device 100 in this embodiment of the invention. The data access device 100 includes at least one software function module that can be stored in the memory 52 in the form of software or firmware. After receiving the execution instruction, the processor 51 executes the program to implement the data access method in this embodiment of the invention.

[0063] The memory 52 may include high-speed random access memory (RAM) or non-volatile memory. Optionally, the memory 52 may be a storage device built into the processor 51 or a storage device independent of the processor 51.

[0064] Bus 53 can be an ISA bus, PCI bus, or EISA bus, etc. Figure 2 It is indicated by a single double-headed arrow, but does not mean that there is only one bus or one type of bus.

[0065] exist Figure 1 and Figure 2 Based on this, this embodiment provides a data access method, please refer to... Figure 3 , Figure 3 Example of a data access method flow provided in embodiments of the present invention Figure 1 This method can be applied to Figure 1 The first slave node 10 or master node 30, or applied to Figure 2 The method includes the following steps: (Storage node 50 in the image)

[0066] Step S100: Receive a read request sent by the client. The read request includes the keyword of the data to be read.

[0067] In this embodiment, since both the first slave node 10 and the master node 30 are synchronous nodes, the client 40 can choose to send the read request to the first slave node 10 or the master node 30 according to preset rules. For example, the client 40 can send the read request to the one with a smaller read load between the first slave node 10 and the master node 30.

[0068] In this embodiment, the distributed storage system stores data in a key-value format. For example, the data is: user identifier-phone number, where the user identifier is the key and the phone number is the value.

[0069] Step S101: Determine the read sequence number of the data to be read based on the read keyword. The read sequence number is the sequence number of the write request to write the data to be read.

[0070] In this embodiment, a write request is an Update request. Write requests are only sent to the master node 30. When processing a write request, the master node 30 generates a sequence number for each write request to uniquely identify the write request. This sequence number can be used as a globally consistent snapshot ID. The master node 30 will synchronously synchronize the sequence number of the write request and the data to be written to the first slave node 10. The first slave node 10 will asynchronously synchronize the sequence number of the write request and the data to be written to the second slave node 20.

[0071] In this embodiment, each data write request corresponds to a sequence number. When reading data to be read, the sequence number of the write request is first determined, and the data to be read can be found based on this sequence number. It should be noted that if data related to the same keyword is written multiple times, each write request will have a sequence number. The read sequence number is the sequence number of the latest write request. For example, write requests 1 to 3 in chronological order are all requests to write data to be read, and their corresponding sequence numbers are 100, 101, and 102, respectively. Then, 103 is the sequence number of the latest write, which is the read sequence number.

[0072] Step S102: Determine the target asynchronous node from multiple asynchronous nodes based on the desired sequence number, and return the desired sequence number and the target asynchronous node to the client to instruct the client to read the desired data from the target asynchronous node based on the desired sequence number.

[0073] In this embodiment, the asynchronous node is Figure 1 In a synchronous node, the second slave node can have different synchronization progresses when synchronizing data from the synchronous node. Only when the data to be read has been synchronized to the asynchronous node can the correct data be read from that asynchronous node. The target asynchronous node is the asynchronous node that has already stored the latest data to be read.

[0074] The method provided in this embodiment involves the synchronous node determining the desired read sequence number based on the desired read keyword in the received read request, and then determining the target asynchronous node based on the desired read sequence number. This allows the client to directly read the desired data from the target asynchronous node. Since the asynchronous node can also handle read requests, it can improve the read performance of the distributed storage system while ensuring strong consistency.

[0075] To determine the desired sequence number more efficiently, the synchronization node stores at least one hash list, which can be stored in the synchronization node's memory. Each hash list corresponds to a list number. This embodiment also provides a specific implementation method for determining the desired sequence number:

[0076] First, perform a hash operation on the keyword to be read to obtain the hash value to be read.

[0077] In this embodiment, a preset hash function can be used, with the keyword to be read as a parameter of the preset hash function, to obtain the hash value to be read.

[0078] Secondly, the hash chain with the chain number equal to the hash value to be read is taken as the hash chain to be read. The hash chain to be read includes at least one entry. Each entry includes an entry key and an entry sequence number. The entry sequence number represents the sequence number of the write request to write data related to the entry key.

[0079] Third, the table entries in the hash chain whose key is the same as the key to be read are taken as the target table entries.

[0080] Finally, the largest entry number in the target table is used as the desired reading number.

[0081] In this embodiment, in order to find the target entry from the hash list to be read more quickly, when the sequence number of the write request is incremented sequentially according to the write time, all entries in the hash list to be read can be arranged in descending order of the entry sequence number. Thus, the first entry whose key is the same as the key to be read from the hash list to be read is the target entry.

[0082] It should be noted that if the synchronization node is Figure 1 When there is a master node 30 and a first slave node 10, since the master node 30 and the first slave node 10 are synchronously replicated, each of them maintains a hash table. A hash table includes at least one hash chain, and the two hash tables are completely identical. Taking a transaction as an example where each request corresponds to a single transaction, the sequence number of each request is the transaction sequence number corresponding to that request. The latest committed transaction sequence number of the synchronous node is denoted as CSeq0. Since each request corresponds to a transaction, and each transaction corresponds to a unique transaction sequence number, this transaction sequence number also serves as a global consistency snapshot identifier. The currently allocated transaction sequence number is denoted as GSeq. Transactions between (CSeq0, GSeq) are in an uncommitted state. Write requests from uncommitted transactions are write requests that have not yet been completed. The synchronous node also records the latest committed transaction sequence number of each asynchronous node, denoted as CSeqi, i = 1, 2, ... For Update operations, a new item is directly inserted from the head of the hash list. For Query operations, the hash list is traversed from the head until the first target item is found. For Trim log operations, the list is traversed from the tail, deleting all items that satisfy the condition WSeq ≤ min{CSeqi}. Log operations are handled by a separate background thread. To improve the access throughput of the in-memory hash list, a lock-free concurrent architecture can be used.

[0083] To more clearly illustrate hash lists and their entries, this example uses a hash table to organize the hash list. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a structural example diagram of the hash table provided in this embodiment. Figure 4 In this example, a hash table consists of n hash buckets, each corresponding to a hash linked list. The hash bucket number is the linked list number of the corresponding hash list. Each hash linked list includes a hash table entry, and each hash table entry includes a pointer to the next hash table entry, an entry number, and an entry key. The hash linked list corresponding to bucket 1 is empty. Figure 4 Taking hash bucket i as an example, hash bucket i includes 3 hash entries: entry 1 to entry 3, whose corresponding entry keys and entry numbers are {key1, 11}, {key1, 10}, and {key2, 12}, respectively. For entry key key1, it is sorted in descending order of entry number. For entry key key2, there is only one entry, which is also sorted in descending order.

[0084] The method provided in this embodiment can quickly determine the hash list to be read by using the keyword to be read through hash operation. Since the entries in the hash list are arranged in an ordered manner, the target entry can be quickly determined from the hash list to be read, which improves the efficiency of determining the target entry and ultimately improves the processing efficiency of read requests.

[0085] In this embodiment, the synchronous node sends synchronous data to all asynchronous nodes. Each asynchronous node writes the synchronous data according to the sequence number of the write request corresponding to the synchronous data. Each asynchronous node periodically feeds back the synchronization sequence number of the most recently written synchronous data to the synchronous node. The synchronous node stores the synchronization sequence number of each asynchronous node. Based on this, this embodiment also provides a specific implementation method for determining the target asynchronous node:

[0086] First, asynchronous nodes whose synchronization sequence number is greater than or equal to the sequence number to be read are selected as the initial nodes.

[0087] In this embodiment, if the synchronization sequence number is greater than or equal to the sequence number to be read, it means that the asynchronous node stores the latest data to be read.

[0088] Secondly, the target asynchronous node is determined from the initial selected nodes according to the preset strategy.

[0089] In this embodiment, in order to determine the target asynchronous node more reasonably and to be more flexibly applicable to various application scenarios, this embodiment can determine the target asynchronous node that meets the preset scenario according to a preset strategy. The preset strategy includes, but is not limited to, random selection strategy, statistical selection strategy, etc.

[0090] For a random selection strategy, the target asynchronous node can be determined in the following ways:

[0091] If the preset strategy is a random selection strategy, then any initial node will be randomly selected as the target asynchronous node.

[0092] For statistical selection strategies, the target asynchronous node can be determined in the following ways:

[0093] If the preset strategy is a statistical selection strategy, then the access latency of each initial selection node is obtained; the initial selection node with the minimum access latency is selected as the target asynchronous node.

[0094] The method provided in this embodiment can reasonably distribute read requests across multiple asynchronous nodes and ensure that the latest data to be read exists on the asynchronous nodes. Ultimately, it improves the read performance of the entire distributed system while ensuring strong consistency. Its advantages are particularly obvious when the number of read requests is large. Since the initial node with the smallest access latency is selected as the target asynchronous node, it ensures that the client's 40 requests receive the fastest response. Even if some asynchronous nodes are in a sub-healthy state, the impact on read performance is not significant.

[0095] In this embodiment, for write-intensive scenarios, there may be an extreme scenario with an extremely low probability of occurrence. For example, W1 is a prior write request, W2 is a subsequent write request, and R is a read request. If W2 arrives at the target asynchronous node before R, the data to be read in the target asynchronous node is not the latest. To avoid reading incorrect data, the target asynchronous node will return a rejection message. In this scenario, to read the correct data, this embodiment also provides a processing method for this scenario. Please refer to [link / reference]. Figure 5 , Figure 5 Example of a data access method flow provided in embodiments of the present invention Figure 2 The method includes the following steps:

[0096] Step S110: Receive a read request re-initiated by the client based on the rejection message returned by the target asynchronous node. The rejection message is returned to the client by the target asynchronous node because it determines that the current sequence number of the target asynchronous node is greater than the reference sequence number. The current sequence number of the target asynchronous node is the sequence number of the write request corresponding to the latest synchronous data written by the target asynchronous node. The latest synchronous data written by the target asynchronous node is sent to the target asynchronous node by the synchronous node. The reference sequence number is obtained from the client along with the desired read sequence number and represents the sequence number of the write request for the latest data written by the synchronous node at that time.

[0097] In this embodiment, the synchronous node synchronizes the data written by the write request and the corresponding sequence number of the write request as synchronous data to the asynchronous node. Each asynchronous node also stores the current sequence number of the write request corresponding to the latest synchronous data written by the asynchronous node. The client first sends a read request to the synchronous node. The synchronous node responds to the read request by returning the desired sequence number, the reference sequence number, and the target asynchronous node to the client. The reference sequence number is the sequence number of the write request that last wrote the data when the synchronous node received the read request. The client sends the desired sequence number and the reference sequence number to the target asynchronous node. The target asynchronous node determines whether its current sequence number is greater than or equal to the desired sequence number. If the current sequence number is less than or equal to the reference sequence number, it indicates that there is no request to update the data to be read between the current sequence number and the reference sequence number, and the data to be read in the target asynchronous node is the latest. If the current sequence number is greater than the reference sequence number, it cannot be determined whether there is a request to update the data to be read between the current sequence number and the reference sequence number, that is, the data to be read in the target asynchronous node is not necessarily the latest. In this case, the target asynchronous node returns a rejection message to the client. After receiving the rejection message, the client re-initiates a read request to the synchronous node to read the data to be read. Based on the read request, the synchronous node reads the latest data to be read from its local machine and returns it to the client. As a specific implementation method, the client 40 can set a flag in the read request to indicate that the read request is re-initiated based on the rejection message.

[0098] It should be noted that in most scenarios, the data to be read in the target asynchronous node is up-to-date, and the read data can be directly returned to the client. Only in extreme and very rare cases may the data to be read in the target asynchronous node be not up-to-date, in which case a rejection message is returned to the client.

[0099] Step S111: Read the data to be read from the local machine according to the keyword to be read, and return the data to be read to the client.

[0100] In this embodiment, the data to be read in the synchronization node is the latest, which is the data that the read request actually needs. At this time, the data to be read is read from the synchronization node and returned to the client 40.

[0101] It should be noted that different processing methods can be adopted depending on the consistency requirements. For example, in application scenarios with high consistency requirements, the above method can be used to query the synchronous node to obtain the target asynchronous node, the desired sequence number, and the reference sequence number. The target asynchronous node determines whether the latest data to be read exists locally based on the desired sequence number, the latest local sequence number, and the reference sequence number. If it does, the data to be read is read from the target asynchronous node; otherwise, the latest data to be read is read from the synchronous node. In this case, it can be guaranteed that the data to be read is the most recently written. For other application scenarios with low consistency requirements, it is necessary to work normally even when strong consistency guarantees cannot be provided, and higher read performance is required. In this case, the step of querying the target asynchronous node can be bypassed, and data can be read directly from multiple asynchronous nodes. In this case, although it cannot be guaranteed that the latest data is read, it can still be guaranteed that the data read is the data that has been stored by the asynchronous nodes, thus ensuring eventual consistency.

[0102] It should also be noted that, in order to adapt data access operations to application scenarios with different access characteristics, different access methods can be used for different application scenarios:

[0103] 1) For read-only application scenarios, all node data is in a completely consistent state, and consistent data can be read from both synchronous and asynchronous nodes;

[0104] 2) For read-heavy and write-light application scenarios, since asynchronous Second Slave nodes have different replication latencies, by querying the synchronous Master / First Slave nodes to obtain the target Second Slave node and the desired sequence number, it can be guaranteed that the data read from the Second Slave node is the latest committed data;

[0105] 3) For application scenarios that involve both reading and writing, and are write-intensive, different processing methods can be adopted according to different consistency requirements.

[0106] This embodiment also provides a method for handling write requests for writing data; please refer to [reference needed]. Figure 6 , Figure 6 Example of a data access method flow provided in embodiments of the present invention Figure 3 The method also includes:

[0107] Step S120: Receive a write request sent by the client. The write request includes the keyword to be written.

[0108] Step S121: Generate the write sequence number corresponding to the write request.

[0109] In this embodiment, the write sequence number is the sequence number corresponding to the write request. Each write request has a unique sequence number, which can be either incrementing or decrementing.

[0110] Step S122: Store the keyword to be written and the sequence number to be written.

[0111] In this embodiment, after the data related to the keyword to be written is written, the data related to the keyword to be written can be read according to the keyword to be written and the sequence number to be written.

[0112] In this embodiment, to more efficiently read data related to the keyword to be written based on the keyword and the sequence number to be written, the synchronization node stores at least one hash linked list, with each hash linked list corresponding to a linked list number. This embodiment also provides a specific implementation method for storing the keyword and the sequence number to be written:

[0113] First, perform a hash operation on the keyword to be written to obtain the hash value to be written.

[0114] Secondly, the hash list whose linked list number is equal to the hash value to be written is selected as the hash list to be written.

[0115] In this embodiment, the calculation method for the hash value to be written is the same as that for the hash value to be read, and the method for determining the hash chain to be written is the same as that for the hash chain to be read, which will not be repeated here.

[0116] Third, generate the entries to be written based on the keywords and serial numbers to be written.

[0117] Finally, insert the entry to be written into the hash list to be written.

[0118] In this embodiment, as a specific implementation method, in the hash chain to be written, the entries with the same key are arranged in descending order of their entry numbers. Therefore, when inserting, it is only necessary to find the first entry with the same key and insert it directly before that entry. Of course, if there is no entry with the same key in the hash chain to be written, the entry to be written can be directly inserted at the head of the hash chain to be written.

[0119] The method provided in this embodiment only includes a small amount of information such as the table key and the table sequence number in the hash chain, so it only needs to occupy a small amount of storage space and can be stored in the memory of the synchronization node, thereby enabling fast access to the hash chain.

[0120] To more clearly illustrate the data access method provided in this embodiment, we take a 5-replica configuration as an example: 1 Master node, 1 First Slave node, and 3 Second Slave nodes: A, B, and C. Each replica node uses the RocksDB storage engine, and all key-value pairs are stored on the hard disk. The replication log uses a write-ahead log (WAL) method, stored on the solid-state drive at a granularity of 64MB per shard.

[0121] In this scenario, the data update (i.e., data write) process is as follows:

[0122] Step S10: The client sends an Update request r to the Master node;

[0123] In step S11, after receiving the request r, the Master node assigns it a unique sequence number WSeq and records it in the replication log. Then, it synchronously replicates the request to the First Slave node and waits for a response.

[0124] In step S12, after receiving the request r, the First Slave node directly records the replication log and replies with an ACK(r) response upon completion.

[0125] In step S13, after receiving the ACK(r) response, the Master node inserts an item into the hash list wTable and responds to the Client request.

[0126] Step S14: The Master node replays the replication logs one by one in the background task mode to modify the backend RocksDB.

[0127] Step S15: The First Slave node uses asynchronous replication to synchronize the replication log to all SecondSlave nodes and replays the replication log to modify the backend RocksDB.

[0128] In step S16, the Second Slave node receives the request r, directly records the replication log, and then modifies the backend RocksDB.

[0129] The data query (i.e., data read) process is as follows:

[0130] Step S20: The Client sends a sequence number query request r' to the Master node;

[0131] Step S21: After receiving the request r', the Master node searches for the target item in the wTable and selects the target Second Slave node based on the query result. For example, the target Second Slave node is A.

[0132] Step S22: The Client sends a read data request to node A;

[0133] In step S23, node A returns the data it has read.

[0134] To perform the corresponding steps in the above embodiments and various possible implementations, an implementation of the data access device 100 is given below. Please refer to... Figure 7 , Figure 7 This is a block diagram of a data access device provided in an embodiment of the present invention. It should be noted that the basic principle and technical effects of the data access device 100 provided in this embodiment are the same as those in the above embodiments; however, for the sake of brevity, some details are not mentioned in this embodiment.

[0135] The data access device 100 includes a receiving module 110 and a determining module 120.

[0136] The receiving module 110 is used to receive a read request sent by the client, which includes the keyword of the data to be read.

[0137] The determination module 120 is used to determine the read sequence number of the data to be read based on the read keyword. The read sequence number is the sequence number of the write request to write the data to be read.

[0138] The determination module 120 is also used to determine the target asynchronous node from multiple asynchronous nodes based on the desired read sequence number, and return the desired read sequence number and the target asynchronous node to the client, so as to instruct the client to read the data to be read from the target asynchronous node based on the desired read sequence number.

[0139] Optionally, the synchronization node stores at least one hash chain, each hash chain corresponding to a chain number. The determining module 120 is specifically used for: performing a hash operation on the keyword to be read to obtain the hash value to be read; taking the hash chain with the chain number equal to the hash value to be read as the hash chain to be read, the hash chain to be read includes at least one entry, each entry includes an entry keyword and an entry sequence number, the entry sequence number representing the sequence number of the write request to write data related to the entry keyword; taking the entry in the hash chain to be read with the same entry keyword as the keyword to be read as the target entry; and taking the largest entry sequence number in the target entry as the read sequence number.

[0140] Optionally, the synchronous node stores the synchronization sequence number of each asynchronous node. The synchronization sequence number of each asynchronous node is the sequence number of the write request corresponding to the most recently written synchronous data of the asynchronous node. The most recently written synchronous data of the asynchronous node is sent from the synchronous node to the asynchronous node. The determining module 120 is specifically used to: determine the asynchronous nodes whose synchronization sequence number is greater than or equal to the desired read sequence number as the initial selection nodes; and determine the target asynchronous node from the initial selection nodes according to a preset strategy.

[0141] Optionally, when determining the target asynchronous node from the initial selected nodes according to the preset strategy, the determining module 120 is specifically used to: if the preset strategy is a random selection strategy, randomly select any initial selected node as the target asynchronous node; if the preset strategy is a statistical selection strategy, obtain the access latency of each initial selected node; and select the initial selected node with the minimum access latency as the target asynchronous node.

[0142] Optionally, the reread module 130 is used to: receive a read request re-initiated by the client based on a rejection message returned by the target asynchronous node, wherein the rejection message is returned to the client by the target asynchronous node because it determines that the current sequence number of the target asynchronous node is greater than the reference sequence number, the current sequence number of the target asynchronous node is the sequence number of the write request corresponding to the latest synchronous data written by the target asynchronous node, the latest synchronous data written by the target asynchronous node is sent to the target asynchronous node by the synchronous node, and the reference sequence number is obtained from the client together with the desired read sequence number and represents the sequence number of the write request of the latest data written by the synchronous node at that time; read the desired data from the local machine according to the desired read keyword, and return the desired read data to the client.

[0143] Optionally, the write module 140 is used to: receive a write request sent by the client, the write request including the keyword to be written; generate the write sequence number corresponding to the write request; and store the keyword to be written and the write sequence number.

[0144] Optionally, the synchronization node stores at least one hash chain, each hash chain corresponding to a chain number. The write module 140 is specifically used for: performing a hash operation on the keyword to be written to obtain the hash value to be written; using the hash chain with the chain number equal to the hash value to be written as the hash chain to be written; generating the entry to be written based on the keyword to be written and the sequence number to be written; and inserting the entry to be written into the hash chain to be written.

[0145] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data access method as described above.

[0146] In summary, the embodiments of the present invention provide a data access method, apparatus, storage node, and readable storage medium, applied to a synchronous node in a distributed storage system that performs data access synchronously. The synchronous node is communicatively connected to multiple asynchronous nodes that perform data access asynchronously, and the synchronous node is communicatively connected to a client. The method includes: receiving a read request sent by the client, the read request including a keyword for data to be read; determining a read sequence number for the data to be read based on the read keyword, the read sequence number being the sequence number of a write request to write the data to be read; determining a target asynchronous node from among the multiple asynchronous nodes based on the read sequence number, and returning the read sequence number and the target asynchronous node to the client to instruct the client to read the data to be read from the target asynchronous node based on the read sequence number. Compared with existing technologies, the synchronous node determines the desired sequence number based on the desired keyword in the received read request, and then determines the target asynchronous node based on the desired sequence number. This allows the client to directly read the desired data from the target asynchronous node. Since the asynchronous node can also handle read requests and has the latest pre-read data, the read performance of the distributed storage system can be improved while ensuring strong consistency. Because sequence number lookup is a lightweight operation, a single sequence number lookup consumes less network bandwidth and can be completed entirely in memory without involving disk read operations, it is less likely to become a bottleneck.

[0147] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data access method, characterized in that, A synchronous node applied in a distributed storage system for synchronous data access, wherein the synchronous node is one of a master node and a first slave node, the synchronous node is communicatively connected to multiple asynchronous nodes for asynchronous data access, and the synchronous node is communicatively connected to a client, the method comprising: Receive a read request sent by the client, the read request including the keyword of the data to be read; The desired read sequence number of the desired read data is determined based on the desired read keyword. The desired read sequence number is the sequence number of the write request to write the desired read data. The desired read data is sent by the client to the master node and stored by the master node. The master node synchronously synchronizes the desired read data to the first slave node, and the first slave node asynchronously synchronizes the desired read data to multiple asynchronous nodes. The target asynchronous node is determined from the plurality of asynchronous nodes according to the desired read sequence number, and the desired read sequence number and the target asynchronous node are returned to the client to instruct the client to read the data to be read from the target asynchronous node according to the desired read sequence number.

2. The data access method as described in claim 1, characterized in that, The synchronization node stores at least one hash linked list, each hash linked list corresponding to a linked list number. The step of determining the read sequence number of the data to be read based on the read keyword includes: Perform a hash operation on the keyword to be read to obtain the hash value to be read; The hash chain list whose chain number is equal to the hash value to be read is used as the hash chain list to be read. The hash chain list to be read includes at least one table entry. Each table entry includes a table entry key and a table entry number. The table entry number represents the sequence number of the write request to write data related to the table entry key. The table entries in the hash chain that have the same key as the desired key are selected as the target table entries; The largest entry number in the target table is used as the desired reading number.

3. The data access method as described in claim 1, characterized in that, The synchronous node stores the synchronization sequence number of each asynchronous node. The synchronization sequence number of each asynchronous node is the sequence number of the write request corresponding to the most recently written synchronous data of the asynchronous node. The most recently written synchronous data is sent from the synchronous node to the asynchronous node. The step of determining the target asynchronous node from the multiple asynchronous nodes based on the desired sequence number includes: The asynchronous nodes whose synchronization sequence number is greater than or equal to the sequence number to be read are determined as the initial selection nodes; The target asynchronous node is determined from the initial selected nodes according to a preset strategy.

4. The data access method as described in claim 3, characterized in that, The step of determining the target asynchronous node from the initially selected nodes according to a preset strategy includes: If the preset strategy is a random selection strategy, then any one of the initial selection nodes is randomly selected as the target asynchronous node; If the preset strategy is a statistical selection strategy, then the access latency of each of the initially selected nodes is obtained; The initial node with the lowest access latency is selected as the target asynchronous node.

5. The data access method as described in claim 1, characterized in that, The method further includes: The client re-initiates the read request based on the rejection message returned by the target asynchronous node. The rejection message is returned to the client by the target asynchronous node because it determines that the current sequence number of the target asynchronous node is greater than the reference sequence number. The current sequence number of the target asynchronous node is the sequence number of the write request corresponding to the latest synchronous data written by the target asynchronous node. The latest synchronous data written by the target asynchronous node is sent to the target asynchronous node by the synchronous node. The reference sequence number is obtained from the client along with the desired read sequence number and represents the sequence number of the write request for the latest data written by the synchronous node at that time. The desired data is read from the local machine according to the desired keyword, and the desired data is returned to the client.

6. The data access method as described in claim 1, characterized in that, The method further includes: Receive a write request sent by the client, the write request including the keyword to be written; Generate the write sequence number corresponding to the write request; Store the keyword to be written and the sequence number to be written.

7. The data access method as described in claim 6, characterized in that, The synchronization node stores at least one hash linked list, each hash linked list corresponding to a linked list number. The step of storing the keyword to be written and the sequence number to be written includes: Perform a hash operation on the keyword to be written to obtain the hash value to be written; The hash list whose linked list number is equal to the hash value to be written is taken as the hash list to be written; Generate the table entries to be written based on the keywords to be written and the serial numbers to be written; Insert the entry to be written into the hash list to be written.

8. A data access device, characterized in that, A synchronous node for synchronous data access in a distributed storage system, wherein the synchronous node is one of a master node and a first slave node, the synchronous node is communicatively connected to multiple asynchronous nodes for asynchronous data access, and the synchronous node is communicatively connected to a client, the device comprising: The receiving module is used to receive a read request sent by the client, wherein the read request includes a keyword for the data to be read; The determination module is used to determine the read sequence number of the data to be read based on the read keyword. The read sequence number is the sequence number of the write request to write the data to be read. The data to be read is sent by the client to the master node and stored by the master node. The master node synchronizes the data to be read to the first slave node in a synchronous manner, and the first slave node synchronizes the data to be read to multiple asynchronous nodes in an asynchronous manner. The determining module is further configured to determine a target asynchronous node from among the multiple asynchronous nodes according to the desired reading sequence number, and return the desired reading sequence number and the target asynchronous node to the client, so as to instruct the client to read the data to be read from the target asynchronous node according to the desired reading sequence number.

9. A storage node, characterized in that, It includes a processor and a memory, the memory being used to store a program, and the processor being used to implement the data access method of any one of claims 1-7 when executing the program.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the data access method as described in any one of claims 1-7.

Images