A timestamp allocation method and apparatus for distributed databases

Abstract

This specification proposes a timestamp allocation method and apparatus for distributed databases. The nodes in the distributed database include time synchronization nodes and ordinary nodes. The method is applied to any node and may include: responding to a received transaction commit request, committing the corresponding transaction to be time-synchronized and recording the start commit time of the transaction to be time-synchronized; querying the time synchronization request sending time of any node to the time synchronization node for other transactions; and, if the time synchronization request sending time of any other transaction is not earlier than the start commit time of the transaction to be time-synchronized, allocating the timestamp returned by the time synchronization node for that other transaction to the transaction to be time-synchronized. The technical solution of this specification can effectively reduce the frequency of each node sending timestamp retrieval requests to the time synchronization node, reduce the load on the time synchronization node, avoid the problem of the time synchronization node returning a time synchronization response for too long due to overload, and improve the processing efficiency of each transaction.

Description

Technical Field

[0001] This specification relates to the field of database technology, and more particularly to a timestamp allocation method and apparatus for distributed databases. Background Technology

[0002] Distributed databases, as a crucial application component of distributed systems, not only inherit the core characteristics of traditional single-machine databases but also possess the processing capabilities of distributed systems, offering features such as low hardware cost, high scalability, and high availability. A distributed database consists of multiple nodes that communicate with each other by exchanging messages. Because each database instance on a node has an independent clock, and these clocks cannot reflect the global order, clock skew can occur, compromising the consistency of the distributed database.

[0003] To avoid clock skew, a globally consistent version number can be provided through a clock service. A clock service uses timestamps (ts) to establish a sequence relationship between transactions in the database; a larger timestamp indicates a higher version number and a later position in the transaction's order. Related technologies use a single time synchronization node to provide clock services to all transactions in the database. This single time synchronization node ensures that timestamps are assigned to transactions on each node in an incremental manner, thereby guaranteeing the consistency of transactions within the database.

[0004] For distributed databases using a single-point time synchronization service, all nodes need to send a request to the synchronization node to retrieve the timestamp for each transaction. This can easily lead to excessive load on the synchronization node, significantly increasing the response time for timestamp retrieval requests when the node's processing capacity is reached. Furthermore, for each transaction, sending a request to the synchronization node and waiting for the node to return the allocated timestamp upon each commit significantly increases the processing time of each transaction, thus reducing database performance. Summary of the Invention

[0005] This specification provides a timestamp allocation method and apparatus for distributed databases to address the shortcomings of related technologies.

[0006] According to a first aspect of one or more embodiments of this specification, a timestamp allocation method for a distributed database is provided, wherein the nodes of the distributed database include time synchronization nodes and ordinary nodes, and the method is applied to any node, the method comprising:

[0007] In response to the received transaction commit request, the corresponding time-pending transaction is committed and the start commit time of the time-pending transaction is recorded;

[0008] Query the time when any of the nodes sent a time synchronization request to the time synchronization node for other transactions;

[0009] If the timing request of any other transaction is sent at a time no earlier than the start submission time of the transaction to be timed, the timestamp fed back by the timing node for that other transaction shall be assigned to the transaction to be timed.

[0010] According to a second aspect of one or more embodiments of this specification, a timestamp allocation apparatus for a distributed database is provided, wherein the nodes of the distributed database include time synchronization nodes and ordinary nodes, and the apparatus is applied to any node, the apparatus comprising:

[0011] The commit module is used to respond to the received transaction commit request, commit the corresponding time-pending transaction, and record the start commit time of the time-pending transaction;

[0012] The query module is used to query the time when any node sends a time synchronization request to the time synchronization node for other transactions;

[0013] The allocation module is used to allocate the timestamp fed back by the timing node for any other transaction to the transaction to be timed, provided that the timing request of any other transaction is sent at a time no earlier than the start submission time of the transaction to be timed.

[0014] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0015] processor;

[0016] Memory used to store processor-executable instructions;

[0017] The processor executes the executable instructions to implement the method described in the embodiments of the first aspect above.

[0018] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the embodiments of the first aspect above.

