WO2024093543A1 - 一种应用于分布式数据库的时间戳分配方法及装置 - Google Patents

一种应用于分布式数据库的时间戳分配方法及装置 Download PDF

Info

Publication number
WO2024093543A1
WO2024093543A1 PCT/CN2023/118659 CN2023118659W WO2024093543A1 WO 2024093543 A1 WO2024093543 A1 WO 2024093543A1 CN 2023118659 W CN2023118659 W CN 2023118659W WO 2024093543 A1 WO2024093543 A1 WO 2024093543A1
Authority
WO
WIPO (PCT)
Prior art keywords
timing
transaction
node
timed
time
Prior art date
Application number
PCT/CN2023/118659
Other languages
English (en)
French (fr)
Inventor
韩富晟
李欣泽
郭进伟
高山岩
肖金亮
Original Assignee
北京奥星贝斯科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京奥星贝斯科技有限公司 filed Critical 北京奥星贝斯科技有限公司
Publication of WO2024093543A1 publication Critical patent/WO2024093543A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements

Definitions

  • One or more embodiments of the present specification relate to the field of database technology, and in particular, to a timestamp allocation method and device applied to a distributed database.
  • distributed databases not only inherit the core features of traditional stand-alone databases, but also have the processing capabilities of distributed systems, with low hardware costs, high scalability, and high availability.
  • Distributed databases are composed of multiple nodes, and each node needs to communicate with each other by exchanging messages. Since the database instance on each node has an independent clock, and the clock on each node cannot reflect the global order, there will be clock offsets and the consistency of the distributed database cannot be guaranteed.
  • a globally consistent version number can be provided through a clock service.
  • the clock service uses a timestamp (ts) to establish a sequence relationship for transactions in the database.
  • ts timestamp
  • a single timing node provides a clock service to transactions in the database. The single timing node can ensure that timestamps are assigned to transactions of each node in an incremental manner, thereby ensuring the consistency of transactions in the database.
  • This specification provides a timestamp allocation method and device applied to a distributed database to solve the deficiencies in the related art.
  • a timestamp allocation method for a distributed database wherein the nodes of the distributed database include timing nodes and ordinary nodes, and the method is applied to any node, and the method comprises: in response to a received transaction submission request, submitting a corresponding transaction to be timed and recording the transaction to be timed. The start submission time of the timing transaction; query the timing request sending time of any node sending the timing request to the timing node for other transactions; when the timing request sending time of any other transaction is not earlier than the start submission time of the transaction to be timed, assign the timestamp fed back by the timing node for any other transaction to the transaction to be timed.
  • a timestamp allocation device applied to a distributed database
  • the nodes of the distributed database include timing nodes and ordinary nodes
  • the device is applied to any node
  • the device includes: a submission module, for submitting a corresponding transaction to be timed in response to a received transaction submission request and recording the start submission time of the transaction to be timed; a query module, for querying the timing request sending time when any node sends a timing request to the timing node for other transactions; and an allocation module, for allocating the timestamp fed back by the timing node for any other transaction to the transaction to be timed, if the timing request sending time of any other transaction is not earlier than the start submission time of the transaction to be timed.
  • an electronic device comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method described in the embodiment of the first aspect above by running the executable instructions.
  • a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method described in the embodiment of the first aspect above.
  • a timestamp cache is added to each node of the distributed database to save the timestamp that has been obtained from the timing node, so that multiple transactions can reuse the same timestamp on the basis of ensuring the external consistency of the database, thereby: on the one hand, the frequency of each node sending a request to obtain a timestamp to the timing node is effectively reduced, and correspondingly, the load generated by the timing node processing the request is reduced, while also avoiding the problem of the timing node taking too long to return a timing response due to an overload of the timing node; on the other hand, since waiting for the timing node to assign a timestamp is avoided, the waiting time is shortened, thereby greatly improving the processing efficiency of each transaction and ensuring the performance of the database.
  • FIG. 1 is an architecture diagram of a distributed database provided by an exemplary embodiment.
  • FIG. 2 is a flow chart of a timestamp allocation method applied to a distributed database provided by an exemplary embodiment.
  • FIG. 3 a is a schematic diagram of ensuring external consistency of a distributed database provided by an exemplary embodiment.
  • FIG. 3 b is a schematic diagram of another exemplary embodiment for ensuring external consistency of a distributed database.
  • FIG. 4 is a schematic structural diagram of an electronic device provided by an exemplary embodiment.
  • FIG5 is a block diagram of a timestamp allocating device applied to a distributed database provided by an exemplary embodiment.
  • the steps of the corresponding method are not necessarily performed in the order shown and described in this specification.
  • the method may include more or fewer steps than those described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.
  • FIG. 1 is an architecture diagram of a distributed database provided by an exemplary embodiment.
  • the distributed database is composed of multiple nodes, including a timing node and an ordinary node. All ordinary nodes send a timing request to the timing node to obtain a timestamp assigned by the timing node.
  • the consistency of transactions in the database is ensured by a single timing node under this architecture providing clock services to transactions in the database.
  • this single-point timing method requires each ordinary node to send a timing request to the timing node one by one for each transaction on the node, which easily leads to an excessively high load on the timing node to process the timing request.
  • the processing upper limit of the timing node When the processing upper limit of the timing node is reached, the response time of the timing request will be greatly increased. Furthermore, for each transaction, a timing request needs to be sent to the timing node each time it is submitted, and the timing node needs to wait for the assigned timestamp to be returned, which will greatly increase the execution time of each transaction and reduce the database performance.
  • This specification provides a timestamp allocation method applied to a distributed database to solve the problems in the related art. foot.
  • FIG2 is a flowchart of a timestamp allocation method applied to a distributed database provided by an exemplary embodiment.
  • the method can be applied to any node of the distributed database in FIG1.
  • the method is also applicable to the timing node. As shown in FIG2, the method may include the following steps S201 to S203.
  • S201 in response to a received transaction submission request, submit a corresponding transaction to be timed and record a start submission time of the transaction to be timed.
  • a database transaction can be understood as a logical unit in the database execution process, which consists of a finite sequence of database operations. Usually a transaction will contain multiple read and write operations. Transactions have four basic characteristics: atomicity, consistency, isolation, and durability. The durability of a transaction determines that the transaction will only be effective if it is committed. After submission, the transaction's related modifications to the database can be permanently saved in the database and read by other users. If it is not submitted, the transaction content will be stored in the cache and can be rolled back at any time. There are three ways to commit a database transaction: manual explicit submission, implicit submission, and automatic submission. Those skilled in the art can set them according to actual needs, and this manual does not limit this.
  • the entire process of transaction execution can be divided into three stages: transaction start submission, transaction acquisition timestamp, and transaction completion submission.
  • the timestamp acquisition process can be divided into the ordinary node sending a timing request to the timing node for the submitted transaction, the timing node receiving the timing request and returning the timing response to the ordinary node that sent the timing request, and the ordinary node receiving the timing response and obtaining the timestamp fed back to the transaction.
  • this process of obtaining timestamps is time-consuming, and the method in which each transaction needs to send a timing request to the timing node separately is likely to cause the load of the timing node to process the request to be too high.
  • this manual proposes another way to obtain timestamps, that is, multiple transactions reuse the same timestamp.
  • any node in the distributed database receives a transaction submission request, it submits the corresponding transaction to be timed, and records the start submission time of the transaction to be timed for use in subsequent processes.
  • the start submission time of the transaction to be timed can be recorded as Absolute Time (Start To Commit).
  • the node that receives the transaction submission request needs to send a timing request to the timing node so that the timing node can assign a timestamp to the transaction to be timed. Therefore, there will be a time when the timing request is sent to the timing node.
  • the transaction submission start time and the timing request sending time are not the same time, and there is a certain time difference between the two.
  • Information exchange depends on the RPC (Remote Procedure Call) protocol, so the time when the timing request is sent can be recorded as Absolute Time (Send RPC Request).
  • RPC Remote Procedure Call
  • ordinary nodes and timing nodes can also exchange information based on other protocols, which is not limited in this specification.
  • ordinary node N1 receives the commit request of transaction T0, commits transaction T0 in response to the request, and records the start commit time of transaction T0, which is recorded as Absolute Time (T0.Start To Commit). At this time, transaction T0 is a transaction to be timed, and a timestamp needs to be assigned to it. After node N1 records the start commit time of transaction T0 to be timed, node N1 can query the time when this node sends a timing request to the timing node for other transactions.
  • Other transactions here can be understood as all transactions on node N1 that have sent timing requests to the timing node except the current transaction T0 to be timed, including transactions that have been timed and transactions that have not been timed.
  • a transaction that has been timed refers to a transaction that has sent a timing request to the timing node and has received a timing response returned by the timing node when the transaction T0 to be timed starts to be committed
  • an untimed transaction refers to a transaction that has sent a timing request to the timing node but has not received a timing response returned by the timing node when the transaction T0 to be timed starts to be committed.
  • the time sequence of its entire execution process is transaction start submission, sending timing request to timing node, timing node receiving timing request, and transaction completion submission.
  • the moment when transaction completion submission is later than the moment when timing node receives timing request
  • the moment when timing node receives timing request is later than the moment when timing request is sent to timing node
  • the moment when timing request is sent to timing node is later than the moment when transaction starts submission.
  • the external consistency of database means that the execution sequence of transactions inside the database cannot violate the order observed outside. If the database can observe that there is a sequence between two transactions, then the latter transaction must be submitted after the former transaction is completed. Otherwise, the two transactions are concurrent, and the database can execute these two transactions in any order.
  • the first transaction is observed outside the database to write data A on a node.
  • the second transaction is started to write data B on another node.
  • the goal of external consistency is that when transaction Ta is completed and transaction Tb starts to start committing, the timestamp assigned to transaction Tb must be greater than the timestamp assigned to transaction Ta. This can ensure that transaction Ta is executed first and then transaction Tb according to the size of the timestamp inside the database.
  • transaction T3 starts to submit.
  • the timestamp of transaction T3 needs to be greater than the timestamp of transaction T1. If, when transaction T3 starts to submit, there is a transaction on this node whose timing request is sent at a time not earlier than the start submission time of transaction T3, then when the transaction receives the timestamp returned by the timing node, transaction T3 can reuse the timestamp of the transaction.
  • the time 306 of sending the timing request of transaction T2 is later than the start submission time 309 of transaction T3, then it can be inferred that the time 307 when the timing node receives the timing request of transaction T2 is later than the start submission time 309 of transaction T3.
  • transaction T3 starts to submit after transaction T1 is submitted, that is, the start submission time 309 of transaction T3 is later than the completion submission time 304 of transaction T1
  • the timestamp of transaction T2 must be greater than the timestamp of transaction T1.
  • transaction T3 reuses the timestamp of transaction T2, so that the timestamp of transaction T3 is greater than the timestamp of transaction T1, thereby ensuring external consistency.
  • time 306 of sending the timing request of transaction T2 is the same as the time 309 of starting to commit transaction T3, it can also be obtained that the time 307 when the timing node receives the timing request of transaction T2 is later than the time 309 of starting to commit transaction T3. It can be further deduced that the time 307 when the timing node receives the timing request of transaction T2 is later than the time 304 of completing to commit transaction T1, that is, the timestamp of transaction T2 is greater than the timestamp of transaction T1.
  • transaction T3 reuses the timestamp of transaction T2, which can also ensure external consistency. That is to say, when the time 306 of sending the timing request of transaction T2 is not earlier than the time 309 of starting to commit transaction T3, transaction T3 reuses the timestamp of transaction T2, which can ensure the external consistency between transaction T3 and transaction T1.
  • the start commit time 305 of transaction T2 may 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 has nothing to do with the reuse of the same timestamp by multiple transactions in this specification.
  • the timestamp of transaction T1 can be obtained from the timing node, or the timestamp of other transactions can be reused, as long as the authorization request sending time of the other transaction is not earlier than the start submission time of transaction T1.
  • the authorization request sending time 311 of transaction T0 is later than the start submission time 301 of transaction T1.
  • transaction T1 can reuse the timestamp of transaction T0.
  • the completion submission time 304 of transaction T1 must be later than the time 312 when the timing node receives the timing request of transaction T0.
  • the time 307 when the timing node receives the timing request of transaction T2 is later than the completion submission time 304 of transaction T1, so the time 307 when the timing node receives the timing request of transaction T2 must be later than the time 312 when the timing node receives the timing request of transaction T0, that is, the timestamp of transaction T2 is greater than the timestamp of transaction T0.
  • the timestamp of transaction T3 is greater than the timestamp of transaction T1, thereby realizing the transaction External consistency of transaction T1 and transaction T3.
  • Tx when the time when the timing request of a transaction Tn is sent is not earlier than the start commit time of the transaction Tx to be timed, that is, Absolute Time (Tn.Send RPC Request) ⁇ Absolute Time (Tx.Start To Commit), Tx can meet external consistency by using the timestamp obtained by Tn.
  • node N1 may first query the time when the node sends the timing request to the timing node for the latest timed transaction in the order in which the timestamps returned by the timing node are received. Since the time when the timing request is sent for the latest timed transaction is stored in the timestamp cache, the time when the timing request is sent for the latest timed transaction may be recorded as Absolute Time(ts cache.Last Send RPC Request).
  • the timestamp received by the latest timed transaction is assigned to the transaction to be timed T0, that is, the transaction to be timed T0 and the latest timed transaction reuse the same timestamp, and the version numbers of the two transactions are consistent.
  • node N1 does not need to send a timing request to the timing node for the pending timing transaction T0.
  • the frequency of node N1 sending timing requests to the timing node is reduced, and at the same time, the load pressure of the timing node is correspondingly reduced.
  • the pending timing transaction T0 can directly reuse the timestamp in the cache, which greatly reduces the waiting time for timing, thereby improving the processing efficiency of the pending timing transaction T0.
  • node N1 when the time of sending the timing request of the latest timed transaction does not meet the preset conditions, node N1 can query the time of sending the timing request of other untimed transactions on this node except the latest timed transaction to send the timing request to the timing node. Similarly, the time of sending the timing request of the untimed transaction is recorded as Absolute Time (ts cache.Send RPC Request). When it is found that the time of sending the timing request of any untimed transaction is not earlier than the start commit time of the transaction to be timed T0.
  • the timestamp in the timing response is assigned to the waiting transaction T0, so that the waiting transaction T0 and transaction T4 reuse the same timestamp.
  • node N1 also does not need to send a timing request to the timing node for the waiting transaction T0, which reduces the frequency of node N1 sending timing requests to the timing node, and at the same time, reduces the load pressure of the timing node to a certain extent.
  • the waiting transaction T0 is added to the waiting queue.
  • the timing queue can be used as an asynchronous task to wait for the timing response of the untimed transaction T4 to return, thereby avoiding affecting the submission process of other transactions.
  • the node N1 when the sending time of the timing request of all transactions other than the waiting timing transaction T0 on the node N1 does not meet the preset condition, that is, the sending time of the timing request of all other transactions is earlier than the start submission time of the waiting timing transaction T0, the node N1 needs to send a timing request to the timing node for the waiting timing transaction T0.
  • the timing node assigns a timestamp in response to the received timing request, assigns this timestamp in the timing response, and the timing response includes the relevant information of the timing request, so that when the node N1 receives the timing response, it can clearly know which timing request the timing response corresponds to.
  • the timing node Because the timestamp of the timing node will not roll back, that is, the timing node assigns timestamps to the transactions of each node in an incremental manner, it can be guaranteed that the timestamp of the latest timing transaction must be the largest, thereby ensuring the external consistency of the database.
  • 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 timed 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 timed transaction in the timestamp cache, then the timing request sending time of the latest timed transaction in the cache is updated to the timing request sending time corresponding to the timing response. At the same time, the timestamp stored in the timestamp cache is updated to the timestamp fed back by the timing response.
  • Timing response is discarded.
  • This update operation can ensure that the time when the timing request of the latest timed transaction in the cache is sent, that is, Absolute Time (ts cache.Last Send RPC Request), is always the maximum value in the set of time when the timing request is sent of the timed transactions.
  • Absolute Time ts cache.Last Send RPC Request
  • the updated timestamp can be assigned to all pending timing transactions whose start submission time is not later than the current maximum timing request sending time.
  • the status of the current timing node can be added to the timing response returned by the timing node, so that when each node receives the timing response, it adjusts the frequency of sending timing requests to the timing node according to the status of the current timing node.
  • 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, the node can send timing requests to the timing node one by one for all current timing transactions, thereby increasing the frequency of sending timing requests to the timing node and achieving timing control.
  • the nodes are fully utilized to avoid waste of resources, and each transaction to be timed can obtain the timestamp assigned by the timing node, which fully guarantees the external consistency of the database.
  • any node When any node obtains that the current timing node state is busy, it can first query whether there are other transactions that meet the above-mentioned embodiment on this node. If so, the timestamps of other transactions are assigned to the transaction to be timed, thereby reducing the frequency of sending requests to obtain timestamps to the timing node and reducing the load pressure of the timing node.
  • any node obtains that the current timing node state is normal it indicates that the frequency of the current node sending timing requests to the timing node is in a balanced state. As long as the current frequency is maintained, it will not cause excessive load pressure on the timing node. At the same time, it can also ensure the efficiency of the timing node in processing timing requests, and avoid the problem of returning timing responses for too long.
  • this specification also provides an embodiment of a device.
  • FIG4 is a schematic diagram of the structure of an electronic device according to an exemplary embodiment of this specification.
  • the electronic device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, and may also include hardware required for other services.
  • the processor 402 reads the corresponding computer program from the non-volatile memory 410 into the memory 408 and then runs it.
  • this specification does not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.
  • FIG5 is a block diagram of a timestamp allocation device applied to a distributed database according to an exemplary embodiment of the present specification.
  • the device includes a submission module 502, a query module 504, and an allocation module 506, wherein:
  • the submission module 502 is configured to submit the corresponding transaction to be timed in response to the received transaction submission request and record the start submission time of the transaction to be timed.
  • the query module 504 is configured to query the time when any of the nodes sends a timing request to the timing node for other transactions.
  • 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 sending time of any other transaction is not earlier than the start submission time of the transaction to be timed.
  • the query module 504 is specifically used to: query the time when any node sends a timing request to the timing node for the latest timed transaction; wherein, if the queried time when the timing request is sent is not earlier than the start submission time of the transaction to be timed, the latest timed transaction is determined as any other transaction.
  • the query module 504 is further configured to: At the start submission time of the transaction to be timed, query the time when any node sends a timing request to the timing node for other untimed transactions; wherein, if the time when the timing request is sent for any other untimed transaction is not earlier than the start submission time of the transaction to be timed, treat any other untimed transaction as any other transaction.
  • the device also includes: a sending module 508, which is configured to send a timing request to the timing node for the transaction to be timed, when the timing request sending time of all other transactions is earlier than the start submission time of the transaction to be timed, so that the timing node assigns a timestamp to the transaction to be timed in response to the timing request.
  • a sending module 508 which is configured to send a timing request to the timing node for the transaction to be timed, when the timing request sending time of all other transactions is earlier than the start submission time of the transaction to be timed, so that the timing node assigns a timestamp to the transaction to be timed in response to the timing request.
  • the receiving module 510 is configured to receive any timing response returned by the timing node.
  • the updating 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 corresponding to the timing response when the timing request sending time corresponding to any timing response is later than the timing request sending time of the latest timing transaction in the cache.
  • the traversal module 514 is configured to traverse all the transactions to be timed in the queue to be timed in the cache, and assign the timestamp of the latest timed transaction in the cache to all the transactions to be timed that meet the conditions, wherein the conditions include: the time when the timing request of the latest timed transaction is sent is not earlier than the start submission time of the transaction to be timed.
  • the adjustment module 516 is configured to adjust the frequency of any node sending timing requests to the timing node according to the current operating status of the timing node contained in any timing response, wherein the current operating status of the timing node indicates the busyness of the timing node.
  • a typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
  • a computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash RAM.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information.
  • Information can be computer readable instructions, data structures, program modules 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本说明书提出了一种应用于分布式数据库的时间戳分配方法及装置，所述分布式数据库的节点包括授时节点和普通节点，所述方法应用于任一节点，该方法可以包括：响应于接收的事务提交请求，提交相应的待授时事务并记录待授时事务的开始提交时刻；查询任一节点针对其他事务向授时节点发送授时请求的授时请求发送时刻；在任一其他事务的授时请求发送时刻不早于待授时事务的开始提交时刻的情况下，将授时节点针对该任一其他事务反馈的时间戳分配至待授时事务。通过本说明书的技术方案，可以有效降低各节点向授时节点发送获取时间戳请求的频率，减少授时节点的负载，避免因授时节点过载导致授时节点返回授时响应过久的问题，提高各个事务的处理效率。

Description

一种应用于分布式数据库的时间戳分配方法及装置 技术领域
本说明书一个或多个实施例涉及数据库技术领域，尤其涉及一种应用于分布式数据库的时间戳分配方法及装置。
背景技术
分布式数据库作为分布式系统中的重要应用部分，不仅继承了传统单机数据库的核心特性，同时还拥有分布式系统的处理能力，具有低硬件成本、高可扩展性、高可用性等特性。分布式数据库由多个节点组成，各个节点需要通过交换消息来相互通信。由于每个节点上的数据库实例拥有独立的时钟，而每个节点上的时钟不能反映全局的顺序，因此会存在时钟偏移、无法保证分布式数据库的一致性的情况。
为了避免发生时钟偏移，可以通过时钟服务来提供全局一致的版本号。时钟服务即利用时间戳(timestamp，ts)为数据库中的事务建立一个先后关系，时间戳越大表示事务的版本号越大，该事务的顺序越靠后。相关技术中通过单一的授时节点统一给数据库中的事务提供时钟服务，单一授时节点可以保证按照递增的方式给各节点的事务分配时间戳，从而确保数据库中事务的一致性。
对于此类使用单点授时时钟服务的分布式数据库来说，所有节点针对每个事务都需要向该授时节点发送获取时间戳的请求，容易导致该授时节点负载过高，当达到授时节点的处理上限时，会大大增加时间戳获取请求的响应时间。再者，对各个事务而言，每次提交时都需要向授时节点发送请求，并等待授时节点返回分配的时间戳，会大大增加各个事务处理的时间，降低数据库性能。
发明内容
本说明书提供一种应用于分布式数据库的时间戳分配方法及装置，以解决相关技术中的不足。
根据本说明书一个或多个实施例的第一方面，提供一种应用于分布式数据库的时间戳分配方法，所述分布式数据库的节点包括授时节点和普通节点，所述方法应用于任一节点，该方法包括：响应于接收的事务提交请求，提交相应的待授时事务并记录所述待 授时事务的开始提交时刻；查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻；在任一其他事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述授时节点针对该任一其他事务反馈的时间戳分配至所述待授时事务。
根据本说明书一个或多个实施例的第二方面，提供一种应用于分布式数据库的时间戳分配装置，所述分布式数据库的节点包括授时节点和普通节点，所述装置应用于任一节点，该装置包括：提交模块，用于响应于接收的事务提交请求，提交相应的待授时事务并记录所述待授时事务的开始提交时刻；查询模块，用于查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻；分配模块，用于在任一其他事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述授时节点针对该任一其他事务反馈的时间戳分配至所述待授时事务。
根据本说明书一个或多个实施例的第三方面，提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如上述第一方面的实施例中所述的方法。
根据本说明书一个或多个实施例的第四方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述第一方面的实施例中所述方法的步骤。
由以上技术方案可见，本说明书一个或多个实施例中，通过在分布式数据库的各个节点增加时间戳缓存来保存曾经从授时节点中获取到的时间戳，使得在保证数据库外部一致性的基础上，多个事务可以复用同一个时间戳，从而：一方面，有效降低了各节点向授时节点发送获取时间戳请求的频率，相应的，减少了授时节点处理请求所产生的负载，同时也避免了因授时节点过载导致授时节点返回授时响应过久的问题；另一方面，由于避免了等待授时节点分配时间戳，所以缩短了等待时长，从而大大提高了各个事务的处理效率，保证了数据库的性能。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施 例，并与说明书一起用于解释本说明书的原理。
图1是一示例性实施例提供的一种分布式数据库的架构图。
图2是一示例性实施例提供的一种应用于分布式数据库的时间戳分配方法的流程图。
图3a是一示例性实施例提供的一种保证分布式数据库外部一致性的示意图。
图3b是另一示例性实施例提供的一种保证分布式数据库外部一致性的示意图。
图4是一示例性实施例提供的一种电子设备的结构示意图。
图5是一示例性实施例提供的一种应用于分布式数据库的时间戳分配装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
分布式数据库因其高可扩展性、高可靠性而被广泛应用于数据的存储及管理。图1是一示例性实施例提供的一种分布式数据库的架构图。如图1所示，分布式数据库由多个节点组成，包括授时节点和普通节点。所有普通节点均向授时节点发送授时请求，以获取授时节点分配的时间戳。相关技术中通过此架构下单一授时节点统一给数据库中的事务提供时钟服务的方式来保证数据库中事务的一致性。但这种单点授时的方式，使得各普通节点需要针对本节点上的每个事务逐一向授时节点发送授时请求，容易导致授时节点处理授时请求的负载过高，当达到授时节点的处理上限时，会大大增加授时请求的响应时间。再者，对各个事务而言，每次提交时都需要向授时节点发送授时请求，并等待授时节点返回分配的时间戳，会大大增加各个事务执行的时间，降低数据库性能。
本说明书提供一种应用于分布式数据库的时间戳分配方法，以解决相关技术中的不 足。
图2是一示例性实施例提供的一种应用于分布式数据库的时间戳分配方法的流程图。该方法可以应用于图1中分布式数据库的任一节点。除普通节点外，当授时节点不仅具备授时功能、还能实现普通节点对事务的处理功能时，该方法同样适用于授时节点。如图2所示，该方法可以包括以下步骤S201至S203。
S201，响应于接收的事务提交请求，提交相应的待授时事务并记录所述待授时事务的开始提交时刻。
数据库的事务可以理解为数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。通常一个事务会包含多个读写操作。事务具有四个基本特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。事务的持久性决定了事务只有提交才会有效，提交之后，事务对数据库的相关修改就能永久保存在数据库中，被其他用户读取，如果不提交，事务内容会存在缓存中，随时可以回滚。数据库事务有三种提交方式：手动显式提交、隐式提交以及自动提交，本领域技术人员可以根据实际需求自行设置，本说明书对此不做限定。
一般的，事务执行的整个过程可以分为事务开始提交、事务获取时间戳、事务完成提交三个阶段。其中，时间戳的获取过程可以分为普通节点针对提交的事务向授时节点发送授时请求、授时节点接收授时请求并向发送此授时请求的普通节点返回授时响应、普通节点接收授时响应并获取反馈至该事务的时间戳。但这种获取时间戳的过程比较耗时，并且每个事务都需要单独向授时节点发送授时请求的方式容易导致授时节点处理请求的负载过高。基于此，本说明书提出另一种获取时间戳的方式，即多个事务复用同一个时间戳。具体的，当分布式数据库中的任一节点接收到事务提交请求时，提交相应的待授时事务，并记录该待授时事务的开始提交时刻，以便后续过程使用。本说明书中可以将待授时事务的开始提交时刻记作Absolute Time(Start To Commit)。
S202，查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻。
通常，在待授时事务开始提交之后，接收该事务提交请求的节点需要向授时节点发送授时请求，以使得授时节点对该待授时事务分配时间戳。因此，会存在一个向授时节点发送授时请求的授时请求发送时刻。通常情况下，事务的开始提交时刻与授时请求发送时刻不是同一时刻，两者存在一定的时间差。本说明书中普通节点与授时节点之间的 信息交互依赖于RPC(Remote Procedure Call)协议，所以可以把授时请求发送时刻记作Absolute Time(Send RPC Request)。当然，普通节点与授时节点也可以基于其他协议进行信息交互，本说明书对此不做限定。
以普通节点N1为例，在一实施例中，普通节点N1接收到事务T0的提交请求，响应于该请求提交事务T0，并且记录下事务T0的开始提交时刻，记作Absolute Time(T0.Start To Commit)。此时事务T0为待授时事务，需要对其分配时间戳。当节点N1记录下待授时事务T0的开始提交时刻后，节点N1可以查询本节点针对其他事务向授时节点发送授时请求的授时请求发送时刻。这里的其他事务可以理解为节点N1上除当前待授时事务T0外的所有已经向授时节点发送授时请求的事务，包括已授时事务和未授时事务。其中，已授时事务指的是已向授时节点发送授时请求、且在待授时事务T0开始提交时已收到授时节点返回授时响应的事务，而未授时事务指的是已向授时节点发送授时请求、但在待授时事务T0开始提交时未收到授时节点返回授时响应的事务。
S203，在任一其他事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述授时节点针对该任一其他事务反馈的时间戳分配至所述待授时事务。
对于同一个事务而言，其整个执行过程在时间上的顺序为事务开始提交、向授时节点发送授时请求、授时节点接收授时请求、事务完成提交。也就是说，事务完成提交的时刻晚于授时节点接收授时请求的时刻，授时节点接收授时请求的时刻晚于向授时节点发送授时请求的时刻，向授时节点发送授时请求的时刻晚于事务开始提交的时刻。而数据库的外部一致性指的是事务在数据库内部的执行序列不能违背外部观察到的顺序。如果数据库外部能够观察到两个事务存在先后顺序，那么一定是前一个事务完成提交后，后一个事务才开始提交。否则两个事务就是并发的，数据库内部可以以任意顺序执行这两个事务。
举个例子，数据库外部观察到第一个事务在一个节点写入数据A，完成后，开始启动第二个事务在另一个节点写入数据B。在这个过程中另有第三个并发运行的事务尝试读A和B，如果读到了数据B却没有读到数据A，那意味着在数据库内部第二个事务先于第一个事务执行了，这与数据库外部观察到的顺序相反，即没有满足外部一致性。因此，为了保证数据库的外部一致性，需要给每个事务分配时间戳。外部一致性的目标是当事务Ta完成提交后，事务Tb才开始启动提交时，事务Tb分配到的时间戳必须大于事务Ta分配到的时间戳，这才能保证数据库内部按照时间戳的大小先执行事务Ta再执行事务Tb。
在一实施例中，事务T1完成提交后，事务T3开始提交，为了保证外部一致性，需要使得事务T3的时间戳大于事务T1的时间戳。如果在事务T3开始提交时，本节点上存在某一事务的授时请求发送时刻不早于事务T3的开始提交时刻，那么当该事务收到授时节点返回的时间戳时，事务T3可以复用该事务的时间戳。下面结合图3进行详细说明：如图3a所示，事务T2的授时请求发送时刻306晚于事务T3的开始提交时刻309，那么可以推出授时节点接收事务T2授时请求的时刻307晚于事务T3的开始提交时刻309。又因为事务T3是在事务T1完成提交后才开始启动提交，即事务T3的开始提交时刻309晚于事务T1的完成提交时刻304，进一步可以推出授时节点接收事务T2授时请求的时刻307晚于事务T1的完成提交时刻304，那么，事务T2的时间戳一定大于事务T1的时间戳。此时，事务T3复用事务T2的时间戳，即可实现事务T3的时间戳大于事务T1的时间戳，从而保证了外部一致性。
当然，如果事务T2的授时请求发送时刻306与事务T3的开始提交时刻309为同一时刻，同样可以得到授时节点接收事务T2授时请求的时刻307晚于事务T3的开始提交时刻309，进一步可以推出授时节点接收事务T2授时请求的时刻307晚于事务T1的完成提交时刻304，即事务T2的时间戳大于事务T1的时间戳。此时，事务T3复用事务T2的时间戳，同样可以保证外部一致性。也就是说，在事务T2的授时请求发送时刻306不早于事务T3的开始提交时刻309的情况下，事务T3复用事务T2的时间戳，可以保证事务T3与事务T1之间的外部一致性。
上述实施例中，事务T2的开始提交时刻305可以早于事务T1的完成提交时刻304，也可以晚于事务T1的完成提交时刻304，即事务T2的开始提交时刻305与本说明书中多个事务复用同一个时间戳无关。
此外，上述实施例中，事务T1的时间戳可以从授时节点获取，也可以复用其他事务的时间戳，只要该其他事务的授权请求发送时刻不早于事务T1的开始提交时刻即可。参考图3b，事务T0的授权请求发送时刻311晚于事务T1的开始提交时刻301，根据前述推论，事务T1可以复用事务T0的时间戳，此时事务T1的完成提交时刻304一定晚于授时节点接收事务T0授时请求的时刻312。又根据图3a中的推论：授时节点接收事务T2授时请求的时刻307晚于事务T1的完成提交时刻304，所以授时节点接收事务T2授时请求的时刻307一定晚于授时节点接收事务T0授时请求的时刻312，即事务T2的时间戳大于事务T0的时间戳。那么，当事务T3复用事务T2的时间戳、且事务T1复用事务T0的时间戳时，事务T3的时间戳大于事务T1的时间戳，由此，实现了事务 T1和事务T3的外部一致性。
综上，当存在某一事务Tn的授时请求发送时刻不早于待授时事务Tx的开始提交时刻，即Absolute Time(Tn.Send RPC Request)≥Absolute Time(Tx.Start To Commit)时，Tx使用Tn获取的时间戳即可满足外部一致性。
在一实施例中，节点N1可以按照收到授时节点返回时间戳的先后顺序，优先查询本节点针对最新已授时事务向授时节点发送授时请求的授时请求发送时刻。由于最新已授时事务的授时请求发送时刻存储在时间戳缓存中，所以，可以将最新已授时事务的授时请求发送时刻记作Absolute Time(ts cache.Last Send RPC Request)。当最新已授时事务的授时请求发送时刻不早于待授时事务T0的开始提交时刻，即Absolute Time(ts cache.Last Send RPC Request)≥Absolute Time(T0.Start To Commit)时，将该最新已授时事务接收到的时间戳分配至待授时事务T0，即待授时事务T0与该最新已授时事务复用同一个时间戳，这两个事务的版本号一致。在这种情况下，节点N1不需要针对待授时事务T0向授时节点发送授时请求，一方面，降低了节点N1向授时节点发送授时请求的频率，同时，也相应减少了授时节点的负载压力。另一方面，由于最新已授时事务接收到的时间戳已经存储在缓存中，因此待授时事务T0可以直接复用缓存中的时间戳，大大减少了等待授时的时间，从而提高了待授时事务T0的处理效率。
在另一实施例中，当最新已授时事务的授时请求发送时刻不满足预设条件时，节点N1可以查询本节点上除最新已授时事务外的其他未授时事务向授时节点发送授时请求的授时请求发送时刻。同样的，将未授时事务的授时请求发送时刻记作Absolute Time(ts cache.Send RPC Request)。当查询到存在任一未授时事务的授时请求发送时刻不早于待授时事务T0的开始提交时刻时。即Absolute Time(ts cache.Send RPC Request)≥Absolute Time(T0.Start To Commit)时，表示该任一未授时事务对应的授时响应中的时间戳可以分配至待授时事务T0，使得待授时事务T0与该任一未授时事务复用同一个时间戳，这两个事务的版本号一致。比如，查询到存在未授时事务T4的授时请求发送时刻满足预设条件，此时，只需将待授时事务T0添加至节点N1缓存的待授时队列中，等待授时节点返回针对未授时事务T4的授时响应。当未授时事务T4接收到授时节点返回的授时响应时，将此授时响应中的时间戳分配至待授时事务T0，使得待授时事务T0和事务T4复用同一个时间戳。在这种情况下，节点N1同样不需要针对待授时事务T0向授时节点发送授时请求，降低了节点N1向授时节点发送授时请求的频率，同时，也在一定程度上减少了授时节点的负载压力。本实施例中，将待授时事务T0添加至待授 时队列以等待未授时事务T4的授时响应返回可以作为一个异步任务，从而避免影响其他事务的提交过程。
在一实施例中，在节点N1上所有除待授时事务T0以外的其他事务的授时请求发送时刻都不满足预设条件，即所有其他事务的授时请求发送时刻都早于待授时事务T0的开始提交时刻的情况下，节点N1需要针对待授时事务T0向授时节点发送授时请求。授时节点响应于接收到的授时请求分配时间戳，将此时间戳赋值在授时响应中，并且授时响应中包含了授时请求的相关信息，以使得节点N1在接收到授时响应时，可以明确该授时响应对应哪个授时请求。因为授时节点的时间戳不会回退，即授时节点按照递增的方式给各节点的事务分配时间戳，因此可以保证最新授时事务的时间戳一定是最大的，进而保证了数据库的外部一致性。
在一实施例中，分布式数据库中的各个节点还负责接收授时节点返回的任一授时响应，并将接收到的授时响应对应的授时请求发送时刻与时间戳缓存中最新已授时事务的授时请求发送时刻进行比较。如果授时响应对应的授时请求发送时刻晚于时间戳缓存中最新已授时事务的授时请求发送时刻，那么将缓存中最新已授时事务的授时请求发送时刻更新为授时响应对应的授时请求发送时刻。同时，将时间戳缓存中存储的时间戳更新为该授时响应反馈的时间戳。如果授时响应对应的授时请求发送时刻不晚于时间戳缓存中最新已授时事务的授时请求发送时刻，就丢掉该授时响应。这一更新操作可以保证缓存中最新已授时事务的授时请求发送时刻、即Absolute Time(ts cache.Last Send RPC Request)一直是已授时事务的授时请求发送时刻集合中的最大值，进而使得满足事物开始提交时刻不晚于最新已授时事务的授时请求发送时刻这一条件的任一待授时事务都可以使用最新已授时事务的时间戳。
在一实施例中，每次更新完时间戳缓存中存储的时间戳后，遍历该节点上待授时队列的所有待授时事务。因为更新后，缓存中最新已授时事务的授时请求发送时刻是当前缓存中已授时事务的授时请求发送时刻集合中的最大值，所以可以将更新后的时间戳分配至所有事物开始提交时刻不晚于当前最大授时请求发送时刻的待授时事务。
在一实施例中，可以在授时节点返回的授时响应中增加当前授时节点的状态，以使得各节点在接收到授时响应时，根据当前授时节点的状态调整本节点对授时节点发送授时请求的频率。比如，可以将授时节点的状态分为正常、空闲和繁忙三种类型。当任一节点获取到当前授时节点状态为空闲状态时，该任一节点可以针对当前所有待授时事务挨个向授时节点发送授时请求，从而提高对授时节点发送授时请求的频率，实现对授时 节点的充分利用，避免资源浪费，并且每个待授时事务都能获取到由授时节点分配的时间戳，充分保证了数据库的外部一致性。当任一节点获取到当前授时节点状态为繁忙状态时，可以先查询本节点上是否有符合前述实施例的其他事务，若有，则将其他事务的时间戳分配至待授时事务，从而降低向授时节点发送获取时间戳请求的频率，减小授时节点的负载压力。当任一节点获取到当前授时节点状态为正常状态时，表明当前本节点向授时节点发送授时请求的频率处于平衡状态，只要保持当前频率就不会对授时节点造成过大的负载压力，同时还能保证授时节点处理授时请求的效率，避免返回授时响应过久的问题。
与上述方法实施例相对应，本说明书还提供了一种装置的实施例。
图4是根据本说明书一示例性实施例示出的一种电子设备的结构示意图。参考图4，在硬件层面，该电子设备包括处理器402、内部总线404、网络接口406、内存408以及非易失性存储器410，当然还可能包括其他业务所需要的硬件。处理器402从非易失性存储器410中读取对应的计算机程序到内存408中然后运行。当然，除了软件实现方式之外，本说明书并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
图5是根据本说明书一示例性实施例示出的一种应用于分布式数据库的时间戳分配装置的框图。参照图5，该装置包括提交模块502、查询模块504、分配模块506，其中：
提交模块502，被配置为响应于接收的事务提交请求，提交相应的待授时事务并记录所述待授时事务的开始提交时刻。
查询模块504，被配置为查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻。
分配模块506，被配置为在任一其他事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述授时节点针对该任一其他事务反馈的时间戳分配至所述待授时事务。
可选的，所述查询模块504具体用于：查询所述任一节点针对最新已授时事务向所述授时节点发送授时请求的授时请求发送时刻；其中，在查询到的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述最新已授时事务确定为所述任一其他事务。
可选的，所述查询模块504还用于：在所述最新已授时事务的授时请求发送时刻早 于所述待授时事务的开始提交时刻的情况下，查询所述任一节点针对其他未授时事务向所述授时节点发送授时请求的授时请求发送时刻；其中，在任一其他未授时事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述任一其他未授时事务作为所述任一其他事务。
可选的，所述装置还包括：发送模块508，被配置为在所有其他事务的授时请求发送时刻均早于所述待授时事务开始提交时刻的情况下，针对所述待授时事务向所述授时节点发送授时请求，以由所述授时节点响应于该授时请求向所述待授时事务分配时间戳。
接收模块510，被配置为接收所述授时节点返回的任一授时响应。
更新模块512，被配置为在所述任一授时响应对应的授时请求发送时刻晚于所述缓存中最新已授时事务的授时请求发送时刻的情况下，将所述缓存中最新已授时事务的授时请求发送时刻更新为所述授时响应对应的授时请求发送时刻。
遍历模块514，被配置为遍历所述缓存中待授时队列的所有待授时事务，将所述缓存中最新已授时事务的时间戳分配至所有满足条件的待授时事务，所述条件包括：所述最新已授时事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻。
调整模块516，被配置为根据任一授时响应中包含的授时节点的当前运行状态调整所述任一节点对所述授时节点发送授时请求的频率，其中，所述授时节点的当前运行状态表明所述授时节点的繁忙程度。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (10)

  1. 一种应用于分布式数据库的时间戳分配方法，所述分布式数据库的节点包括授时节点和普通节点，所述方法应用于任一节点，该方法包括：
    响应于接收的事务提交请求，提交相应的待授时事务并记录所述待授时事务的开始提交时刻；
    查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻；
    在任一其他事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述授时节点针对该任一其他事务反馈的时间戳分配至所述待授时事务。
  2. 根据权利要求1所述的方法，所述查询所述任一节点针对其他事务向所述授时节点发送授时请求的的授时请求发送时刻，包括：
    查询所述任一节点针对最新已授时事务向所述授时节点发送授时请求的授时请求发送时刻；
    其中，在查询到的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述最新已授时事务确定为所述任一其他事务。
  3. 根据权利要求2所述的方法，所述查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻，包括：
    在所述最新已授时事务的授时请求发送时刻早于所述待授时事务的开始提交时刻的情况下，查询所述任一节点针对其他未授时事务向所述授时节点发送授时请求的授时请求发送时刻；
    其中，在任一其他未授时事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述任一其他未授时事务作为所述任一其他事务。
  4. 根据权利要求1所述的方法，还包括：
    在所有其他事务的授时请求发送时刻均早于所述待授时事务的开始提交时刻的情况下，针对所述待授时事务向所述授时节点发送授时请求，以由所述授时节点响应于该授时请求向所述待授时事务分配时间戳。
  5. 根据权利要求1所述的方法，还包括：
    接收所述授时节点返回的任一授时响应；
    在所述任一授时响应对应的授时请求发送时刻晚于缓存中最新已授时事务的授时请求发送时刻的情况下，将所述缓存中最新已授时事务的授时请求发送时刻更新为所述任一授时响应对应的授时请求发送时刻。
  6. 根据权利要求1所述的方法，还包括：
    接收所述授时节点返回的任一授时响应，所述任一授时响应包含授时节点的当前运行状态，所述授时节点的当前运行状态表明所述授时节点的繁忙程度；
    根据所述授时节点的当前运行状态调整所述任一节点对所述授时节点发送授时请求的频率。
  7. 根据权利要求1所述的方法，还包括：
    遍历缓存中待授时队列的所有待授时事务，将所述缓存中最新已授时事务的时间戳分配至所有满足条件的待授时事务，所述条件包括：所述最新已授时事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻。
  8. 一种应用于分布式数据库的时间戳分配装置，所述分布式数据库的节点包括授时节点和普通节点，所述装置应用于任一节点，该装置包括：
    提交模块，用于响应于接收的事务提交请求，提交相应的待授时事务并记录所述待授时事务的开始提交时刻；
    查询模块，用于查询所述任一节点针对其他事务向所述授时节点发送授时请求的授时请求发送时刻；
    分配模块，用于在任一其他事务的授时请求发送时刻不早于所述待授时事务的开始提交时刻的情况下，将所述授时节点针对该任一其他事务反馈的时间戳分配至所述待授时事务。
  9. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-7中任一项所述的方法。
  10. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-7中任一项所述方法。