[0019] As can be seen from the above technical solutions, in one or more embodiments of this specification, by adding a timestamp cache to each node of the distributed database to store timestamps previously obtained from the time synchronization node, multiple transactions can reuse the same timestamp while ensuring external consistency of the database. This effectively reduces the frequency of each node sending timestamp requests to the time synchronization node, thereby reducing the load on the time synchronization node and avoiding the problem of the time synchronization node returning a time synchronization response for too long due to overload. Furthermore, by avoiding waiting for the time synchronization node to allocate timestamps, the waiting time is shortened, thus greatly improving the processing efficiency of each transaction and ensuring database performance.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0022] Figure 1 This is an exemplary embodiment of a distributed database architecture diagram.

[0023] Figure 2 This is a flowchart illustrating an exemplary embodiment of a timestamp allocation method applied to a distributed database.

[0024] Figure 3a This is a schematic diagram illustrating an exemplary embodiment of ensuring external consistency of a distributed database.

[0025] Figure 3b This is a schematic diagram illustrating how to ensure external consistency of a distributed database, provided by another exemplary embodiment.

[0026] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment.

[0027] Figure 5 This is a block diagram of a timestamp allocation device applied to a distributed database, provided as an exemplary embodiment. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0029] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0030] Distributed databases are widely used for data storage and management due to their high scalability and high reliability. Figure 1 This is an exemplary embodiment of a distributed database architecture diagram. For example... Figure 1 As shown, a distributed database consists of multiple nodes, including a time synchronization node and ordinary nodes. All ordinary nodes send time synchronization requests to the time synchronization node to obtain the timestamp assigned by the time synchronization node. Related technologies use a single time synchronization node to uniformly provide clock services to transactions in the database to ensure transaction consistency. However, this single-point time synchronization method requires each ordinary node to send a time synchronization request to the time synchronization node for each transaction on its own node. This can easily lead to excessive load on the time synchronization node, significantly increasing the response time of time synchronization requests when the node's processing capacity is reached. Furthermore, for each transaction, sending a time synchronization request to the time synchronization node each time it commits and waiting for the time synchronization node to return the assigned timestamp significantly increases the execution time of each transaction and reduces database performance.

[0031] This specification provides a timestamp allocation method for distributed databases to address the shortcomings of related technologies.

[0032] Figure 2 This is a flowchart illustrating a timestamp allocation method applied to a distributed database, as provided in an exemplary embodiment. This method can be applied to... Figure 1 This method applies to any node in a distributed database. Besides ordinary nodes, when a time synchronization node not only has time synchronization capabilities but also performs transaction processing functions similar to those of ordinary nodes, this method also applies to the time synchronization node. For example... Figure 2 As shown, the method may include the following steps:

[0033] S201, in response to the received transaction commit request, submit the corresponding pending time-sharing transaction and record the start commit time of the pending time-sharing transaction.

[0034] A database transaction can be understood as a logical unit in the database execution process, consisting of a finite sequence of database operations. Typically, a transaction contains multiple read and write operations. Transactions have four fundamental properties: Atomicity, Consistency, Isolation, and Durability. The durability of a transaction means that it only becomes effective after being committed. After committing, the changes the transaction made to the database are permanently saved and can be read by other users. If not committed, the transaction content is cached and can be rolled back at any time. There are three ways to commit database transactions: explicit commit, implicit commit, and automatic commit. Those skilled in the art can configure these according to their actual needs; this specification does not impose any limitations on this.

[0035] Generally, the entire transaction execution process can be divided into three stages: transaction start commit, transaction timestamp acquisition, and transaction completion commit. The timestamp acquisition process can be further divided into three parts: a regular node sends a time synchronization request to the time synchronization node for the committed transaction; the time synchronization node receives the time synchronization request and returns a time synchronization response to the regular node that sent the request; and the regular node receives the time synchronization response and obtains the timestamp returned to the transaction. However, this timestamp acquisition process is time-consuming, and the method of each transaction sending a separate time synchronization request to the time synchronization node can easily lead to excessive load on the time synchronization node's request processing. Therefore, this specification proposes an alternative timestamp acquisition method: multiple transactions reuse the same timestamp. Specifically, when any node in the distributed database receives a transaction commit request, it commits the corresponding transaction to be time-synchronized and records the start commit time of the transaction to be time-synchronized for subsequent use. In this specification, the start commit time of the transaction to be time-synchronized can be denoted as Absolute Time (Start To Commit).

[0036] S202, query the time when any node sends a timing request to the timing node for other transactions.

[0037] Typically, after a transaction awaiting time synchronization begins to commit, the node receiving the commit request needs to send a time synchronization request to the time synchronization node so that the time synchronization node can assign a timestamp to the transaction. Therefore, there will be a time when the time synchronization request is sent to the time synchronization node. Usually, the start commit time of the transaction and the time synchronization request sending time are not the same; there is a certain time difference between them. In this specification, the information exchange between ordinary nodes and the time synchronization node relies on the RPC (Remote Procedure Call) protocol, so the time synchronization request sending time can be denoted as AbsoluteTime(Send RPC Request). Of course, ordinary nodes and the time synchronization node can also exchange information based on other protocols, which this specification does not limit.

[0038] Taking a regular node N1 as an example, in one embodiment, when a regular node N1 receives a commit request for transaction T0, it commits transaction T0 in response to the request and records the start commit time of transaction T0, denoted as Absolute Time(T0.StartToCommit). At this time, transaction T0 is a time-awaited transaction, and a timestamp needs to be assigned to it. After node N1 records the start commit time of the time-awaited transaction T0, node N1 can query the time when it sent time-awaiting requests to the time-awaiting node for other transactions. Here, "other transactions" can be understood as all transactions on node N1 that have sent time-awaiting requests to the time-awaiting node, excluding the current time-awaited transaction T0, including time-awaited transactions and non-time-awaited transactions. Among them, a time-awaited transaction refers to a transaction that has sent a time-awaiting request to the time-awaiting node and has received a time-awaiting response from the time-awaiting node when the time-awaited transaction T0 starts committing, while a non-time-awaited transaction refers to a transaction that has sent a time-awaiting request to the time-awaiting node but has not received a time-awaiting response from the time-awaiting node when the time-awaited transaction T0 starts committing.

[0039] S203, if the timing request of any other transaction is sent at a time no earlier than the start submission time of the transaction to be timed, the timestamp fed back by the timing node for any other transaction is assigned to the transaction to be timed.

[0040] For the same transaction, the execution sequence in time is: transaction begins committing, a time synchronization request is sent to the time synchronization node, the time synchronization node receives the time synchronization request, and the transaction completes committing. That is, the time the transaction completes committing is later than the time the time synchronization node receives the time synchronization request, the time the time synchronization node receives the time synchronization request is later than the time the time synchronization request is sent to the time synchronization node, and the time the time synchronization request is sent to the time synchronization node is later than the time the transaction begins committing. External consistency of a database refers to the fact that the execution sequence of transactions within the database cannot violate the order observed externally. If two transactions can be observed to have a sequential order externally, then the second transaction must have started committing only after the first transaction has completed committing. Otherwise, the two transactions are concurrent, and the database can execute them in any order.

[0041] For example, an external database observes that the first transaction writes data A to a node. After completion, a second transaction starts writing data B to another node. During this process, a third concurrent transaction attempts to read both A and B. If it reads data B but not data A, it means that internally, the second transaction executed before the first, which is the opposite of the order observed externally, meaning external consistency is not satisfied. Therefore, to ensure external consistency, each transaction needs to be assigned a timestamp. The goal of external consistency is that when transaction Tb starts committing after transaction Ta has completed its commit, the timestamp assigned to transaction Tb must be greater than the timestamp assigned to transaction Ta. This ensures that internally, the database executes transaction Ta first, followed by transaction Tb, according to the timestamp size.

[0042] In one embodiment, after transaction T1 completes its commit, transaction T3 begins its commit. To ensure external consistency, the timestamp of transaction T3 needs to be greater than the timestamp of transaction T1. If, when transaction T3 begins its commit, a time synchronization request for another transaction on this node is sent at a time no earlier than the start commit time of transaction T3, then when that transaction receives the timestamp returned by the time synchronization node, transaction T3 can reuse that transaction's timestamp. This will be explained in detail below with reference to Figure 3:

[0043] like Figure 3aAs shown, the time synchronization request sent by transaction T2 at time 306 is later than the start commit time of transaction T3 at time 309. Therefore, it can be deduced that the time synchronization node receives the time synchronization request from transaction T2 at time 307 is later than the start commit time of transaction T3 at time 309. Since transaction T3 only starts committing after transaction T1 has completed its commit, meaning the start commit time of transaction T3 at time 309 is later than the completion commit time of transaction T1 at time 304, it can be further deduced that the time synchronization node receives the time synchronization request from transaction T2 at time 307 is later than the completion commit time of transaction T1 at time 304. Therefore, the timestamp of transaction T2 must be greater than the timestamp of transaction T1. At this point, transaction T3 reuses the timestamp of transaction T2, thus ensuring that the timestamp of transaction T3 is greater than the timestamp of transaction T1, guaranteeing external consistency.

[0044] Of course, if the time synchronization request of transaction T2 is sent at time 306 and the start commit time of transaction T3 is at the same time 309, it can also be deduced that the time the time synchronization node receives the time synchronization request of transaction T2 at time 307 is later than the start commit time of transaction T3 at time 309. Furthermore, it can be deduced that the time the time synchronization node receives the time synchronization request of transaction T2 at time 307 is later than the completion commit time of transaction T1 at time 304, meaning the timestamp of transaction T2 is greater than the timestamp of transaction T1. In this case, transaction T3 reuses the timestamp of transaction T2, which can also guarantee external consistency. In other words, as long as the time synchronization request of transaction T2 is not earlier than the start commit time of transaction T3 at time 309, the reuse of the timestamp of transaction T2 by transaction T3 can guarantee the external consistency between transaction T3 and transaction T1.

[0045] In the above embodiments, the start commit time 305 of transaction T2 can be earlier than the completion commit time 304 of transaction T1, or later than the completion commit time 304 of transaction T1. That is, the start commit time 305 of transaction T2 is unrelated to the reuse of the same timestamp by multiple transactions in this specification.

[0046] Furthermore, in the above embodiments, the timestamp of transaction T1 can be obtained from the time synchronization node, or it can reuse the timestamp of other transactions, as long as the authorization request of the other transaction is sent no earlier than the start commit time of transaction T1. (See reference...) Figure 3b The authorization request sent by transaction T0 at time 311 is later than the start commit time of transaction T1 at time 301. Based on the aforementioned reasoning, transaction T1 can reuse the timestamp of transaction T0. In this case, the completion commit time of transaction T1 at time 304 must be later than the time the time synchronization node receives the time synchronization request from transaction T0 at time 312. Furthermore, according to... Figure 3aThe inference is as follows: The time 307 when the time synchronization node receives the time synchronization request for transaction T2 is later than the completion and commit time 304 of transaction T1. Therefore, the time 307 when the time synchronization node receives the time synchronization request for transaction T2 must be later than the time 312 when the time synchronization node receives the time synchronization request for transaction T0. That is, the timestamp of transaction T2 is greater than the timestamp of transaction T0. Therefore, when transaction T3 reuses the timestamp of transaction T2, and transaction T1 reuses the timestamp of transaction T0, the timestamp of transaction T3 is greater than the timestamp of transaction T1. Thus, external consistency between transactions T1 and T3 is achieved.

[0047] In summary, when the time synchronization request of a certain transaction Tn is sent at a time no earlier than the start commit time of the transaction Tx to be synchronized, i.e., Absolute Time(Tn.Send RPC Request)≥Absolute Time(Tx.Start To Commit), Tx can satisfy external consistency by using the timestamp obtained by Tn.

[0048] In one embodiment, node N1 can prioritize querying the time of the time synchronization request sent by its node to the time synchronization node for the latest synchronized transaction, according to the order in which it receives the timestamp returned by the time synchronization node. Since the time of the time synchronization request of the latest synchronized transaction is stored in the timestamp cache, it can be denoted as Absolute Time(ts cache.Last Send RPC Request). When the time of the time synchronization request of the latest synchronized transaction is not earlier than the start commit time of the transaction to be synchronized T0, i.e., Absolute Time(tscache.Last Send RPC Request) ≥ Absolute Time(T0.Start To Commit), the timestamp received by the latest synchronized transaction is assigned to the transaction to be synchronized T0. That is, the transaction to be synchronized T0 and the latest synchronized transaction reuse the same timestamp, and the version numbers of the two transactions are the same. In this scenario, node N1 does not need to send a time synchronization request to the time synchronization node for the transaction T0 awaiting time synchronization. This reduces the frequency with which node N1 sends such requests, thus decreasing the load on the time synchronization node. Furthermore, since the timestamp received by the latest synchronized transaction is already stored in the cache, the transaction T0 awaiting time synchronization can directly reuse the cached timestamp, significantly reducing the waiting time for time synchronization and thereby improving the processing efficiency of the transaction T0.