PCT/CN2023/118659 2022-11-01 2023-09-13 一种应用于分布式数据库的时间戳分配方法及装置 WO2024093543A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211358893.8A CN115774725A (zh) 2022-11-01 2022-11-01 一种应用于分布式数据库的时间戳分配方法及装置
CN202211358893.8 2022-11-01

Publications (1)

Publication Number Publication Date
WO2024093543A1 true WO2024093543A1 (zh) 2024-05-10

Family

ID=85388675

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/118659 WO2024093543A1 (zh) 2022-11-01 2023-09-13 一种应用于分布式数据库的时间戳分配方法及装置

Country Status (2)

Country Link
CN (1) CN115774725A (zh)
WO (1) WO2024093543A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115774725A (zh) * 2022-11-01 2023-03-10 北京奥星贝斯科技有限公司 一种应用于分布式数据库的时间戳分配方法及装置
CN118157808B (zh) * 2024-05-11 2024-07-09 平凯星辰(北京)科技有限公司 多租户环境下的授时方法、装置和授时服务系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190294711A1 (en) * 2018-03-22 2019-09-26 Microsoft Technology Licensing, Llc Performing transactions in distributed transactional memory systems
CN113312370A (zh) * 2021-07-30 2021-08-27 北京金山云网络技术有限公司 信息获取方法、装置、电子设备及存储介质
CN115774725A (zh) * 2022-11-01 2023-03-10 北京奥星贝斯科技有限公司 一种应用于分布式数据库的时间戳分配方法及装置
CN116488764A (zh) * 2023-04-20 2023-07-25 贵州易鲸捷信息技术有限公司 基于区域间混合逻辑时钟的分布式事务授时方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190294711A1 (en) * 2018-03-22 2019-09-26 Microsoft Technology Licensing, Llc Performing transactions in distributed transactional memory systems
CN113312370A (zh) * 2021-07-30 2021-08-27 北京金山云网络技术有限公司 信息获取方法、装置、电子设备及存储介质
CN115774725A (zh) * 2022-11-01 2023-03-10 北京奥星贝斯科技有限公司 一种应用于分布式数据库的时间戳分配方法及装置
CN116488764A (zh) * 2023-04-20 2023-07-25 贵州易鲸捷信息技术有限公司 基于区域间混合逻辑时钟的分布式事务授时方法