[0049] In another embodiment, when the timing request sending time of the latest time-approved transaction does not meet a preset condition, node N1 can query the timing request sending times of other untime-approved transactions on this node that sent their timing requests to the timing node. Similarly, the timing request sending time of untime-approved transactions is denoted as Absolute Time(tscache.Send RPC Request). When it is found that the timing request sending time of any untime-approved transaction is not earlier than the start commit time of the transaction to be time-approved, T0 (i.e., Absolute Time(tscache.Send RPC Request) ≥ Absolute Time(T0.Start To Commit), it means that the timestamp in the timing response corresponding to that untime-approved transaction can be assigned to the transaction to be time-approved, T0, so that the transaction to be time-approved and the untime-approved transaction reuse the same timestamp, and the version numbers of these two transactions are consistent. For example, if a query reveals that the timing request for an untimed transaction T4 meets a preset condition, then the transaction T0 awaiting timing is simply added to the timing queue cached by node N1, waiting for the timing node to return a timing response for the untimed transaction T4. When the untimed transaction T4 receives the timing response from the timing node, it assigns the timestamp from this response to the untimed transaction T0, allowing the untimed transaction T0 and transaction T4 to reuse the same timestamp. In this case, node N1 also does not need to send a timing request to the timing node for the untimed transaction T0, reducing the frequency of node N1 sending timing requests to the timing node, and also reducing the load pressure on the timing node to some extent. In this embodiment, adding the untimed transaction T0 to the timing queue to wait for the timing response from the untimed transaction T4 can be treated as an asynchronous task, thereby avoiding affecting the commit process of other transactions.

[0050] In one embodiment, if the timing request sending times of all transactions on node N1 other than the time-synchronized transaction T0 do not meet a preset condition (i.e., the timing request sending times of all other transactions are earlier than the start commit time of the time-synchronized transaction T0), node N1 needs to send a timing request to the timing node for the time-synchronized transaction T0. The timing node responds to the received timing request by allocating a timestamp and assigning this timestamp to the timing response. The timing response also includes relevant information about the timing request, allowing node N1 to clearly identify which timing request the timing response corresponds to. Because the timestamps of the timing node do not roll back (i.e., the timing node allocates timestamps to transactions on each node in an incremental manner), it can be guaranteed that the timestamp of the latest time-synchronized transaction is always the largest, thus ensuring external consistency of the database.

[0051] In one embodiment, each node in the distributed database is also responsible for receiving any timing response returned by the timing node and comparing the timing request sending time corresponding to the received timing response with the timing request sending time of the latest time-synchronized transaction in the timestamp cache. If the timing request sending time corresponding to the timing response is later than the timing request sending time of the latest time-synchronized transaction in the timestamp cache, then the timing request sending time of the latest time-synchronized transaction in the cache is updated to the timing request sending time of the timing response. Simultaneously, the timestamp stored in the timestamp cache is updated to the timestamp returned by the timing response. If the timing request sending time corresponding to the timing response is not later than the timing request sending time of the latest time-synchronized transaction in the timestamp cache, then the timing response is discarded. This update operation ensures that the time of sending the time request of the latest timed transaction in the cache, i.e., Absolute Time(ts cache.Last Send RPC Request), is always the maximum value in the set of time request times of timed transactions. This allows any transaction awaiting timed ...

[0052] In one embodiment, after each update of the timestamps stored in the timestamp cache, all pending time-synchronization transactions in the pending time-synchronization queue on that node are traversed. Because after the update, the time synchronization request sending time of the latest time-synchronized transaction in the cache is the maximum value in the current set of time synchronization request sending times of time-synchronized transactions in the cache, the updated timestamps can be assigned to all pending time-synchronization transactions whose start commit time is no later than the current maximum time synchronization request sending time.

[0053] In one embodiment, the current status of the timing node can be added to the timing response returned by the timing node. This allows each node to adjust the frequency of sending timing requests to the timing node based on the current status of the timing node when receiving the timing response. For example, the status of the timing node can be divided into three types: normal, idle, and busy. When any node obtains that the current timing node status is idle, it can send timing requests to the timing node one by one for all transactions awaiting timing, thereby increasing the frequency of sending timing requests to the timing node, making full use of the timing node, avoiding resource waste, and ensuring that each transaction awaiting timing can obtain a timestamp allocated by the timing node, thus fully guaranteeing the external consistency of the database. When any node obtains that the current timing node status is busy, it can first check whether there are other transactions on this node that conform to the aforementioned embodiments. If so, the timestamps of the other transactions are allocated to the transactions awaiting timing, thereby reducing the frequency of sending requests to obtain timestamps to the timing node and reducing the load pressure on the timing node. When any node obtains that the current time synchronization node status is normal, it indicates that the frequency at which the current node sends time synchronization requests to the time synchronization node is in a balanced state. As long as the current frequency is maintained, it will not put too much load pressure on the time synchronization node, and at the same time, it can ensure the efficiency of the time synchronization node in processing time synchronization requests and avoid the problem of returning time synchronization responses for too long.

[0054] Corresponding to the above method embodiments, this specification also provides an embodiment of an apparatus.

[0055] Figure 4 This is a schematic diagram illustrating the structure of an electronic device according to an exemplary embodiment of this specification. (Reference) Figure 4 At the hardware level, the electronic device includes a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, and may also include other hardware required for business operations. The processor 402 reads the corresponding computer program from the non-volatile memory 410 into memory 408 and then runs it. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0056] Figure 5 This is a block diagram illustrating a timestamp allocation device applied to a distributed database according to an exemplary embodiment of this specification. (Refer to...) Figure 5 The device includes a submission module 502, a query module 504, and an allocation module 506, wherein:

[0057] The commit module 502 is configured to, in response to a received transaction commit request, commit the corresponding time-pending transaction and record the start commit time of the time-pending transaction.

[0058] The query module 504 is configured to query the time when any node sends a timing request to the timing node for other transactions.

[0059] The allocation module 506 is configured to allocate the timestamp fed back by the timing node for any other transaction to the transaction to be timed if the timing request of any other transaction is sent at a time no earlier than the start submission time of the transaction to be timed.

[0060] Optionally, the query module 504 is specifically used to: query the timing request sending time of any node sending a timing request to the timing node for the latest timed transaction; wherein, if the timed request sending time found is not earlier than the start submission time of the transaction to be timed, the latest timed transaction is determined as any other transaction.

[0061] Optionally, the query module 504 is further configured to: if the timing request sending time of the latest timed transaction is earlier than the start submission time of the timed transaction to be timed, query the timing request sending time of any node sending a timing request to the timing node for other untimed transactions; wherein, if the timing request sending time of any other untimed transaction is not earlier than the start submission time of the timed transaction to be timed, the other untimed transaction is regarded as the other transaction.

[0062] Optionally, the device further includes:

[0063] The sending module 508 is configured to send a timing request to the timing node for the time-to-be-timed transaction when all other time-to-be-timed requests are sent earlier than the start commit time of the time-to-be-timed transaction, so that the time-to-be-timed node can allocate a timestamp to the time-to-be-timed transaction in response to the time-to-be-timed request.

[0064] The receiving module 510 is configured to receive any timing response returned by the timing node.

[0065] The update module 512 is configured to update the timing request sending time of the latest timing transaction in the cache to the timing request sending time of the timing response if the timing request sending time of any timing response is later than the timing request sending time of the latest timing transaction in the cache.

[0066] The traversal module 514 is configured to traverse all pending time-synchronization transactions in the pending time-synchronization queue in the cache, and assign the timestamp of the latest time-synchronized transaction in the cache to all pending time-synchronization transactions that meet the following conditions: the time synchronization request of the latest time-synchronized transaction is sent at a time no earlier than the start commit time of the pending time-synchronization transaction.