Also Published As

Publication number Publication date
CN115774725A (zh) 2023-03-10

Similar Documents

Publication Publication Date Title
WO2024093543A1 (zh) 一种应用于分布式数据库的时间戳分配方法及装置
EP3718024B1 (en) High-throughput distributed transaction management for globally consistent sharded oltp system and method of implementing
US11099937B2 (en) Implementing clone snapshots in a distributed storage system
US20190340171A1 (en) Data Redistribution Method and Apparatus, and Database Cluster
US11822540B2 (en) Data read method and apparatus, computer device, and storage medium
US12026100B2 (en) Method and system for low latency data management
US20230099664A1 (en) Transaction processing method, system, apparatus, device, storage medium, and program product
US11966599B2 (en) Method and system for low latency data management
WO2021147935A1 (zh) 一种日志回放方法及装置
CN109446222A (zh) 一种双缓存的数据存储方法、装置及存储介质
US7467166B2 (en) System and method for heterogeneous caching
US20230418811A1 (en) Transaction processing method and apparatus, computing device, and storage medium
WO2023197404A1 (zh) 一种基于分布式数据库的对象存储方法及装置
WO2023124422A1 (zh) 一种数据读写的控制方法及电子设备
CN114168262B (zh) 一种基于lru置换算法的云平台镜像缓存管理方法
CN108460047B (zh) 数据同步方法及设备
CN116303661B (zh) 一种分布式数据库中针对序列的处理方法、装置及系统
CN115640353A (zh) 数据读取方法、计算机存储介质和电子设备
US20220171756A1 (en) Method and apparatus for distributed database transactions using global timestamping
Shrivastava et al. Replication protocol based on dynamic versioning of data object for replicated DRTDBS
US11514015B2 (en) Reducing requests using probabilistic data structures
US11954039B2 (en) Caching system and method
WO2022001629A1 (zh) 一种数据库系统、管理事务的方法及装置
CN117370129A (zh) 线程状态记录方法及计算设备
CN114064595A (zh) 写事务日志的方法、装置、处理器和服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23884475

Country of ref document: EP

Kind code of ref document: A1