[0067] The adjustment module 516 is configured to adjust the frequency at which any node sends a timing request to the timing node based on the current operating status of the timing node contained in any timing response, wherein the current operating status of the timing node indicates the busy level of the timing node.

[0068] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0069] The apparatus or module described in the above embodiments can be implemented by a computer chip or entity, or by a product with a certain function. A typical implementation device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0070] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0071] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0072] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0073] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A timestamp allocation method applied to a distributed database, wherein nodes of the distributed database comprise a time-providing node and common nodes, the method is applied to any node, and the method comprises: in response to a received transaction commit request, committing a corresponding to-be-time-provided transaction and recording a start commit time of the to-be-time-provided transaction; inquiring a time-providing request sending time of the any node sending a time-providing request to the time-providing node for other transactions; in a case where the time-providing request sending time of any other transaction is not earlier than the start commit time of the to-be-time-provided transaction, allocating a timestamp fed back by the time-providing node for the any other transaction to the to-be-time-provided transaction. 2.The method of claim 1, wherein the inquiring the time-providing request sending time of the any node sending a time-providing request to the time-providing node for other transactions comprises: inquiring a time-providing request sending time of the any node sending a time-providing request to the time-providing node for a latest time-provided transaction; wherein in a case where the inquired time-providing request sending time is not earlier than the start commit time of the to-be-time-provided transaction, the latest time-provided transaction is determined as the any other transaction. 3.The method of claim 2, wherein the inquiring the time-providing request sending time of the any node sending a time-providing request to the time-providing node for other transactions comprises: inquiring a time-providing request sending time of the any node sending a time-providing request to the time-providing node for other non-time-provided transactions in a case where the time-providing request sending time of the latest time-provided transaction is earlier than the start commit time of the to-be-time-provided transaction; wherein in a case where the time-providing request sending time of any other non-time-provided transaction is not earlier than the start commit time of the to-be-time-provided transaction, the any other non-time-provided transaction is taken as the any other transaction. 4.The method of claim 1, further comprising: in a case where the time-providing request sending time of all other transactions is earlier than the start commit time of the to-be-time-provided transaction, sending a time-providing request to the time-providing node for the to-be-time-provided transaction, so as to allocate a timestamp by the time-providing node to the to-be-time-provided transaction in response to the time-providing request. 5.The method of claim 1, further comprising: receiving any time-providing response returned by the time-providing node; in a case where the time-providing request sending time corresponding to the any time-providing response is later than the time-providing request sending time of the latest time-provided transaction in a cache, updating the time-providing request sending time of the latest time-provided transaction in the cache to the time-providing request sending time corresponding to the any time-providing response. 6.The method of claim 1, further comprising: receiving any time-providing response returned by the time-providing node, wherein the any time-providing response contains a current running state of the time-providing node, and the current running state of the time-providing node indicates a busy degree of the time-providing node; adjusting a frequency of sending a time-providing request to the time-providing node by the any node according to the current running state of the time-providing node. 7.The method of claim 1, further comprising: Traverse all the to-be-time-synchronized transactions in the to-be-time-synchronized queue in the cache, and assign the timestamp of the latest time-synchronized transaction in the cache to all the to-be-time-synchronized transactions satisfying the condition, the condition including that the time-synchronized request sending time of the latest time-synchronized transaction is not earlier than the start commit time of the to-be-time-synchronized transaction.

8. A timestamp assignment apparatus applied to a distributed database, nodes of the distributed database including time-synchronized nodes and normal nodes, the apparatus being applied to any node, the apparatus comprising: a commit module configured to, in response to a received transaction commit request, commit a corresponding to-be-time-synchronized transaction and record a start commit time of the to-be-time-synchronized transaction; a query module configured to query a time-synchronized request sending time at which the any node sends a time-synchronized request to the time-synchronized node for other transactions; an assignment module configured to, in a case where the time-synchronized request sending time of any other transaction is not earlier than the start commit time of the to-be-time-synchronized transaction, assign a timestamp fed back by the time-synchronized node for the any other transaction to the to-be-time-synchronized transaction.

9. An electronic device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method of any one of claims 1-7 by running the executable instructions.

10. A computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any one of claims 1-7.

Images