WO2018223262A1 - 一种事务处理方法、装置及设备 - Google Patents

一种事务处理方法、装置及设备 Download PDF

Info

Publication number
WO2018223262A1
WO2018223262A1 PCT/CN2017/087194 CN2017087194W WO2018223262A1 WO 2018223262 A1 WO2018223262 A1 WO 2018223262A1 CN 2017087194 W CN2017087194 W CN 2017087194W WO 2018223262 A1 WO2018223262 A1 WO 2018223262A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
transaction
partition
snapshot
partitions
Prior art date
Application number
PCT/CN2017/087194
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 华为技术有限公司
Priority to CN201780002963.7A priority Critical patent/CN110168514B/zh
Priority to JP2020517246A priority patent/JP6924898B2/ja
Priority to EP17912603.2A priority patent/EP3627359B1/en
Priority to PCT/CN2017/087194 priority patent/WO2018223262A1/zh
Priority to KR1020197036437A priority patent/KR102353141B1/ko
Publication of WO2018223262A1 publication Critical patent/WO2018223262A1/zh
Priority to US16/703,362 priority patent/US20200110739A1/en

Links

Images

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/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1865—Transactional file systems
    • 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
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1466—Management of the backup or restore process to make the backup process non-disruptive
    • 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
    • G06F16/2379—Updates performed during online database operations; commit processing
    • 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning

Definitions

  • the present application relates to the field of database technologies, and in particular, to a transaction processing method, apparatus, and device.
  • the traditional database-based transaction-based solution can only guarantee the consistency of one-time processing of a single service, but it cannot guarantee the consistency of processing among multiple distributed services. Therefore, it is necessary to establish a coordination mechanism between distributed service processing to Implement Multi-Version Concurrency Control (MVCC).
  • MVCC Multi-Version Concurrency Control
  • the server distinguishes between a single partition transaction (a transaction operation involves only one data partition) and a multi-partition transaction (a transaction operation involves multiple data partitions), and a transaction queue is set separately for each data partition.
  • the server adds a single-partition transaction to the transaction queue of the corresponding data partition and adds the multi-partition transaction to the transaction queue of the corresponding multiple data partitions.
  • the server processes the transactions in each transaction queue one by one.
  • the server performs collaborative processing for the same multi-partition write transaction in multiple data partitions.
  • FIG. 1 illustrates a transaction processing diagram involved in the related art.
  • data partition 1 corresponds to transaction queue 1
  • data partition 2 corresponds to transaction queue 2, wherein transaction queue 1 contains two transactions, namely single partition transaction 1 and multi-partition transaction 2
  • transaction queue 2 includes Two transactions, multi-partition transaction 2 and single-partition transaction 3, respectively.
  • the server first extracts the multi-partition transaction 1 in the single partition transaction 1 and the queue 2 in the queue 1 according to the transaction queue. At this time, the server performs the single partition transaction 1 for the data partition 1 and targets the data.
  • Partition 2 executes multi-partition transaction 2, after the single-partition transaction 1 is processed, the server extracts the multi-partition transaction 2 in transaction queue 1.
  • the server since the multi-partition transaction 2 for data partition 1 has not been executed yet, even then The multi-partition transaction 2 for data partition 2 has been executed, and the server does not immediately execute the single-partition transaction 3 in queue 2, but waits for the execution of the multi-partition transaction 2 for data partition 2, and then executes the single-partition transaction 3 .
  • Multi-partition transactions are generally long transactions, usually take a long time to process, while single-partition transactions are usually short transactions, and the processing time is relatively short.
  • the processing progress of the same multi-partition transaction in different transaction queues At the same time, the processing of multi-partition transactions will block the single-partition transaction, resulting in low throughput and service level of the system, affecting the user experience.
  • an embodiment of the present application provides a transaction processing method, apparatus, and device.
  • a transaction processing method comprising:
  • Receiving a transaction to be processed is a transaction operating in at least two data partitions; acquiring a data snapshot corresponding to the at least two data partitions and satisfying consistency; according to the at least two data partitions Corresponding, and the data snapshot satisfying the consistency performs the operation corresponding to the to-be-processed transaction.
  • a data snapshot satisfying consistency is obtained by using each data partition involved in the multi-partition transaction, and multi-partition transaction correspondence is performed based on the data snapshot.
  • the operation supports the parallel execution between the read transaction and the write transaction, avoiding the mutual blocking between the write transaction and the read transaction, thereby achieving the effect of improving the throughput and service level of the system.
  • the pending transaction is a transaction that performs a read operation in the at least two data partitions.
  • the obtaining a data snapshot corresponding to the at least two data partitions and satisfying consistency includes: acquiring a data snapshot of each of the at least two data partitions, and the at least two And verifying, by the version information of the respective data snapshots of the at least two data partitions, whether the data snapshots of the at least two data partitions meet the consistency; if the detection result is the at least The data snapshots of the two data partitions satisfy the consistency, and it is determined that the data snapshots corresponding to the at least two data partitions respectively and satisfying the consistency are successfully obtained.
  • the version information of the data snapshot is also obtained, and the data snapshot corresponding to the multiple data partitions is checked based on the version information of the obtained data snapshot. Whether consistency is met between them, and avoiding snapshots that do not meet the consistency.
  • the obtaining the data snapshot corresponding to the at least two data partitions and satisfying the consistency further includes: if the detection result is that the data snapshots of the at least two data partitions are not consistent And re-acquiring the data snapshot of the data partition with the low version and the version information of the re-acquired data snapshot; detecting whether the data snapshots of the at least two data partitions are consistent according to the version information of the re-acquired data snapshot Sex.
  • the method further includes: if the detection result is that the data snapshots of the at least two data partitions are inconsistent, deleting the data snapshot of the acquired data partition with a lower version.
  • the version information of the data snapshot includes the identifier of the most recently written multi-partition write transaction in the data partition corresponding to the data snapshot when the data snapshot is generated, and the multi-partition write transaction Is a transaction that writes in at least two data partitions.
  • the identifier of the most-written multi-partition write transaction is used as the version information of the data partition, and the data in which the write inconsistency is read during the multi-partition read operation is avoided, and the accuracy of data reading is ensured.
  • the to-be-processed transaction is a transaction that performs a write operation in the at least two data partitions, and the data snapshot execution corresponding to the at least two data partitions and satisfying consistency is performed.
  • the operations corresponding to the to-be-processed transaction include:
  • the to-be-processed transaction is a transaction that performs a write operation in the at least two data partitions, and the method further includes:
  • the identifier of the to-be-processed transaction is updated to version information corresponding to each of the at least two data partitions.
  • a transaction processing apparatus having the functionality of a transaction processing method provided by implementing the first aspect and the possible design of the first aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more than one unit corresponding to the functions described above.
  • a transaction processing apparatus comprising: a processor, a memory, and a communication interface, the communication interface configured to be controlled by the processor; the processor in the device controls the communication interface by executing the memory
  • the program or instructions stored therein implement the transaction processing methods provided by the first aspect and the possible design of the first aspect.
  • a computer readable storage medium storing an executable program executed by a processor to implement the first aspect and the possible design of the first aspect is provided The transaction processing method provided.
  • a transaction processing system comprising a transaction processing device and at least two data partitions; the transaction processing device is configured to implement the transaction processing method provided by the first aspect and the possible design of the first aspect .
  • FIG. 1 is a schematic diagram of a transaction process related to the related art
  • FIG. 2A is a block diagram of a transaction processing system involved in various embodiments of the present application.
  • 2B is a schematic diagram of a multi-partition transaction processing process involved in various embodiments of the present application.
  • FIG. 3 is a flowchart of a method of a transaction processing method provided by an exemplary embodiment of the present application
  • FIG. 4 is a schematic diagram of a correspondence between a second write transaction queue and a data partition according to the embodiment shown in FIG. 3;
  • FIG. 5 is a schematic diagram of a correspondence between a second read transaction queue and a data partition according to the embodiment shown in FIG. 3;
  • FIG. 6 is a schematic diagram of correspondence between a first transaction queue and a special partition involved in the embodiment shown in FIG. 3;
  • FIG. 7 is a schematic diagram of a composition of a participating node according to an exemplary embodiment of the present application.
  • FIG. 8 is a schematic diagram of a transaction processing device provided by an exemplary embodiment of the present application.
  • FIG. 9 is a schematic diagram of a transaction processing device provided by an exemplary embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of a transaction processing apparatus according to an exemplary embodiment of the present disclosure.
  • FIG. 11 is a block diagram showing the structure of a transaction processing apparatus according to an exemplary embodiment of the present application.
  • FIG. 12 is a system configuration diagram of a transaction processing system according to an exemplary embodiment of the present application.
  • FIG. 2A is a block diagram of a transaction processing system involved in the present application.
  • the system includes the following devices: a transaction device 210 and at least one terminal device 220.
  • the transaction processing device 210 can be a general-purpose computer or a workstation, or the transaction processing device 210 can also be a single server, a server cluster, or a cloud computing center.
  • the data corresponding to the transaction processing device 210 may be divided into one or more data partitions.
  • the partition refers to a continuous range of values.
  • the data partition may be a continuous interval obtained by hashing the field (primary key field or non-primary key field) of the data according to a certain hash algorithm.
  • the transaction device 210 and the at least one terminal device 220 are connected by a wired or wireless network.
  • the transaction processing device 210 is configured to process the transaction sent by the at least one terminal device 220, wherein the transaction sent by the at least one terminal device 220 can also be divided into a single partition transaction and a multi-partition transaction. From another perspective, transactions sent by at least one terminal device 220 can also be divided into read transactions and write transactions.
  • FIG. 2B is a schematic diagram of a multi-partition transaction process involved in various embodiments of the present application.
  • the processing steps for the multi-partition transaction are as follows:
  • Step 21 Receive a pending transaction, where the pending transaction is a transaction operating in at least two data partitions.
  • Step 22 Obtain a data snapshot corresponding to the at least two data partitions and satisfy the consistency.
  • Step 23 Perform an operation corresponding to the to-be-processed transaction according to the data snapshot corresponding to the at least two data partitions and satisfying the consistency.
  • the transaction processing device does not directly operate in the data partition when performing a read operation or a write operation, but operates in a data snapshot corresponding to the data partition.
  • the same time can be Providing a data snapshot to a write transaction and at least one read transaction, that is, it can simultaneously support the processing of one write transaction and at least one read transaction, that is, the write transaction and the read transaction of the data partition do not block each other, thereby Improve system throughput and service levels.
  • FIG. 3 is a flowchart of a method of a transaction processing method provided by an exemplary embodiment of the present application.
  • the method can be used in the transaction device 210 of the system shown in FIG.
  • the transaction processing method may include the following steps:
  • Step 301 Receive a pending transaction sent by the terminal device. If the pending transaction is a multi-partition transaction, proceed to step 302. If the pending transaction is a single-partition transaction, proceed to step 303.
  • a single partition transaction is a transaction operating in a single data partition
  • a multi-partition transaction is a transaction operating in at least two data partitions.
  • a single-partition read transaction is a transaction that performs a read operation in a single data partition involved
  • a single-partition write transaction is a transaction that performs a write operation in a single data partition involved; accordingly, a multi-partition read transaction is involved
  • a transaction in which at least two data partitions are read, and a multi-partition write transaction is a transaction that performs a write operation in at least two data partitions involved.
  • the terminal device may send a transaction request to the transaction processing device, where the transaction request includes a transaction to be processed.
  • the foregoing transaction request may include partition indication information, where the partition indication information may indicate the to-be-in- Whether the transaction is a single partition transaction or a multi-partition transaction.
  • the foregoing transaction request may not include partition indication information, and the partition indication information may be obtained by the transaction processing device parsing key information in the transaction request.
  • Step 302 Add the multi-partition transaction to the first read transaction queue or the first write transaction queue according to the transaction type of the multi-partition transaction.
  • the transaction request may further include a transaction type of the transaction, or the transaction processing device may perform analysis according to the transaction to be processed to determine a corresponding transaction type.
  • the transaction queue in the embodiment of the present application can be divided into two levels of queues.
  • the transaction processing device When receiving the multi-partition transaction, the transaction processing device first adds the multi-partition transaction to the first-level queue, and then in the parallel processing process, the first Multi-partition transactions in the level queue are added to the second level queue.
  • the first level queue is the first read transaction queue and the first write transaction queue; the second level queue is a second read transaction queue and a second write transaction queue corresponding to each data partition.
  • the first level queue includes a first read transaction queue and/or a first write transaction queue.
  • Step 303 Add the single-partition transaction to the second read transaction queue or the second write transaction queue of the corresponding data partition according to the transaction type of the single-partition transaction.
  • each data partition corresponds to only one second write transaction queue, and each second write transaction queue may correspond to one or more data partitions.
  • the transaction processing device receives a single partition transaction, if the single partition transaction is a write transaction, the single partition transaction is added to the second write transaction queue corresponding to the single partition transaction.
  • FIG. 4 illustrates a corresponding relationship between a second write transaction queue and a data partition according to an embodiment of the present application; as shown in FIG. 4(a), the data partition 1 and the data partition 2 may correspond to each other.
  • the same second write transaction queue (write transaction queue 1), that is, a single partition write transaction for data partition 1 and a single partition write transaction for data partition 2 are added to write transaction queue 1; or, as shown in Figure 4(b)
  • the two data partitions can respectively correspond to a second write transaction queue (ie, data partition 1 corresponds to write transaction queue 1 and data partition 2 corresponds to write transaction queue 2), that is, a single partition write transaction for data partition 1 is added to write.
  • Transaction queue 1 a single partition write transaction to data partition 2 is added to write transaction queue 2.
  • the correspondence between the data partition and the second read transaction queue may be a one-to-one, one-to-many or many-to-many relationship.
  • the transaction processing device receives the single-partition transaction, if the single-partition transaction is a read transaction, the single-partition transaction is added to the second read transaction queue corresponding to the single-partition transaction, wherein when the single-partition transaction corresponds to multiple
  • the second read transaction queue only the single partition transaction is added to one of the corresponding multiple read transaction queues.
  • FIG. 5 illustrates a corresponding relationship between a second read transaction queue and a data partition according to an embodiment of the present application
  • the data partition 1 and the data partition 2 may correspond to each other.
  • the same second read transaction queue (read transaction queue 1), that is, a single partition read transaction for data partition 1 and a single partition read transaction for data partition 2 are added to read transaction queue 1; or, as shown in Figure 5(b)
  • the two data partitions can respectively correspond to a second read transaction queue (ie, data partition 1 corresponds to read transaction queue 1 and data partition 2 corresponds to read transaction queue 2), that is, a single partition read transaction for data partition 1 is added to read.
  • Transaction queue 1 add a single partition read transaction to data partition 2 to read transaction queue 2; or, as shown in Figure 5 (c), data partition 1 can simultaneously correspond to read transaction queue 1 and read transaction queue 2, that is, data A single partition read transaction of partition 1 can be added to read transaction queue 1 or read transaction queue 2; or, as shown in FIG. 5(d), data partition 1 can simultaneously correspond to read transaction queue 1 and read transaction queue 2, and at the same time, data Partition 2 also corresponds to Read transaction queue 1 and read transaction queue 2, that is, a single partition read transaction for data partition 1 can be added to read transaction queue 1 or read transaction queue 2, and a single partition read transaction for data partition 2 can also be added to the read transaction. Queue 1 or read transaction queue 2.
  • the first transaction queue may be assigned a special partition with a special flag, the special partition is not used to store data, and the special flag of the special partition is used to distinguish the data partition. Or other special partitions.
  • FIG. 6 is a schematic diagram of the correspondence between the first transaction queue and the special partition involved in the embodiment of the present application; as shown in FIG. 6( a ), the special partition is divided into a write special partition and a read special partition, and a special partition is written.
  • the number of the first write transaction queues is one, and one-to-one correspondence. All multi-partition write transactions are entered into the first write transaction queue corresponding to the special partition; as shown in FIG.
  • the first read transaction queue has one or more (two are shown in the figure), and each of the first The read-ahead transaction queues all correspond to one read special partition (the figure shows that the first read transaction queue 1 corresponds to the read special partition 1, and the first read transaction queue 2 corresponds to the read special partition 2).
  • the multi-partition transaction can enter the first read transaction queue 1 or enter the first read transaction queue 2.
  • first write transaction queue corresponding to the write special partition may also be added to the second write transaction queue as a special write queue.
  • the first read transaction queue corresponding to the read special partition may also be added to the second read transaction queue as a special read queue.
  • step 304 the read transaction queue and the write transaction queue are processed in parallel.
  • the transaction processing device when the transaction processing device performs parallel processing on each read transaction queue and write transaction queue involved in the foregoing steps 302 and 303, the transaction processing device serializes each write transaction in the same write transaction queue. Processing, that is, for multiple write transactions in a write transaction queue, the transaction processing device processes the next write transaction in the write transaction queue after the previous write transaction is completed.
  • the transaction processing device can serially process each read transaction in the same read transaction queue; or, the transaction processing device can also process each read transaction in the same read transaction queue in parallel, for example, for a read transaction queue, transaction processing A device can simultaneously process multiple read transactions in the read transaction queue through multiple threads.
  • the transaction processing device can process each transaction by using a data snapshot.
  • the processing of the multi-partition read transaction and the multi-partition write transaction is involved, and the multi-partition transaction is processed.
  • the data consistency principle needs to be considered. Therefore, in the embodiment of the present application, when processing each transaction through a data snapshot, it is necessary to ensure that the acquired data snapshot satisfies the consistency.
  • the specific processing can be as follows:
  • the transaction processing device can obtain a data snapshot of the data partition corresponding to the single-partition read transaction or the single-partition write transaction, and after successfully obtaining the data snapshot, according to the data snapshot Reading or writing of a transaction.
  • the transaction processing device acquires the processing location in the second write transaction queue (for example, the processing location may be the queue head position of the queue).
  • a single partition write transaction obtain a data snapshot of the data partition corresponding to the single partition write transaction, and write the write data corresponding to the single partition write transaction in the obtained data snapshot, and the data after the data is written
  • the snapshot is stored as data in the corresponding data partition.
  • the step of writing the data to the data snapshot and storing the data snapshot as the data in the data partition may be referred to as a commit of the write transaction.
  • the transaction processing device acquires a single-partition read transaction in the second read transaction queue that arrives at the processing location, and obtains the single-region read transaction corresponding to the single-region read transaction.
  • the data snapshot of the data partition reads the data corresponding to the single partition read transaction from the obtained data snapshot, and sends the read data to the corresponding terminal device, and deletes the data snapshot.
  • the acquisition can be considered as The data snapshot corresponding to the pending transaction must be consistent.
  • the transaction processing device can determine each data partition corresponding to the multi-partition transaction, obtain a corresponding data snapshot corresponding to each data partition, and satisfy the consistency data snapshot, and each data partition The data snapshots are respectively read by the multi-partition transaction.
  • the data snapshot corresponding to each data partition satisfies the consistency, which means that for any two data partitions in each data partition, when acquiring the data snapshot of the two data partitions, the latest one is involved at the same time.
  • the multi-partition write transaction for these two data partitions has been written in both data partitions.
  • the transaction processing device may acquire a multi-partition transaction reaching the processing location in the first read transaction queue, and add the acquired multi-partition transaction to the multi-partition.
  • the transaction processing device acquires a data snapshot of each data partition corresponding to the multi-partition transaction.
  • the transaction data may also directly acquire the data snapshot of each data partition corresponding to the multi-partition transaction.
  • the multi-partition read transaction involves reading operations on data in a plurality of data partitions
  • the read transaction and the write transaction in the embodiment of the present application are processed in parallel, and the multi-partition write transaction is in different data partitions.
  • the time of the commit is not absolutely the same. Therefore, the external visibility of the multi-partition write transaction may also exist in sequence.
  • the snapshot of the data obtained by the different data partitions corresponding to the same multi-partition read transaction is not Consistency is met, and the data read directly from the acquired data snapshot may be inconsistent.
  • the data snapshot of the at least two data partitions may be acquired. And verifying the version information of the respective data snapshots of the at least two data partitions, and detecting whether the data snapshots of the respective data partitions meet the consistency according to the version information of the data in the respective data snapshots of the respective data partitions, if each If the data snapshots of the data partitions satisfy the consistency, perform the steps of performing the read operations corresponding to the data snapshots of the respective data partitions respectively; if the data snapshots of the respective data partitions do not satisfy the consistency,
  • the version information of the data corresponds to a data partition with a low version (that is, not the highest version), and the transaction processing device deletes the data snapshot with the low version of the acquired data, and reacquires the data snapshot of the partition, and according to the reacquired data snapshot.
  • the version information of the data in the data snapshot includes an identifier of a most-partitioned multi-partition transaction (ie, a multi-partition write transaction) in the data partition corresponding to the data snapshot when the data snapshot is generated.
  • a most-partitioned multi-partition transaction ie, a multi-partition write transaction
  • the transaction processing device may allocate a corresponding identifier for the multi-partition transaction after receiving a multi-partition transaction.
  • the identifier of the multi-partition transaction may be an ID or a unique number of the multi-partition transaction.
  • different multi-partition transaction identifiers can be used to distinguish between different multi-partition transactions being processed.
  • the ID of the multi-partition transaction is an example.
  • the transaction processing device allocates the ID of the multi-partition transaction whose transaction type is a write transaction, the ID assigned to each multi-partition transaction is incremented from 1, and the ID is smaller.
  • the multi-partition transaction the higher the order of processing, the lower the version of the corresponding data, and the larger the multi-partition transaction with the larger ID, the lower the order of processing, the higher the version of the corresponding data.
  • the transaction processing device may determine at least two data partitions corresponding to the multi-partition write transaction, and acquire respective data snapshots of the at least two data partitions. Performing a write operation corresponding to the multi-partition write transaction for each of the data snapshots of the at least two data partitions, and performing at least two data partitions after the write operations respectively performed on the respective data snapshots of the at least two data partitions are completed The respective data snapshots are saved as respective data for the at least two data partitions.
  • the transaction processing device since the transaction processing device serially processes each write transaction in the same write transaction queue, that is, for a plurality of write transactions in a write transaction queue, the transaction processing device writes the transaction to the previous one. After completion, the next write transaction in the write transaction queue is processed, that is, when the transaction processing device is processing a multi-partition write transaction, at least two data partitions corresponding to the multi-partition write transaction are respectively corresponding to each other. A write transaction has been processed. Therefore, the data snapshot corresponding to the at least two data partitions acquired at this time must be singular, that is, the transaction processing device does not need to pass data when processing the multi-partition write transaction.
  • the version information corresponding to the snapshot is used to detect whether the acquired data snapshot satisfies the unity.
  • the transaction processing device after performing a write operation corresponding to the multi-partition write transaction (ie, the transaction to be processed) according to the data snapshot corresponding to the at least two data partitions and satisfying the consistency, the transaction processing device further updates the identifier of the transaction to be processed.
  • the transaction processing device may acquire a multi-partition write transaction in the first write transaction queue that arrives at the processing location, and add the obtained multi-partition write transaction to In the second write transaction queue corresponding to each of the data partitions involved in the multi-partition write transaction, when the multi-partition write transaction reaches the processing location in the second write transaction queue corresponding to each of the data partitions, the transaction processing device acquires each A separate data snapshot of the data partition.
  • Each data partition may correspond to a single-partition write transaction and a multi-partition write transaction to be processed at the same time.
  • the write transaction corresponding to the same data partition is processed when the write transaction is processed.
  • the transaction processing device processes the multi-partition write transaction,
  • the multi-partition write transaction is respectively added to the second write transaction queue corresponding to each of the involved data partitions, and serially sorted together with the respective single-partition write transactions of the respective data partitions, and the second write transaction queue corresponding to each data partition
  • the transaction processing device acquires a snapshot of the data corresponding to each data partition and performs a write operation.
  • the transaction processing device may perform the write to the multi-partition write transaction without waiting for other second write transaction queues including the multi-partition write transaction.
  • all the written data snapshots corresponding to the multi-partition write transaction are stored as data in the corresponding data partitions.
  • the transaction processing device may acquire a multi-partition transaction that arrives at the processing location in the first write transaction queue, and add the obtained multi-partition transaction to the write special Partition In the corresponding second write transaction queue, when the transaction of the second write transaction queue corresponding to the write special partition is scheduled (ie, processed), the transaction processing device acquires a respective data snapshot of each data partition. Wherein, when the write special partition corresponds to the transaction of the second write transaction queue, the single partition write transaction of other data partitions is blocked.
  • the second write transaction queue corresponding to two data partitions may be the same queue, and the transaction processing device adds the multiple partition only once in the second write transaction queue corresponding to the two data partitions. Write a transaction.
  • the transaction processing device acquires a data snapshot that satisfies the consistency for each data partition involved in the multi-partition transaction, and performs a read operation or write corresponding to the multi-partition transaction based on the data snapshot.
  • the operation supports the parallel execution between the read transaction and the write transaction, and avoids the situation that the write transaction and the read transaction corresponding to the same data partition block each other, thereby achieving the effect of improving the throughput and service level of the system.
  • each step in the foregoing embodiment corresponding to FIG. 3 may be implemented by different functional components in the transaction processing device.
  • These functional components may be logical functional components implemented by software or a combination of software and hardware.
  • each of the above functional components may be a separate functional node (such as a separate virtual machine or process), and each functional node interacts to implement transaction processing.
  • the function nodes in the foregoing transaction processing device may be divided into two types, which may be referred to as a coordination node and a participation node, respectively.
  • the number of the coordination nodes may be one, and the role is to coordinate the processing of the multi-partition transaction; optionally, the number of coordination nodes may be multiple, and one of the coordination nodes is used to process the multi-partition write and/or read transaction.
  • Other coordination nodes are responsible for handling multi-partition read transactions, that is, there is only one coordination node for multi-partition writes, and there may be multiple coordination nodes for multi-partition read.
  • each participating node corresponds to a respective data partition, and its role is to be responsible for processing a single partition transaction involving the corresponding data partition by itself, or processing multiple partitions involving corresponding data partitions under coordination of the coordination node.
  • Transaction optional each participating node has a corresponding special data partition, a write special partition and a read special partition, a write special partition and a read special partition for processing the multi-partition write transaction and the multi-partition read issued by the coordination node.
  • the coordination node is responsible for managing the first read transaction queue and the first write transaction queue in the embodiment shown in FIG. 3, and each participating node is responsible for the second read transaction queue and the second corresponding to the respective one or more data partitions. Write a transaction queue.
  • the second read transaction queue and the second write transaction queue that each participating node is responsible for further includes a read queue and a write queue corresponding to the read special partition and the write special partition.
  • FIG. 7 is a schematic diagram of a component node configuration provided by an exemplary embodiment of the present application.
  • the participating node 70 includes a sorting module 701, a scheduling module 702, and a storage engine 703.
  • the sorting module 701 is configured to implement the step of adding a single partition transaction to the corresponding second read transaction queue/second write transaction queue.
  • the sorting module 701 can also be configured to implement adding a multi-partition transaction distributed by the coordinating node from the first queue (including the first write transaction queue and/or the first read transaction queue) to the corresponding second queue (including the second write) The steps of sorting the transaction queue and/or the second read transaction queue.
  • the scheduling module 702 is configured to implement a step of scheduling processing on a transaction in the second read transaction queue/second write transaction queue.
  • the foregoing storage engine 703 is configured to implement a function of acquiring, storing, and deleting data snapshots of corresponding data partitions, and maintaining version information of data in the acquired data snapshots.
  • each participating node 70 there is one and only one storage engine 703, and the participating node 70 will correspond.
  • One to more data partitions are read and written as a whole, that is, when processing a transaction, regardless of whether the transaction involves all data partitions in the data partition corresponding to the participating node, the storage engine 703 acquires all corresponding data partitions. A snapshot of the data, and the data in all of the data partitions share a version information.
  • each storage engine 703 is responsible for storing data of one or more of the data partitions. Snapshot and version information.
  • the participating node 70 processes a transaction, it can acquire only the data snapshot of the partial data partition involved in the transaction in the data partition on the node.
  • multiple data partitions correspond to the same second write transaction queue, that is, a single partition write transaction and a multi-partition write transaction involving the multiple data partitions are added to the same second write transaction. queue.
  • the coordination node is a function node independent of each of the participating nodes, and the coordination node is responsible for managing the first read transaction queue and the first write transaction queue, and coordinating each participating node to process the first read transaction queue and the first Write a multi-partition transaction in the transaction queue.
  • the coordination node is also a participating node, which manages the first read transaction queue and the first write transaction queue, and coordinates each participating node to process the multi-partition transaction in the first read transaction queue and the first write transaction queue.
  • it is also responsible for managing the corresponding second read transaction queue and second write transaction queue, and processing transactions in the corresponding second read transaction queue and second write transaction queue.
  • the coordination node is also a participating node
  • the first write transaction queue of the coordination node is a write transaction queue corresponding to the write special partition in the second write transaction queue
  • the first read transaction queue of the coordination node is the second read transaction queue.
  • Read the read transaction queue corresponding to the special partition For multi-partition transactions, it can be added to the first transaction queue first.
  • the multi-partition transaction is scheduled, it is distributed to the second transaction queue corresponding to the data partition, or alternatively, for multi-partition transactions, it can be added to the first
  • the transaction queue when the multi-part transaction is scheduled, is redistributed to the second transaction queue corresponding to the special partition. For the node, it is considered that the execution location has been reached, and it is not necessary to add to the second transaction queue of the special partition of the node. request.
  • the coordination node is also a participating node
  • the first write transaction queue of the coordination node is equivalent to the second write transaction queue on the node
  • the first read transaction queue of the coordination node is equivalent to the second read transaction on the node. queue.
  • redistribute The request is sent to the second write transaction queue. If the node believes that the execution location has been reached, it is not necessary to add a request to all second write transaction queues of the node.
  • a multi-partition read transaction directly into a first read transaction queue, that is, a second read transaction queue, when the transaction is scheduled, the redistribution request is sent to the second read transaction queue, which is considered by the node to be When the execution location is reached, there is no need to add a request to the second read transaction queue of the node.
  • FIG. 8 is a schematic diagram of a transaction processing device implementation provided by an exemplary embodiment of the present application.
  • transaction processing device 80 may include at least one participating node (shown as participating node 811 and participating node 812 in FIG. 8) and a coordinating node 820.
  • There are one or more data partitions on each participating node (the data partition 1 and the data partition 2 are shown on the participating node 811 in FIG. 8 and the data partition 3 is on the participating node 812).
  • the coordination node may be one of the participating nodes, or the coordination node may be an independent node. Taking each of the participating nodes as a write transaction queue and a read transaction queue as an example, in FIG.
  • the coordination node 820 manages the first write transaction queue 851 and the first read transaction queue 852, and the participating node 811 manages the second write transaction queue. 831 and second read transaction queue 832, participating node 812 manages second write transaction queue 841 and second read transaction queue 842.
  • FIG. 9 is a schematic diagram of a transaction processing device implementation provided by an exemplary embodiment of the present application.
  • transaction processing device 80 may include at least one participating node (shown as participating node 811 and participating node 812 in FIG. 9) and at least two coordination nodes 820 (shown as three coordination nodes 820 in FIG. 9, Respective node 820-1, coordination node 820-2, and coordination node 820-3).
  • There are one or more data partitions on each participating node (the data partition 1 and the data partition 2 are shown on the participating node 811 in FIG. 9 and the data partition 3 is on the participating node 812).
  • the coordination node may be one of the participating nodes, or the coordination node may be an independent node.
  • each of the participating nodes as a write transaction queue and a read transaction queue as an example, in FIG. 9, three coordination nodes 820 respectively manage a first write transaction queue 851 and two first read transaction queues 852 (first read)
  • the transaction queue 852 is a first read transaction queue 852-1 and a first read transaction queue 852-2, respectively, wherein the coordination node 820-2 corresponds to the first read transaction queue 852-1, and the coordination node 820-3 corresponds to the management first.
  • participating node 811 manages second write transaction queue 831 and second read transaction queue 832
  • participating node 812 manages second write transaction queue 841 and second read transaction queue 842.
  • the request corresponding to the single-partition transaction is directly sent to the participating node corresponding to the single-partition transaction, and the participating node adds the single-partition transaction to the corresponding write transaction queue or read transaction. Queue; for example, in FIG. 8 or FIG. 9, when the participating node 811 receives the transaction request sent by the terminal device, the participating single-partition write transaction corresponding to the transaction request is added to the write transaction queue 831, and the transaction request is corresponding.
  • a single partition read transaction is added to the read transaction queue 832; and when the participating node 812 receives the transaction request sent by the terminal device, the single partition write transaction corresponding to the transaction request is added to the write transaction queue 841, and the transaction request is corresponding.
  • a single partition read transaction is added to the read transaction queue 842.
  • the terminal device sends the corresponding request to the coordination node 820, and the coordination node 820 adds the multi-partition transaction to the write transaction queue or the read transaction queue corresponding to the coordination node 820; specifically, the coordination node 820 receives After the transaction request sent by the terminal device, the multi-partition write transaction corresponding to the transaction request is added to the write transaction queue 851, and the multi-partition read transaction corresponding to the transaction request is added to the read transaction queue 852.
  • a transaction ID can be assigned to the multi-partition write transaction.
  • the processing process of the participating nodes on the transaction can be as follows:
  • a single-partition transaction is handled by the participating nodes where the data partition involved in the transaction is located. For example, taking the participating node 811 in FIG. 8 or FIG. 9 as an example, when processing the write transaction queue 831, the participating node 811 serially processes each write transaction in the write transaction queue 831 by one thread, for example, when After the participating node 811 extracts a single-partition write transaction involving the data partition 1 from the write transaction queue 831 in the queue order, the participating node 811 acquires a data snapshot of the data partition 1, and writes the extracted to the acquired data snapshot. After the write data corresponding to the single-partition write transaction, the data snapshot after the write data is stored as the data in the data partition 1.
  • the participating node 811 Upon processing the read transaction queue 832, the participating node 811 serially processes each single partition read transaction in the read transaction queue 832 by one thread. Specifically, for the single-partition read transaction involved in the data partition 1, the participating node 811 can obtain the data snapshot of the data partition 1 and read the data corresponding to the single-partition read transaction in the acquired data snapshot, and the read data is read. After the data is sent to the terminal device, the acquired data snapshot is deleted.
  • the multi-partition write transaction is coordinated by the coordinating node to coordinate the various participating nodes.
  • the coordinating node 820 serially processes each multi-partition write transaction in the write transaction queue 851 by one thread.
  • coordination device 820 sends the multi-partition write transaction to participating node 811 and participating node 812, respectively, to participate.
  • the node 811 adds the multi-partition write transaction to the write transaction queue 831, the participating node 812 adds the multi-partition write transaction to the write transaction queue 841, and the participating node 811 processes the data snapshot of the data partition 1 when processing the multi-partition write transaction. After obtaining the data snapshot successfully, returning the acquisition success response to the coordination node, or returning the acquisition failure response to the coordination node after failing to acquire the data snapshot. Similarly, when the participating node 812 processes the multi-partition write transaction, the data is acquired. A snapshot of the data of the partition 3, and returning a successful response or obtaining a failure response to the coordination node according to whether the snapshot of the obtained data is successful or not.
  • the coordination node 820 receives the acquisition failure response sent by one of the participating nodes, it sends a delete snapshot request to the other participating node, instructing another participating node to delete the successfully acquired data snapshot.
  • the coordinating node 820 confirms that the acquisition success response sent by the participating node 811 and the participating node 812 is received, respectively, a transaction instruction is sent to the participating node 811 and the participating node 812, respectively, and the participating node 811 writes to the data snapshot corresponding to the data partition 1. Data, and according to the success or failure of the write, return a write success response or a write failure response to the coordination node 820; at the same time, the participating node 812 writes data to the data snapshot corresponding to the data partition 3, and according to whether the write succeeds or not Returns a write success response or a write failure response to the coordination node.
  • the coordination node 820 receives the write failure response sent by one of the participating nodes, it sends a delete snapshot request to the other participating node, instructing another participating node to delete the successfully written data snapshot.
  • the coordination node 820 confirms that the write success response sent by the participating node 811 and the participating node 812 is received, respectively, the submission indication is sent to the participating node 811 and the participating node 812, respectively; the participating node 811 saves the successfully written data snapshot as the data partition. The data in 1, and after the save is completed, update the version number of the data in the data partition 1 to the transaction id of the multi-partition write transaction; the participating node 812 also saves the successfully written data snapshot as the data partition 3 Data, and after the save is complete, update the version number of the data in data partition 2 to the transaction id of the multi-partition write transaction.
  • the multi-partition read transaction is coordinated by the coordination node by each participating node.
  • the coordination node 820 serially processes each multi-partition read transaction in the read transaction queue 852 through a thread.
  • the coordination node 820 sends a snapshot acquisition request to the participating node 811 and the participating node 812, respectively.
  • the 811 obtains a data snapshot of the data partition 1 and returns the version information of the data in the data snapshot to the coordination node 820, where the version information of the data in the data snapshot is the latest commit in the data partition 1.
  • the id of the completed multi-partition write transaction correspondingly, after receiving the request, the participating node 812 obtains a data snapshot of the data partition 3, and returns the version information of the data in the data snapshot to the coordination node 820; the coordination node 820 receives The version information of the data in the data snapshot of the data partition 1 transmitted by the participating node 811, and the number sent by the participating node 812 According to the version information of the data in the data snapshot of the partition 3, it is detected whether the data snapshot of the data partition 1 and the data snapshot of the data partition 3 satisfy the consistency according to the version information.
  • the data snapshots corresponding to the at least two data partitions satisfy the consistency.
  • the version information of the data snapshot corresponding to the at least two data partitions may be the same; or the data snapshots corresponding to the at least two data partitions may be consistent with each other, or may be for each of the at least two data partitions.
  • a data partition, the obtained version information of the data snapshot of the data partition is the same as the version information of the pre-stored data partition.
  • the manner in which the coordination node 820 detects whether the data snapshot of the data partition 1 and the data snapshot of the data partition 3 satisfy the consistency according to the version information may be as follows:
  • coordination node 820 If data partition 1 and data partition 3 are two data partitions for simultaneous multi-partition writes (ie, when a multi-partition write transaction involves data partition 1, and data partition 3 is also necessarily involved), coordination node 820 The version information corresponding to the two data partitions can be directly compared with each other. If yes, the corresponding data snapshots of the two data partitions are consistent; if the version information of the two data partitions is different, the basis may be further determined. The version information determines the lower version of the data partition (ie, the data partition with a smaller id corresponding to the most recently completed multi-partition write transaction, the version is lower).
  • the coordination node 820 can maintain the version information corresponding to each data partition.
  • the coordination node 820 sends a submitting instruction to a participating node in the process of processing a multi-partition write transaction
  • the self-maintained The version information of the data partition involved in the multi-partition write transaction is updated to the id of the multi-partition write transaction; correspondingly, each participating node also maintains the version information of its corresponding data partition, in the process of processing a multi-partition write transaction
  • the participating node receives the submission instruction sent by the coordination node 820, after successfully saving the currently completed data snapshot as the data in the corresponding data partition, updating the version information of the data partition maintained by itself to the multiple The id of the partition write transaction.
  • the participating node When a multi-partition read transaction is subsequently processed, the participating node obtains a data snapshot of the data partition involved in the multi-partition read transaction, and sends the version information corresponding to the data snapshot to the coordination node 820, and the coordination node 820 sends the participating node to the node.
  • the version information is compared with the version information corresponding to the data partition that is maintained by the user. If the version information of each data snapshot corresponding to the multi-partition read transaction sent by the participating node is compared with the version information of the corresponding data partition maintained by the coordination node itself, The same, it indicates that the acquired data snapshots of the data partitions corresponding to the multi-partition read transaction satisfy the consistency.
  • the one or more ones may be determined.
  • the version information corresponding to the data snapshot is low.
  • the coordination node 820 determines the participating node corresponding to the low-version data snapshot according to the version information, and sends a re-acquisition data snapshot to the determined participating node.
  • the request after receiving the request for re-acquiring the data snapshot, the participating node deletes the original data snapshot, and re-acquires the data snapshot, and returns the version information of the data in the re-acquired data snapshot to the coordination node 820, and the coordination node 820 is
  • the version information of the data in the reacquired data snapshot again detects whether the data snapshot of the data partition 1 and the data snapshot of the data partition 3 satisfy the consistency.
  • the coordination node 820 sends a transaction instruction to the participating node 811 and the participating node 812, respectively, instructing the participating node 811 and the participating node 812 to process the multiple. Partition read request.
  • the participating node 811 and the participating node 812 receive the transaction processing instruction, the data corresponding to the multi-partition read request is read in the acquired data snapshot, and the read success is sent to the coordination node 820 according to whether the read succeeds or not. Respond or read the failure response.
  • the coordination node 820 After receiving the read failure response sent by any of the participating nodes 811 and the participating nodes 812, the coordination node 820 sends a delete snapshot request to another participating node, instructing another participating node to delete the acquired data snapshot.
  • the coordination node 820 After receiving the read success response sent by the participating node 811 and the participating node 812 respectively, the coordination node 820 sends a delete snapshot request to the participating node 811 and the participating node 812 respectively, instructing the two participating nodes to delete the acquired data. Snapshot.
  • FIG. 10 is a schematic structural diagram of a transaction processing device 100 according to an exemplary embodiment of the present application.
  • the transaction processing device 100 may be implemented as a transaction processing device 210 in the network environment shown in FIG. 1.
  • the transaction processing device 100 can include a processor 101 and a communication interface 104.
  • the processor 101 may include one or more processing units, which may be a central processing unit (CPU) or a network processor (NP).
  • processing units may be a central processing unit (CPU) or a network processor (NP).
  • CPU central processing unit
  • NP network processor
  • Communication interface 104 can include a network interface.
  • the network interface is used to connect to the terminal device.
  • the network interface may include a wired network interface, such as an Ethernet interface or a fiber interface, or the network interface may also include a wireless network interface, such as a wireless local area network interface or a cellular mobile network interface.
  • Transaction processing device 100 communicates with various terminal devices over the network interface 104.
  • the transaction processing device 100 may further include a memory 103, and the processor 101 may be connected to the memory 103 and the communication interface 104 by using a bus.
  • the memory 103 can be used to store software programs that can be executed by the processor 101.
  • various types of service data or user data can also be stored in the memory 103.
  • the software program may include a transaction receiving module, a snapshot acquisition module, an execution module, and an update module.
  • the transaction receiving module is executed by the processor 101 to implement the functions of the multi-partition transaction and the single-partition transaction sent by the receiving terminal device in the embodiment shown in FIG. 3 above.
  • the snapshot acquisition module is executed by the processor 101 to implement the function of acquiring the data snapshot satisfying the consistency in the embodiment shown in FIG. 3 above.
  • the execution module is executed by the processor 101 to implement the functions of performing the read operation or the write operation in the embodiment shown in FIG. 3 described above.
  • the update module is executed by the processor 101 to implement the function of updating the version information of the data in the data snapshot corresponding to the data partition in the embodiment shown in FIG.
  • the transaction processing device 100 may further include an output device 105 and an input device 107.
  • Output device 105 and input device 107 are coupled to processor 101.
  • the output device 105 can be a display for displaying information, a power amplifier device for playing sound, or a printer, etc.
  • the output device 105 can also include an output controller for providing output to a display screen, a power amplifier device, or a printer.
  • the input device 107 may be a device such as a mouse, a keyboard, an electronic stylus or a touch panel for inputting information by the user, and the input device 107 may further include an output controller for receiving and processing from the mouse, the keyboard, the electronic Input from devices such as stylus or touch panel.
  • FIG. 11 is a structural block diagram of a transaction processing apparatus according to an exemplary embodiment of the present application.
  • the transaction processing apparatus may be implemented as part or all of a transaction processing apparatus by a combination of hardware circuits or software and hardware, and the transaction processing apparatus may be The transaction processing device 210 in the embodiment shown in FIG. 2A above.
  • the transaction processing apparatus may include a transaction receiving unit 1101, a snapshot obtaining unit 1102, an executing unit 1103, and an updating unit 1104.
  • the transaction receiving unit 1101 is executed by the processor 81 to implement the functions of the multi-partition transaction and the single-partition transaction transmitted by the receiving terminal device in the embodiment shown in FIG. 3 described above.
  • the snapshot obtaining unit 1102 is configured to implement the function of acquiring a data snapshot that satisfies the consistency in the embodiment shown in FIG. 3.
  • the execution unit 1103 is configured to implement the function of performing the read operation or the write operation in the embodiment shown in FIG. 3 described above.
  • the updating unit 1104 is configured to implement the function of updating the version information of the data in the data snapshot corresponding to the data partition in the embodiment shown in FIG. 3.
  • FIG. 12 is a system configuration diagram of a transaction processing system according to an exemplary embodiment of the present application.
  • the transaction processing system can include a transaction processing device 122 and at least two data partitions 124.
  • the transaction processing device 122 can be implemented as the transaction processing device shown in FIG. 11 above, and the transaction processing device is used to implement the transaction processing method in the embodiment shown in FIG.
  • the transaction processing apparatus provided in the foregoing embodiment performs transaction processing
  • only the division of each functional unit described above is used for illustration. In actual applications, the function allocation may be completed by different functional units as needed.
  • the internal structure of the device is divided into different functional units to complete all or part of the functions described above.
  • the transaction processing apparatus provided by the foregoing embodiment is the same as the method embodiment of the transaction processing method, and the specific implementation process is described in detail in the method embodiment, and details are not described herein again.
  • a person skilled in the art may understand that all or part of the steps of implementing the above embodiments may be completed by hardware, or may be instructed by a program to execute related hardware, and the program may be stored in a computer readable storage medium.
  • the storage medium mentioned may be a read only memory, a magnetic disk or an optical disk or the like.

Landscapes

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

Abstract

一种事务处理方法、装置及设备，涉及数据库技术领域，所述方法包括：接收待处理事务，所述述待处理事务是在至少两个数据分区中进行操作的事务（21）；获取所述至少两个数据分区对应的，且满足一致性的数据快照（22）；根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作（23）。通过对多分区事务涉及的各个数据分区获取满足一致性的数据快照，并基于数据快照进行多分区事务对应的操作，支持读事务和写事务之间的并行执行，避免写事务与读事务之间相互阻塞的情况，从而达到提高系统的吞吐量和服务等级的效果。

Description

一种事务处理方法、装置及设备 技术领域
本申请涉及数据库技术领域，特别涉及一种事务处理方法、装置及设备。
背景技术
传统的基于数据库本地事务的解决方案只能保障单个服务的一次处理具有一致性，但无法保障多个分布服务间处理的一致性，因此需要建立一套分布式服务处理之间的协调机制，以实现多版本并发控制(Multi-Version Concurrency Control，MVCC)。
在相关技术中，服务器区分单分区事务(事务操作只涉及一个数据分区)和多分区事务(事务操作涉及多个数据分区)，并对每一个数据分区分别设置事务队列。在接收到一个事务时，服务器将单分区事务添加入对应的数据分区的事务队列，并将多分区事务添加到对应的多个数据分区的事务队列。在对事务进行处理时，服务器对各个事务队列中的事务逐一进行处理，其中，为了保证数据分区之间的一致性，对于多个数据分区中相同的多分区写事务，服务器会进行协同处理。
比如，请参考图1，其示出了相关技术涉及的一种事务处理示意图。在图1中，数据分区1对应事务队列1，数据分区2对应事务队列2，其中，事务队列1中包含两个事务，分别为单分区事务1和多分区事务2，而事务队列2中包含两个事务，分别为多分区事务2和单分区事务3。在处理事务的过程中，服务器按照事务队列，首先分别提取出队列1中单分区事务1和队列2中的多分区事务2，此时，服务器针对数据分区1执行单分区事务1，并针对数据分区2执行多分区事务2，在单分区事务1处理完成后，服务器提取到事务队列1中的多分区事务2，此时，由于针对数据分区1的多分区事务2尚未执行完成，此时即便针对数据分区2的多分区事务2已经执行完成，服务器也不会立刻执行队列2中的单分区事务3，而是等待针对数据分区2的多分区事务2执行完成后，再执行单分区事务3。
多分区事务一般是长事务，通常处理的时间比较久，而单分区事务通常是短事务，处理的时间比较短，在上述相关技术中，当不同的事务队列中的相同多分区事务的处理进度不同时，多分区事务的处理会对单分区事务形成阻塞，从而导致系统的吞吐量和服务等级不高，影响用户体验。
发明内容
为了提高系统的吞吐量和服务等级，本申请的实施例提供了一种事务处理方法、装置及设备。
第一方面，提供了一种事务处理方法，所述方法包括：
接收待处理事务，所述待处理事务是在至少两个数据分区中进行操作的事务；获取所述至少两个数据分区对应的，且满足一致性的数据快照；根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作。
在上述第一方面所示的方案中，对于涉及至少两个数据分区的多分区事务，通过对多分区事务涉及的各个数据分区获取满足一致性的数据快照，并基于数据快照进行多分区事务对应的操作，支持读事务和写事务之间的并行执行，避免写事务与读事务之间相互阻塞的情况，从而达到提高系统的吞吐量和服务等级的效果。
在一种可能的设计中，所述待处理事务是在所述至少两个数据分区中进行读操作的事务。
在一种可能的设计中，所述获取所述至少两个数据分区对应的，且满足一致性的数据快照，包括：获取所述至少两个数据分区各自的数据快照，以及所述至少两个数据分区各自的数据快照的版本信息；根据所述至少两个数据分区各自的数据快照的版本信息，检测所述至少两个数据分区各自的数据快照是否满足一致性；若检测结果为所述至少两个数据分区各自的数据快照满足一致性，则确定成功获取到所述至少两个数据分区各自对应且满足一致性的数据快照。
在上述可能的设计方案中，在获取多分区事务对应的数据快照时，还一并获取数据快照的版本信息，并基于获取到的数据快照的版本信息来检查多个数据分区分别对应的数据快照之间是否满足一致性，避免获取到不满足一致性的快照。
在一种可能的设计中，所述获取所述至少两个数据分区对应的，且满足一致性的数据快照，还包括：若检测结果为所述至少两个数据分区各自的数据快照不满足一致性，则重新获取版本低的数据分区的数据快照，以及重新获取到的数据快照的版本信息；根据重新获取到的数据快照的版本信息检测所述至少两个数据分区各自的数据快照是否满足一致性。
在上述可能的设计方案中，在获取到的数据快照不满足一致性时，对于数据快照版本低的数据分区，重新获取该数据分区对应的数据快照和版本信息，并继续判断数据快照之间是否满足一致性。
在一种可能的设计中，所述方法还包括：若检测结果为所述至少两个数据分区各自的数据快照不一致，则删除已获取的版本低的数据分区的数据快照。
在上述可能的设计方案中，所述数据快照的版本信息包含所述数据快照生成时，所述数据快照对应的数据分区中最近一次写入的多分区写事务的标识，所述多分区写事务是在至少两个数据分区中进行写操作的事务。
在上述可能的设计方案中，使用最近一次写入的多分区写事务的标识作为数据分区的版本信息，避免多分区读操作时读取到写入不一致的数据，保证数据读取的准确性。
在一种可能的设计中，所述待处理事务是在所述至少两个数据分区中进行写操作的事务，所述根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作，包括：
在所述至少两个数据分区对应的，且满足一致性的数据快照中执行所述待处理事务对应的写操作；将执行所述待处理事务对应的写操作之后的数据快照保存为对应的数据分区中的数据。
在一种可能的设计中，所述待处理事务是在所述至少两个数据分区中进行写操作的事务，所述方法还包括：
在根据所述至少两个数据分区各自对应且满足一致性的数据快照执行所述待处理事务 对应的写操作成功后，将所述待处理事务的标识更新为所述至少两个数据分区各自对应的版本信息。
第二方面，提供了一种事务处理装置，该装置具有实现上述第一方面及第一方面的可能的设计方案所提供的事务处理方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多于一个与上述功能相对应的单元。
第三方面，提供了一种事务处理设备，该设备包括：处理器、存储器和通信接口，该通信接口被配置为由该处理器控制；该设备中的处理器控制该通信接口，通过执行存储器中存储的程序或指令以实现上述第一方面及第一方面的可能的设计方案所提供的事务处理方法。
第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有可执行程序，该可执行程序由处理器执行以实现上述第一方面及第一方面的可能的设计方案所提供的事务处理方法。
第五方面，提供了一种事务处理系统，系统包括事务处理装置和至少两个数据分区；该事务处理装置用于实现上述第一方面及第一方面的可能的设计方案所提供的事务处理方法。
附图说明
图1是相关技术涉及的一种事务处理示意图；
图2A是本申请各个实施例涉及的一种事务处理系统的架构图；
图2B是本申请各个实施例涉及的一种多分区事务处理流程示意图；
图3是本申请一个示例性实施例提供的事务处理方法的方法流程图；
图4是图3所示实施例涉及的一种第二写事务队列与数据分区的对应关系示意图；
图5是图3所示实施例涉及的一种第二读事务队列与数据分区的对应关系示意图；
图6是图3所示实施例涉及的第一事务队列与特殊分区的对应关系示意图；
图7是本申请一个示例性实施例提供的一种参与节点组成示意图；
图8是本申请一个示例性实施例提供的事务处理设备实现示意图；
图9是本申请一个示例性实施例提供的事务处理设备实现示意图；
图10是本申请一个示例性实施例提供的事务处理设备的结构示意图；
图11是本申请一个示例性实施例提供的一种事务处理装置的结构方框图；
图12是本申请一个示例性实施例提供的一种事务处理系统的系统构成图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
图2A是本申请所涉及的一种事务处理系统的架构图。该系统包括以下设备：事务处理设备210以及至少一个终端设备220。
其中，事务处理设备210可以是一台通用计算机或者工作站，或者，事务处理设备210也可以是单台服务器、服务器集群或者云计算中心等。
在本申请实施例中，事务处理设备210对应的数据可以分为一个或者多个数据分区。其中，分区是指一个连续的取值范围。在本申请实施例中，数据分区可以是将数据的字段(主键字段或非主键字段)按照一定的哈希(hash)算法进行哈希计算后得到的一段连续区间。
事务处理设备210与至少一个终端设备220之间通过有线或者无线网络相连接。
事务处理设备210用于对至少一个终端设备220发送的事务进行处理，其中，至少一个终端设备220发送的事务还可以分为单分区事务和多分区事务。从另一角度来说，至少一个终端设备220发送的事务还可以分为读事务和写事务。
在实际应用中，对于同一个数据分区，写事务会改变数据分区中存储的数据，而读事务则不会改变数据分区中存储的数据，即写事务和读事务实际上是可以并行执行的。因此，请参考图2B，其是本申请各个实施例涉及的多分区事务处理流程示意图，如图2B所示，事务处理设备210在处理事务时，对于多分区事务的处理步骤如下：
步骤21，接收待处理事务，该待处理事务是在至少两个数据分区中进行操作的事务。
步骤22，获取该至少两个数据分区对应的，且满足一致性的数据快照。
步骤23，根据该至少两个数据分区对应的，且满足一致性的数据快照执行该待处理事务对应的操作。
即在本申请实施例中，事务处理设备在进行读操作或者写操作时，并不直接在数据分区中操作，而是在数据分区对应的数据快照中进行操作，对于一个数据分区，同一时间可以向一个写事务以及至少一个读事务提供数据快照，也就是说，可以同时支持一个写事务和至少一个读事务的处理，即对该数据分区的写事务和读事务之间不会相互阻塞，从而提高系统的吞吐量和服务等级。
图3是本申请一个示例性实施例提供的事务处理方法的方法流程图。该方法可以用于如图1所示系统的事务处理设备210中。如图3所示，该事务处理方法可以包括如下步骤：
步骤301，接收终端设备发送的待处理事务，若该待处理事务是多分区事务，则进入步骤302，若该待处理事务是单分区事务，则进入步骤303。
其中，单分区事务是在单个数据分区中进行操作的事务，多分区事务是在至少两个数据分区中进行操作的事务。
更具体的，单分区读事务是在涉及的单个数据分区中进行读操作的事务，单分区写事务是在涉及的单个数据分区中进行写操作的事务；相应的，多分区读事务是在涉及的至少两个数据分区中进行读操作的事务，多分区写事务是在涉及的至少两个数据分区中进行写操作的事务。
在本申请实施例中，终端设备可以向事务处理设备发送事务处理请求，该事务处理请求中包含待处理的事务。
其中，上述事务处理请求中可以包含分区指示信息，该分区指示信息可以指示该待处 理的事务是单分区事务还是多分区事务。
可选的，上述事务处理请求可以不包含分区指示信息，分区指示信息可以由事务处理设备解析事务处理请求中的关键信息获得。
步骤302，根据多分区事务的事务类型，将该多分区事务添加入第一读事务队列或者第一写事务队列。
其中，上述事务处理请求中还可以包含事务的事务类型，或者，事务处理设备也可以根据待处理的事务进行分析以确定对应的事务类型。
本申请实施例中的事务队列可以分为两级队列，事务处理设备在接收到多分区事务时，首先将多分区事务添加入第一级队列，后续在并行处理的过程中，再将第一级队列中的多分区事务添加入第二级队列。其中，第一级队列为上述第一读事务队列和第一写事务队列；第二级队列是每一个数据分区各自对应的第二读事务队列和第二写事务队列。
其中，第一级队列包括第一读事务队列和/或第一写事务队列，事务处理设备接收到一个多分区事务之后，若该多分区事务的事务类型是读事务，则将该多分区事务添加入第一读事务队列，反之，若该多分区事务的事务类型是写事务，则将该多分区事务添加入第一写事务队列。
步骤303，根据单分区事务的事务类型，将该单分区事务添加至对应的数据分区的第二读事务队列或者第二写事务队列。
在本申请实施例中，每个数据分区只对应一个第二写事务队列，而每个第二写事务队列可以对应一个或者多个数据分区。当事务处理设备接收到单分区事务时，若该单分区事务是写事务，则将该单分区事务添加至该单分区事务对应的第二写事务队列。
比如，请参考图4，其示出了本申请实施例涉及的一种第二写事务队列与数据分区的对应关系示意图；如图4(a)所述，数据分区1和数据分区2可以对应同一个第二写事务队列(写事务队列1)，即对数据分区1的单分区写事务和对数据分区2的单分区写事务都添加至写事务队列1；或者，如图4(b)所示，两个数据分区可以分别对应一个第二写事务队列(即数据分区1对应写事务队列1，数据分区2对应写事务队列2)，即对数据分区1的单分区写事务添加至写事务队列1，对数据分区2的单分区写事务添加至写事务队列2。
数据分区与第二读事务队列之间没有对应关系的限定，可以是一对一、一对多或者多对多的关系。当事务处理设备接收到单分区事务时，若该单分区事务是读事务，则将该单分区事务添加至该单分区事务对应的第二读事务队列，其中，当该单分区事务对应多个第二读事务队列时，只将该单分区事务添加至对应的多个第二读事务队列中的一个队列。
比如，请参考图5，其示出了本申请实施例涉及的一种第二读事务队列与数据分区的对应关系示意图；如图5(a)所述，数据分区1和数据分区2可以对应同一个第二读事务队列(读事务队列1)，即对数据分区1的单分区读事务和对数据分区2的单分区读事务都添加至读事务队列1；或者，如图5(b)所示，两个数据分区可以分别对应一个第二读事务队列(即数据分区1对应读事务队列1，数据分区2对应读事务队列2)，即对数据分区1的单分区读事务添加至读事务队列1，对数据分区2的单分区读事务添加至读事务队列2；或者，如图5(c)所示，数据分区1可以同时对应读事务队列1和读事务队列2，即对数据分区1的单分区读事务可以添加至读事务队列1或者读事务队列2；或者，如图5(d)所示，数据分区1可以同时对应读事务队列1和读事务队列2，同时，数据分区2也同时对应 读事务队列1和读事务队列2，即对数据分区1的单分区读事务可以添加至读事务队列1或者读事务队列2，并且，对数据分区2的单分区读事务也可以添加至读事务队列1或者读事务队列2。
可选的，数据分区虽然与第一事务队列没有对应关系，但可以给第一事务队列分配具有特殊标志的特殊分区，该特殊分区不用来存储数据，而特殊分区的特殊标志用于区别数据分区或其他特殊分区。
请参考图6，其示出了本申请实施例涉及的第一事务队列与特殊分区对应关系示意图；如图6(a)所述，特殊分区分为写特殊分区和读特殊分区，写特殊分区和第一写事务队列的数量各自为一，且一一对应。所有的多分区写事务都进该写特殊分区对应的第一写事务队列；如图6(b)所示，第一读事务队列有一至多个(图中示出为两个)，每个第一读事务队列都对应一个读特殊分区(图中示出为第一读事务队列1对应读特殊分区1，第一读事务队列2对应读特殊分区2)。对于多分区读事务，该多分区事务可以进第一读事务队列1，也可以进第一读事务队列2。
需要说明的是，上述写特殊分区对应的第一写事务队列，也可以作为一个特殊的写队列加入到第二写事务队列中。
类似的，上述读特殊分区对应的第一读事务队列，也可以作为特殊的读队列加入到第二读事务队列中。
步骤304，对读事务队列和写事务队列并行处理。
在本申请实施例中，事务处理设备对上述步骤302和步骤303涉及到的各个读事务队列和写事务队列进行并行处理时，事务处理设备对同一个写事务队列中的各个写事务进行串行处理，即对于一个写事务队列中的多个写事务，事务处理设备在对前一个写事务处理完成后，才会处理该写事务队列中的下一个写事务。事务处理设备对同一个读事务队列中的各个读事务可以串行处理；或者，事务处理设备对同一个读事务队列中的各个读事务也可以并行处理，比如，对于一个读事务队列，事务处理设备可以通过多个线程同时处理该读事务队列中的多个读事务。
在本申请实施例中，事务处理设备可以通过数据快照对各个事务进行处理，另外，由于本申请实施例中涉及到多分区读事务和多分区写事务的处理，而多分区事务的处理过程中需要考虑数据的一致性原则，因此，在本申请实施例中，通过数据快照对各个事务进行处理时，需要保证获取到的数据快照满足一致性。具体处理过程可以如下：
一、对于单分区读事务或者单分区写事务的处理。
在对单分区读事务或者单分区写事务进行处理时，事务处理设备可以获取单分区读事务或者单分区写事务对应的数据分区的数据快照，并在成功获取到数据快照后，根据数据快照实现事务的读或者写。
具体的，在对单分区写事务进行处理时，对于上述任意一个第二写事务队列，事务处理设备获取该第二写事务队列中到达处理位置(比如，该处理位置可以是队列的队首位置)的单分区写事务，获取该单分区写事务对应的数据分区的数据快照，并在获取到的数据快照中写入该单分区写事务对应的写入数据，并将写入数据后的数据快照存储为对应的数据分区中的数据。其中，上述将数据写入数据快照，并将数据快照存储为数据分区中的数据的步骤可以称为写事务的提交(commit)。
类似的，在对单分区读事务进行处理时，对于上述任意一个第二读事务队列，事务处理设备获取该第二读事务队列中到达处理位置的单分区读事务，获取该单分区读事务对应的数据分区的数据快照，从获取到的数据快照中读取该单分区读事务对应的数据，并将读取的数据发送给对应的终端设备，同时将该数据快照删除。
由于单分区事务只涉及到的单个数据分区，而单个数据分区的数据快照不存在不满足一致性的问题，即在本申请实施例中，当待处理事务只涉及一个数据分区时，可以认为获取到的该待处理事务对应的数据快照必然是满足一致性的。
二、对于多分区读事务的处理。
对于读事务队列中的任一多分区事务，事务处理设备可以确定该多分区事务对应的各个数据分区，获取该各个数据分区各自对应的，且满足一致性的数据快照，并对各个数据分区各自的数据快照分别进行该多分区事务对应的读操作。
在本发明实施例中，各个数据分区各自对应的数据快照满足一致性，是指对于各个数据分区中的任意两个数据分区，在获取这两个数据分区的数据快照时，最近一次同时涉及到这两个数据分区的多分区写事务在这两个数据分区中已写入完成。
具体的，对于上述第一读事务队列中的各个多分区事务，事务处理设备可以获取该第一读事务队列中到达处理位置的多分区事务，并将获取到的多分区事务添加至该多分区事务对应的一个第二读事务队列中，当该多分区事务到达该第二读事务队列中的处理位置时，事务处理设备再获取该多分区事务对应的各个数据分区各自的数据快照。或者，事务处理设备获取到该第一读事务队列中到达处理位置的多分区事务后，也可以直接获取该多分区事务对应的各个数据分区各自的数据快照。
其中，由于多分区读事务会涉及到对多个数据分区中的数据进行读取操作，而本申请实施例中的读事务和写事务是并行处理的，而多分区写事务在不同的数据分区中commit的时间并不是绝对相同的，因此，多分区写事务的对外可见性也可能存在先后顺序，在某一时刻，对同一个多分区读事务对应的不同的数据分区获取到的数据快照不满足一致性，此时直接按照获取到的数据快照读取的数据可能会不一致。因此，在本申请实施例中，事务处理设备在获取上述多分区读事务涉及的至少两个数据分区对应的，且满足一致性的数据快照时，可以获取该至少两个数据分区各自的数据快照，以及该至少两个数据分区各自的数据快照的版本信息，并根据该各个数据分区各自的数据快照中的数据的版本信息，检测该各个数据分区各自的数据快照是否满足一致性，若该各个数据分区各自的数据快照满足一致性，则执行对各个数据分区各自的数据快照分别进行该多分区事务对应的读操作的步骤；反之，若各个数据分区各自的数据快照不满足一致性，则对于数据的版本信息对应的版本低(即不是最高版本)的数据分区，事务处理设备删除已获取的数据版本低的数据快照，并重新获取该据分区的数据快照，并根据重新获取到的数据快照中的数据的版本信息检测各个数据分区的数据快照是否一致。
在本申请实施例中，上述数据快照中的数据的版本信息包含该数据快照生成时，该数据快照对应的数据分区中最近一次写入的多分区事务(即多分区写事务)的标识。
其中，事务处理设备在接收到一个多分区事务后，可以为该多分区事务分配对应的标识。具体的，上述多分区事务的标识可以是多分区事务的ID或者唯一编号。
进一步的，不同的多分区事务的标识可以用来区分不同的多分区事务被处理的先后顺 序，比如，以多分区事务的标识是ID为例，事务处理设备在分配事务类型为写事务的多分区事务的ID时，分配给各个多分区事务的ID从1开始递增，则ID越小的多分区事务，其被处理的顺序越靠前，对应的数据的版本也越低，而ID越大的多分区事务，其被处理的顺序越靠后，对应的数据的版本也越高。
三、对于多分区写事务的处理。
对于该写事务队列中的任一待处理事务(即多分区写事务)，事务处理设备可以确定该多分区写事务对应的至少两个数据分区，获取该至少两个数据分区各自的数据快照，对该至少两个数据分区各自的数据快照分别进行该多分区写事务对应的写操作，当对该至少两个数据分区各自的数据快照分别进行的写操作完成后，将该至少两个数据分区各自的数据快照保存为该至少两个数据分区各自的数据。
在本申请实施例中，由于事务处理设备对同一个写事务队列中的各个写事务进行串行处理，即对于一个写事务队列中的多个写事务，事务处理设备在对前一个写事务处理完成后，才会处理该写事务队列中的下一个写事务，也就是说，当事务处理设备在处理一个多分区写事务时，该多分区写事务对应的至少两个数据分区各自对应的上一个写事务都已经处理完成，因此，此时获取到的该至少两个数据分区各自对应的数据快照，必然是满足单一性的，即在处理多分区写事务时，事务处理设备不需要通过数据快照对应的版本信息来检测获取到的数据快照是否满足单一性。
可选的，在根据上述至少两个数据分区各自对应且满足一致性的数据快照执行多分区写事务(即待处理事务)对应的写操作成功后，事务处理设备还将待处理事务的标识更新为上述至少两个数据分区各自对应的版本信息。
具体的，对于上述第一写事务队列中的各个多分区写事务，事务处理设备可以获取该第一写事务队列中到达处理位置的多分区写事务，并将获取到的多分区写事务添加至该多分区写事务涉及的各个数据分区各自对应的第二写事务队列中，当该多分区写事务在各个数据分区各自对应的第二写事务队列中都到达处理位置时，事务处理设备获取各个数据分区各自的数据快照。其中，各个数据分区可能同时对应有待处理的单分区写事务和多分区写事务，为了避免出现数据不一致的情况，在处理写入事务时，同一个数据分区对应的写事务，无论是单分区事务还是多分区事务，都需要统一进行串行处理，因此，在本申请实施例中，对于第一写事务队列中的多分区写事务，事务处理设备在处理到该多分区写事务时，将该多分区写事务分别添加至涉及到的各个数据分区各自对应的第二写事务队列中，与各个数据分区各自的单分区写事务一起进行串行排序，各个数据分区各自对应的第二写事务队列中的每一个队列都执行到该多分区写事务时，事务处理设备才获取各个数据分区对应的数据快照并执行写入操作。或者，在上述任意一个第二写事务队列执行到该多分区写事务时，事务处理设备可以不用等待其它包含该多分区写事务的第二写事务队列执行到该多分区写事务，而是直接获取已经执行到该多分区写事务的第二写事务队列所对应的数据分区的数据快照，并在获取到的数据快照中进行写操作，等到在该多分区写事务涉及的所有数据分区对应的数据快照中都完成该多分区写事务对应的写操作后，在将该多分区写事务对应的所有写入后的数据快照存储为各自对应的数据分区中的数据。
可选的，对于上述第一写事务队列中的各个多分区事务，事务处理设备可以获取该第一写事务队列中到达处理位置的多分区事务，并将获取到的多分区事务添加至写特殊分区 对应的第二写事务队列中，当写特殊分区对应的第二写事务队列的该事务被调度到(即被处理到)时，事务处理设备获取各个数据分区各自的数据快照。其中，该写特殊分区对应第二写事务队列的该事务执行时，会阻塞其他数据分区的单分区写事务。
在实际应用中，还可能出现某两个数据分区对应的第二写事务队列是同一个队列的情况，事务处理设备在这两个数据分区对应的第二写事务队列中只添加一次该多分区写事务。
综上所述，本申请实施例所示的事务处理方法，事务处理设备对多分区事务涉及的各个数据分区获取满足一致性的数据快照，并基于数据快照进行多分区事务对应的读操作或者写操作，支持读事务和写事务之间的并行执行，避免同一数据分区对应的写事务和读事务之间相互阻塞的情况，从而达到提高系统的吞吐量和服务等级的效果。
在本申请实施例中，上述图3对应的实施例中的各个步骤可以分别由事务处理设备中不同的功能组件来实现。这些功能组件可以是通过软件或者软硬结合实现的逻辑功能组件。比如，上述每个功能组件可以是一个独立的功能节点(比如独立的虚拟机或者进程)，各个功能节点之间交互实现事务的处理。
具体比如，上述事务处理设备中的功能节点可以分为两种，分别可以称为协调节点和参与节点。其中，协调节点的个数可以是一个，作用是负责协调处理多分区事务；可选的，协调节点的个数可以是多个，其中一个协调节点用来处理多分区写和/或读事务，其他协调节点用来负责处理多分区读事务，也就是多分区写的协调节点只有一个，多分读的协调节点可以有多个。而参与节点可以有多个，并且每个参与节点对应各自的数据分区，其作用是负责独自处理涉及对应的数据分区的单分区事务，或者在协调节点协调下处理涉及对应的数据分区的多分区事务；可选的每个参与节点除了有各自对应的数据分区，还有写特殊分区以及读特殊分区，写特殊分区和读特殊分区用来处理协调节点下发的多分区写事务和多分区读事务。
其中，协调节点负责管理上述图3所示实施例中的第一读事务队列和第一写事务队列，而每个参与节点负责各自的一至多个数据分区对应的第二读事务队列和第二写事务队列。
可选的，每个参与节点负责的第二读事务队列和第二写事务队列还包括读特殊分区和写特殊分区对应的读队列和写队列。
其中，上述参与节点所执行的步骤可以分别由三种功能模块来实现。具体的，请参考图7，其是本申请一个示例性实施例提供的一种参与节点组成示意图。在图7中，参与节点70包括排序模块701、调度模块702以及存储引擎703。
其中，上述排序模块701用于实现将单分区事务添加至相应的第二读事务队列/第二写事务队列的步骤。或者，排序模块701也可以用于实现将协调节点从第一队列(包括第一写事务队列和/或第一读事务队列)分发的多分区事务添加到对应的第二队列(包括第二写事务队列和/或第二读事务队列)进行排序的步骤。
上述调度模块702用于实现对第二读事务队列/第二写事务队列中的事务进行调度处理的步骤。
上述存储引擎703用于实现获取、存储以及删除对应数据分区的数据快照，以及，维护获取到的数据快照中的数据的版本信息的功能。
可选的，每个参与节点70中，存储引擎703有且只有一个，且该参与节点70将对应 的一至多个数据分区作为一个整体进行读写处理，即在处理一个事务时，无论该事务是否涉及到该参与节点对应的数据分区中的所有数据分区，存储引擎703都获取对应的所有数据分区的数据快照，且该所有数据分区中的数据共用一个版本信息。
或者，当参与节点70上的数据分区的数量大于或者等于两个时，参与节点70中，存储引擎703也可以有多个，且每个存储引擎703负责存储其中一个或多个数据分区的数据快照和版本信息。参与节点70在处理一个事务时，可以只获取本节点上的数据分区中，该事务涉及的部分数据分区的数据快照。
在一种可能的实现场景中，多个数据分区对应同一个第二写事务队列，即涉及到该多个数据分区的单分区写事务和多分区写事务都会被添加至同一个第二写事务队列。
可选的，协调节点是独立于上述各个参与节点之外的一个功能节点，该协调节点负责管理第一读事务队列和第一写事务队列，并协调各个参与节点处理第一读事务队列和第一写事务队列中的多分区事务。
或者，协调节点同时也是一个参与节点，该协调节点除了管理第一读事务队列和第一写事务队列，以及协调各个参与节点处理第一读事务队列和第一写事务队列中的多分区事务之外，还负责管理对应的第二读事务队列和第二写事务队列，以及处理对应的第二读事务队列和第二写事务队列中的事务。
或者，协调节点同时也是一个参与节点，该协调节点的第一写事务队列是第二写事务队列中写特殊分区对应的写事务队列，该协调节点的第一读事务队列是第二读事务队列中读特殊分区对应的读事务队列。对于多分区事务，可以先添加至第一事务队列，待多分区事务调度到时，再分发给数据分区对应的第二事务队列，或者可选的，对于多分区事务，可以先添加至第一事务队列，待多分事务调度到时，再分发给特殊分区对应的第二事务队列，对于本节点来说，认为已经到达执行位置，不需要再向本节点的特殊分区的第二事务队列中添加请求。
或者，协调节点同时也是一个参与节点，该协调节点的第一写事务队列等同于该节点上的第二写事务队列，该协调节点的第一读事务队列等同于该节点上的第二读事务队列。对于多分区写事务，直接进每个第一写事务队列也即第二写事务队列中，待所有第一写事务队列也即第二写事务队列调度到同一个多分区写事务时，再分发请求给第二写事务队列，对于本节点认为已经到达执行位置，不需要再向本节点的所有第二写事务队列添加请求。类似的，对于多分区读事务，直接进某一个第一读事务队列也即第二读事务队列中，待该事务被调度到时，再分发请求给第二读事务队列，对于本节点认为已经到达执行位置，不需要再向本节点的第二读事务队列添加请求。
图8是本申请一个示例性实施例提供的事务处理设备实现示意图。在图8中，事务处理设备80可以包括至少一个参与节点(图8中示出为参与节点811和参与节点812)以及协调节点820。其中，每个参与节点上有一至多个数据分区(图8中示出为参与节点811上有数据分区1和数据分区2，参与节点812上有数据分区3)。协调节点可以是参与节点中的一个，或者，协调节点也可以是独立的节点，。以每个参与节点对应一个写事务队列和一个读事务队列为例，在图8中，协调节点820管理第一写事务队列851和第一读事务队列852，参与节点811管理第二写事务队列831和第二读事务队列832，参与节点812管理第二写事务队列841和第二读事务队列842。
图9是本申请一个示例性实施例提供的事务处理设备实现示意图。在图9中，事务处理设备80可以包括至少一个参与节点(图9中示出为参与节点811和参与节点812)以及至少两个协调节点820(图9中示出为3个协调节点820，分别为协调节点820-1、协调节点820-2以及协调节点820-3)。其中，每个参与节点上有一至多个数据分区(图9中示出为参与节点811上有数据分区1和数据分区2，参与节点812上有数据分区3)。协调节点可以是参与节点中的一个，或者，协调节点也可以是独立的节点，。以每个参与节点对应一个写事务队列和一个读事务队列为例，在图9中，3个协调节点820分别管理一个第一写事务队列851和两个第一读事务队列852(第一读事务队列852分别为第一读事务队列852-1以及第一读事务队列852-2，其中，协调节点820-2对应管理第一读事务队列852-1，协调节点820-3对应管理第一读事务队列852-2)，参与节点811管理第二写事务队列831和第二读事务队列832，参与节点812管理第二写事务队列841和第二读事务队列842。
终端设备在向事务处理设备发送事务处理请求时，将单分区事务对应的请求直接发送给该单分区事务对应的参与节点，由参与节点将该单分区事务添加至相应的写事务队列或者读事务队列；比如，在图8或图9中，参与节点811接收到终端设备发送的事务处理请求时，将事务处理请求对应的单分区写事务添加至写事务队列831，并将事务处理请求对应的单分区读事务添加至读事务队列832；而参与节点812接收到终端设备发送的事务处理请求时，将事务处理请求对应的单分区写事务添加至写事务队列841，并将事务处理请求对应的单分区读事务添加至读事务队列842。
对于多分区事务，终端设备则将对应的请求发送给协调节点820，由协调节点820将该多分区事务添加至协调节点820对应的写事务队列或者读事务队列；具体的，协调节点820接收到终端设备发送的事务处理请求后，将事务处理请求对应的多分区写事务添加至写事务队列851，并将事务处理请求对应的多分区读事务添加至读事务队列852。其中，协调节点820在将多分区写事务添加入写事务队列851时，可以为该多分区写事务分配一个事务ID。
其中，参与节点对事务的处理过程可以如下：
一、对单分区事务的处理。
单分区事务由该事务涉及的数据分区所在的参与节点处理。比如，以图8或图9中的参与节点811为例，在对写事务队列831进行处理时，参与节点811通过一个线程对写事务队列831中的各个写事务进行串行处理，比如，当参与节点811按照队列顺序从写事务队列831中提取出一个涉及数据分区1的单分区写事务之后，参与节点811获取数据分区1的数据快照，并在获取到的数据快照中写入该提取到的单分区写事务对应的写入数据之后，将写入数据之后的数据快照存储为该数据分区1中的数据。
在对读事务队列832进行处理时，参与节点811通过一个线程对读事务队列832中的各个单分区读事务进行串行处理。具体的，对于数据分区1涉及的单分区读事务，参与节点811可以获取数据分区1的数据快照，并在获取到的数据快照中读取该单分区读事务对应的数据，在将读取到的数据发送给终端设备之后，将获取到的数据快照删除。
二、对多分区写事务的处理。
多分区写事务由协调节点协调各个参与节点进行处理，比如，以图8或图9所示，协调节点820通过一个线程对写事务队列851中的各个多分区写事务进行串行处理。具体的， 对于每一个多分区写事务，假设该多分区写事务涉及到向数据分区1和数据分区3中写入数据，则协调设备820将多分区写事务分别发送给参与节点811和参与节点812，参与节点811将该多分区写事务添加至写事务队列831，参与节点812将该多分区写事务添加至写事务队列841，参与节点811处理到该多分区写事务时，获取数据分区1的数据快照，在获取数据快照成功后，向协调节点返回获取成功响应，或者，在获取数据快照失败后，向协调节点返回获取失败响应，类似的，参与节点812处理到该多分区写事务时，获取数据分区3的数据快照，并根据获取数据快照成功与否，向协调节点返回获取成功响应或者获取失败响应。
若协调节点820接收到其中一个参与节点发送的获取失败响应，则向另一个参与节点发送删除快照请求，指示另一个参与节点删除获取成功的数据快照。
如果协调节点820确认接收到参与节点811和参与节点812各自发送的获取成功响应，则分别向参与节点811和参与节点812发送事务处理指示，参与节点811向数据分区1对应的数据快照中写入数据，并根据写入成功与否，向协调节点820返回写入成功响应或者写入失败响应；同时，参与节点812向数据分区3对应的数据快照中写入数据，并根据写入成功与否，向协调节点返回写入成功响应或者写入失败响应。
若协调节点820接收到其中一个参与节点发送的写入失败响应，则向另一个参与节点发送删除快照请求，指示另一个参与节点删除写入成功的数据快照。
如果协调节点820确认接收到参与节点811和参与节点812各自发送的写入成功响应，则分别向参与节点811和参与节点812发送提交指示；参与节点811将写入成功的数据快照保存为数据分区1中的数据，并在保存完成后，将数据分区1中的数据的版本号更新为该多分区写事务的事务id；参与节点812也将写入成功的数据快照保存为数据分区3中的数据，并在保存完成后，将数据分区2中的数据的版本号更新为该多分区写事务的事务id。
三、对多分区读事务的处理。
多分区读事务由协调节点协调各个参与节点进行处理，比如，以图8或图9所示，协调节点820通过一个线程对读事务队列852中的各个多分区读事务进行串行处理，具体的，对于某一个多分区读事务，假设该多分区读事务涉及到读取数据分区1和数据分区3中的数据，则协调节点820分别向参与节点811和参与节点812发送快照获取请求，参与节点811接收到该请求后，获取数据分区1的数据快照，并向协调节点820返回该数据快照中的数据的版本信息，其中，数据快照中的数据的版本信息是该数据分区1中最近一次commit完成的多分区写事务的id；相应的，参与节点812接收到该请求后，获取数据分区3的数据快照，并向协调节点820返回该数据快照中的数据的版本信息；协调节点820接收到参与节点811发送的数据分区1的数据快照中的数据的版本信息，以及参与节点812发送的数据分区3的数据快照中的数据的版本信息后，根据版本信息检测该数据分区1的数据快照与数据分区3的数据快照是否满足一致性。
在本发明实施例中，当数据快照的版本信息是数据快照对应的数据分区中最近一次写入的多分区写事务的标识时，至少两个数据分区各自对应的数据快照之间满足一致性，可以是该至少两个数据分区各自对应的数据快照的版本信息相同；或者，该至少两个数据分区各自对应的数据快照之间满足一致性，也可以是对于该至少两个数据分区中的每一个数据分区，获取到的该数据分区的数据快照的版本信息与预存的该数据分区的版本信息相同。
比如，协调节点820根据版本信息检测数据分区1的数据快照与数据分区3的数据快照是否满足一致性的方式可以如下：
1)若数据分区1和数据分区3是同时进行多分区写入的两个数据分区(即一个多分区写事务涉及到数据分区1时，同时也必然涉及到数据分区3)，则协调节点820可以直接比对两个数据分区各自对应的版本信息是否相同，若是，则说明两个数据分区各自对应的数据快照满足一致性；若两个数据分区各自对应的版本信息不相同，则可以进一步根据版本信息确定低版本的数据分区(即对应最近完成的多分区写事务的id小的数据分区，其版本较低)。
2)若数据分区1和数据分区3不是同时进行多分区写入的两个数据分区(即一个多分区写事务涉及到数据分区1时，可能不会涉及到数据分区3)。在这种情况下，协调节点820可以维护各个数据分区各自对应的版本信息，当协调节点820在处理一个多分区写事务的过程中，向某一个参与节点发送提交指示后，即将自身维护的该多分区写事务涉及的数据分区的版本信息更新为该多分区写事务的id；相应的，每个参与节点也各自维护自己对应的数据分区的版本信息，在处理一个多分区写事务的过程中，当参与节点接收到协调节点820发送的提交指示后，在将当前写入完成的数据快照成功保存为对应的数据分区中的数据之后，将自身维护的该数据分区的版本信息更新为该多分区写事务的id。在后续处理一个多分区读事务时，参与节点获取到该多分区读事务涉及的数据分区的数据快照，并将该数据快照对应的版本信息发送给协调节点820后，协调节点820将参与节点发送的版本信息与自己维护的该数据分区对应的版本信息进行比对，若参与节点发送的该多分区读事务对应的各个数据快照的版本信息，与协调节点自身维护的对应数据分区中版本信息都相同，则说明获取到的该多分区读事务对应的各个数据分区的数据快照之间满足一致性。若参与节点发送的该多分区读事务对应的各个数据快照的版本信息中，有一个或者一个以上的版本信息与协调节点自身维护的对应数据分区中版本信息不同，则可以确定该一个或者一个以上的版本信息对应的数据快照的版本低。
若检测出数据分区1的数据快照与数据分区3的数据快照不满足一致性，则协调节点820根据版本信息确定版本低的数据快照对应的参与节点，并向确定的参与节点发送重新获取数据快照的请求，参与节点接收到重新获取数据快照的请求后，删除原来的数据快照，并重新获取数据快照，并将重新获取的数据快照中的数据的版本信息返回给协调节点820，协调节点820根据该重新获取的数据快照中的数据的版本信息，再次检测该数据分区1的数据快照与数据分区3的数据快照是否满足一致性。
若检测出数据分区1的数据快照与数据分区3的数据快照满足一致性，则协调节点820分别向参与节点811和参与节点812发送事务处理指示，指示参与节点811和参与节点812分别处理该多分区读请求。参与节点811和参与节点812接收到该事务处理指示后，即在获取到的数据快照中读取该多分区读请求对应的数据，并根据读取成功与否，向协调节点820发送读取成功响应或者读取失败响应。
协调节点820接收到参与节点811和参与节点812中的任一节点发送的读取失败响应后，即向另一参与节点发送删除快照请求，指示另一参与节点删除获取的数据快照。
协调节点820接收到参与节点811和参与节点812分别发送的读取成功响应后，即向参与节点811和参与节点812分别发送删除快照请求，指示两个参与节点删除获取的数据 快照。
图10是本申请一个示例性实施例提供的事务处理设备100的结构示意图，该事务处理设备100可以实现为图1所示的网络环境中的事务处理设备210。如图10所示，该事务处理设备100可以包括：处理器101以及通信接口104。
处理器101可以包括一个或者一个以上处理单元，该处理单元可以是中央处理单元(英文：central processing unit，CPU)或者网络处理器(英文：network processor，NP)等。
通信接口104可以包括网络接口。其中，该网络接口用于连接终端设备。具体的，该网络接口可以包括有线网络接口，比如以太网接口或者光纤接口，或者，网络接口也可以包括无线网络接口，比如无线局域网接口或者蜂窝移动网络接口。事务处理设备100通过该网络接口104与各个终端设备进行通信。
可选的，该事务处理设备100还可以包括存储器103，处理器101可以用总线与存储器103和通信接口104相连。
存储器103可用于存储软件程序，该软件程序可以由处理器101执行。此外，该存储器103中还可以存储各类业务数据或者用户数据。该软件程序可以包括事务接收模块、快照获取模块、执行模块以及更新模块等。
其中，事务接收模块由处理器101执行，以实现上述图3所示实施例中有关接收终端设备发送的多分区事务以及单分区事务的功能。
快照获取模块由处理器101执行，以实现上述图3所示实施例中有关获取满足一致性的数据快照的功能。
执行模块由处理器101执行，以实现上述图3所示实施例中有关执行读操作或者写操作的功能。
更新模块由处理器101执行，以实现上述图3所示实施例中有关更新数据分区对应的数据快照中的数据的版本信息的功能。
可选地，该事务处理设备100还可以包括输出设备105以及输入设备107。输出设备105和输入设备107与处理器101相连。输出设备105可以是用于显示信息的显示器、播放声音的功放设备或者打印机等，输出设备105还可以包括输出控制器，用以提供输出到显示屏、功放设备或者打印机。输入设备107可以是用于用户输入信息的诸如鼠标、键盘、电子触控笔或者触控面板之类的设备，输入设备107还可以包括输出控制器以用于接收和处理来自鼠标、键盘、电子触控笔或者触控面板等设备的输入。
下述为本申请的装置实施例，可以用于执行本申请的方法实施例。对于本申请的装置实施例中未披露的细节，请参照本申请的方法实施例。
图11是本申请一个示例性实施例提供的一种事务处理装置的结构方框图，该事务处理装置可以通过硬件电路或者软件硬件的结合实现成为事务处理设备的部分或者全部，该事务处理设备可以是上述图2A所示的实施例中的事务处理设备210。该事务处理装置可以包括：事务接收单元1101、快照获取单元1102、执行单元1103以及更新单元1104。
其中，事务接收单元1101由处理器81执行，以实现上述图3所示实施例中有关接收终端设备发送的多分区事务以及单分区事务的功能。
快照获取单元1102，用于实现上述图3所示实施例中有关获取满足一致性的数据快照的功能。
执行单元1103，用于实现上述图3所示实施例中有关执行读操作或者写操作的功能。
更新单元1104，用于实现上述图3所示实施例中有关更新数据分区对应的数据快照中的数据的版本信息的功能。
图12是本申请一个示例性实施例提供的一种事务处理系统的系统构成图。如图11所示，该事务处理系统可以包括：事务处理装置122以及至少两个数据分区124。
其中，事务处理装置122可以实现为上述图11所示的事务处理装置，该事务处理装置用于实现如图3所示实施例中的事务处理方法。
需要说明的是：上述实施例提供的事务处理装置在进行事务处理时，仅以上述各功能单元的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元完成，即将设备的内部结构划分成不同的功能单元，以完成以上描述的全部或者部分功能。另外，上述实施例提供的事务处理装置与事务处理方法的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
上述本申请的实施例序号仅仅为了描述，不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (26)

  1. 一种事务处理方法，其特征在于，所述方法包括：
    接收待处理事务，所述待处理事务是在至少两个数据分区中进行操作的事务；
    获取所述至少两个数据分区对应的，且满足一致性的数据快照；
    根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作。
  2. 根据权利要求1所述的方法，其特征在于，所述待处理事务是在所述至少两个数据分区中进行读操作的事务。
  3. 根据权利要求1或2所述的方法，其特征在于，所述获取所述至少两个数据分区对应的，且满足一致性的数据快照，包括：
    获取所述至少两个数据分区各自的数据快照，以及所述至少两个数据分区各自的数据快照的版本信息；
    根据所述至少两个数据分区各自的数据快照的版本信息，检测所述至少两个数据分区各自的数据快照是否满足一致性；
    若检测结果为所述至少两个数据分区各自的数据快照满足一致性，则确定成功获取到所述至少两个数据分区各自对应且满足一致性的数据快照。
  4. 根据权利要求3所述的方法，其特征在于，所述获取所述至少两个数据分区对应的，且满足一致性的数据快照，还包括：
    若检测结果为所述至少两个数据分区各自的数据快照不满足一致性，则重新获取版本低的数据分区的数据快照，以及重新获取到的数据快照的版本信息；
    根据重新获取到的数据快照的版本信息检测所述至少两个数据分区各自的数据快照是否满足一致性。
  5. 根据权利要求3或4所述的方法，其特征在于，所述方法还包括：
    若检测结果为所述至少两个数据分区各自的数据快照不一致，则删除已获取的版本低的数据分区的数据快照。
  6. 根据权利要求1至5任一所述的方法，其特征在于，
    所述数据快照的版本信息包含所述数据快照生成时，所述数据快照对应的数据分区中最近一次写入的多分区写事务的标识，所述多分区写事务是在至少两个数据分区中进行写操作的事务。
  7. 根据权利要求1所述的方法，其特征在于，所述待处理事务是在所述至少两个数据分区中进行写操作的事务，所述根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作，包括：
    在所述至少两个数据分区对应的，且满足一致性的数据快照中执行所述待处理事务对应的写操作；
    将执行所述待处理事务对应的写操作之后的数据快照保存为对应的数据分区中的数据。
  8. 根据权利要求1所述的方法，其特征在于，所述待处理事务是在所述至少两个数据分区中进行写操作的事务，所述方法还包括：
    在根据所述至少两个数据分区各自对应且满足一致性的数据快照执行所述待处理事务对应的写操作成功后，将所述待处理事务的标识更新为所述至少两个数据分区各自对应的版本信息。
  9. 一种事务处理装置，其特征在于，所述装置包括：
    事务接收单元，用于接收待处理事务，所述待处理事务是在至少两个数据分区中进行操作的事务；
    快照获取单元，用于获取所述至少两个数据分区对应的，且满足一致性的数据快照；
    执行单元，用于根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作。
  10. 根据权利要求9所述的装置，其特征在于，所述待处理事务是在所述至少两个数据分区中进行读操作的事务。
  11. 根据权利要求9或10所述的装置，其特征在于，所述快照获取单元，用于
    获取所述至少两个数据分区各自的数据快照，以及所述至少两个数据分区各自的数据快照的版本信息；
    根据所述至少两个数据分区各自的数据快照的版本信息，检测所述至少两个数据分区各自的数据快照是否满足一致性；
    若检测结果为所述至少两个数据分区各自的数据快照满足一致性，则确定成功获取到所述至少两个数据分区各自对应且满足一致性的数据快照。
  12. 根据权利要求11所述的装置，其特征在于，所述快照获取单元，还用于
    若检测结果为所述至少两个数据分区各自的数据快照不满足一致性，则重新获取对应版本低的数据分区的数据快照，以及重新获取到的数据快照的版本信息；
    根据重新获取到的数据快照的版本信息检测所述至少两个数据分区各自的数据快照是否满足一致性。
  13. 根据权利要求11或12所述的装置，其特征在于，所述快照获取单元，还用于
    若检测结果为所述至少两个数据分区各自的数据快照不一致，则删除已获取的版本低的数据分区的数据快照。
  14. 根据权利要求9至13任一所述的装置，其特征在于，
    所述数据快照的版本信息包含所述数据快照生成时，所述数据快照对应的数据分区中最近一次写入的多分区写事务的标识，所述多分区写事务是在至少两个数据分区中进行写操作的事务。
  15. 根据权利要求9所述的装置，其特征在于，所述待处理事务是在所述至少两个数据分区中进行写操作的事务，所述执行单元，具体用于
    在所述至少两个数据分区对应的，且满足一致性的数据快照中执行所述待处理事务对应的写操作；
    将执行所述待处理事务对应的写操作之后的数据快照保存为对应的数据分区中的数据。
  16. 根据权利要求9所述的装置，其特征在于，所述装置还包括：
    更新单元，用于当所述待处理事务是在所述至少两个数据分区中进行写操作的事务时，在对所述至少两个数据分区各自对应且满足一致性的数据快照执行所述待处理事务对应的写操作成功后，将所述待处理事务的标识更新为所述至少两个数据分区各自对应的版本信息。
  17. 一种事务处理设备，其特征在于，所述设备包括：通信接口、处理器和存储器；所述存储器中存储有所述处理器可执行的程序或指令，所述处理器控制所述通信接口，通过执行所述处理器中存储的程序或指令以实现权利要求1至8任一所述的事务处理方法。
  18. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有可执行程序，所述可执行程序由处理器执行以实现权利要求1至8任一所述的事务处理方法。
  19. 一种事务处理系统，其特征在于，所述系统包括事务处理装置和至少两个数据分区；
    所述事务处理装置，用于接收待处理事务，所述待处理事务是在所述至少两个数据分区中进行操作的事务，获取所述至少两个数据分区对应的，且满足一致性的数据快照，根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作。
  20. 根据权利要求19所述的系统，其特征在于，所述待处理事务是在所述至少两个数据分区中进行读操作的事务。
  21. 根据权利要求19或20所述的系统，其特征在于，在获取所述至少两个数据分区对应的，且满足一致性的数据快照时，所述事务处理装置，具体用于
    获取所述至少两个数据分区各自的数据快照，以及所述至少两个数据分区各自的数据快照的版本信息；
    根据所述至少两个数据分区各自的数据快照的版本信息，检测所述至少两个数据分区各自的数据快照是否满足一致性；
    若检测结果为所述至少两个数据分区各自的数据快照满足一致性，则确定成功获取到所述至少两个数据分区各自对应且满足一致性的数据快照。
  22. 根据权利要求21所述的系统，其特征在于，所述事务处理装置，还用于
    若检测结果为所述至少两个数据分区各自的数据快照不满足一致性，则重新获取对应版本低的数据分区的数据快照，以及重新获取到的数据快照的版本信息；
    根据重新获取到的数据快照的版本信息检测所述至少两个数据分区各自的数据快照是否满足一致性。
  23. 根据权利要求21或22所述的系统，其特征在于，所述事务处理装置，还用于
    若检测结果为所述至少两个数据分区各自的数据快照不一致，则删除已获取的版本低的数据分区的数据快照。
  24. 根据权利要求19至23任一所述的系统，其特征在于，
    所述数据快照的版本信息包含所述数据快照生成时，所述数据快照对应的数据分区中最近一次写入的多分区写事务的标识，所述多分区写事务是在至少两个数据分区中进行写操作的事务。
  25. 根据权利要求19所述的系统，其特征在于，所述待处理事务是在所述至少两个数据分区中进行写操作的事务，在根据所述至少两个数据分区对应的，且满足一致性的数据快照执行所述待处理事务对应的操作时，所述事务处理装置，具体用于
    在所述至少两个数据分区对应的，且满足一致性的数据快照中执行所述待处理事务对应的写操作；将执行所述待处理事务对应的写操作之后的数据快照保存为对应的数据分区中的数据。
  26. 根据权利要求19所述的系统，其特征在于，所述事务处理装置，还用于
    当所述待处理事务是在所述至少两个数据分区中进行写操作的事务时，在根据所述至少两个数据分区各自对应且满足一致性的数据快照执行所述待处理事务对应的写操作成功后，将所述待处理事务的标识更新为所述至少两个数据分区各自对应的版本信息。
PCT/CN2017/087194 2017-06-05 2017-06-05 一种事务处理方法、装置及设备 WO2018223262A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN201780002963.7A CN110168514B (zh) 2017-06-05 2017-06-05 一种事务处理方法、装置及设备
JP2020517246A JP6924898B2 (ja) 2017-06-05 2017-06-05 トランザクション処理方法、装置及びデバイス
EP17912603.2A EP3627359B1 (en) 2017-06-05 2017-06-05 Transaction processing method, device and equipment
PCT/CN2017/087194 WO2018223262A1 (zh) 2017-06-05 2017-06-05 一种事务处理方法、装置及设备
KR1020197036437A KR102353141B1 (ko) 2017-06-05 2017-06-05 트랜잭션 처리 방법, 디바이스 및 장비
US16/703,362 US20200110739A1 (en) 2017-06-05 2019-12-04 Transaction processing method, apparatus, and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/087194 WO2018223262A1 (zh) 2017-06-05 2017-06-05 一种事务处理方法、装置及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/703,362 Continuation US20200110739A1 (en) 2017-06-05 2019-12-04 Transaction processing method, apparatus, and device

Publications (1)

Publication Number Publication Date
WO2018223262A1 true WO2018223262A1 (zh) 2018-12-13

Family

ID=64565652

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/087194 WO2018223262A1 (zh) 2017-06-05 2017-06-05 一种事务处理方法、装置及设备

Country Status (6)

Country Link
US (1) US20200110739A1 (zh)
EP (1) EP3627359B1 (zh)
JP (1) JP6924898B2 (zh)
KR (1) KR102353141B1 (zh)
CN (1) CN110168514B (zh)
WO (1) WO2018223262A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111475262B (zh) * 2020-04-02 2024-02-06 百度国际科技（深圳）有限公司 区块链中事务请求处理方法、装置、设备和介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103116596A (zh) * 2011-11-16 2013-05-22 Sap股份公司 在分布式数据库中执行快照隔离的系统和方法
WO2015039569A1 (zh) * 2013-09-22 2015-03-26 华为技术有限公司 副本存储装置及副本存储方法
CN106598992A (zh) * 2015-10-15 2017-04-26 中兴通讯股份有限公司 数据库的操作方法及装置
CN106610876A (zh) * 2015-10-23 2017-05-03 中兴通讯股份有限公司 数据快照的恢复方法及装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5287496A (en) * 1991-02-25 1994-02-15 International Business Machines Corporation Dynamic, finite versioning for concurrent transaction and query processing
AU6104800A (en) * 1999-07-16 2001-02-05 Intertrust Technologies Corp. Trusted storage systems and methods
US7334004B2 (en) * 2001-06-01 2008-02-19 Oracle International Corporation Consistent read in a distributed database environment
US8949220B2 (en) * 2003-12-19 2015-02-03 Oracle International Corporation Techniques for managing XML data associated with multiple execution units
US8375290B1 (en) * 2004-02-25 2013-02-12 Avaya Inc. Document version marking and access method and apparatus
US7653665B1 (en) 2004-09-13 2010-01-26 Microsoft Corporation Systems and methods for avoiding database anomalies when maintaining constraints and indexes in presence of snapshot isolation
US8713046B2 (en) 2011-11-08 2014-04-29 Sybase, Inc. Snapshot isolation support for distributed query processing in a shared disk database cluster
CN102819615A (zh) * 2012-08-30 2012-12-12 天津火星科技有限公司 一种基于应用快照的数据库持续数据保护方法
US9098522B2 (en) 2012-11-29 2015-08-04 Sap Se Version garbage collection using snapshot lists
US9411533B2 (en) * 2013-05-23 2016-08-09 Netapp, Inc. Snapshots and versioning of transactional storage class memory
US9632878B1 (en) * 2013-09-20 2017-04-25 Amazon Technologies, Inc. Verification of database table partitions during backup
US9779128B2 (en) * 2014-04-10 2017-10-03 Futurewei Technologies, Inc. System and method for massively parallel processing database
US9990224B2 (en) * 2015-02-23 2018-06-05 International Business Machines Corporation Relaxing transaction serializability with statement-based data replication
US20170139980A1 (en) * 2015-11-17 2017-05-18 Microsoft Technology Licensing, Llc Multi-version removal manager

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103116596A (zh) * 2011-11-16 2013-05-22 Sap股份公司 在分布式数据库中执行快照隔离的系统和方法
WO2015039569A1 (zh) * 2013-09-22 2015-03-26 华为技术有限公司 副本存储装置及副本存储方法
CN106598992A (zh) * 2015-10-15 2017-04-26 中兴通讯股份有限公司 数据库的操作方法及装置
CN106610876A (zh) * 2015-10-23 2017-05-03 中兴通讯股份有限公司 数据快照的恢复方法及装置

Also Published As

Publication number Publication date
CN110168514B (zh) 2022-06-10
EP3627359A1 (en) 2020-03-25
US20200110739A1 (en) 2020-04-09
CN110168514A (zh) 2019-08-23
EP3627359B1 (en) 2023-10-04
KR20200006098A (ko) 2020-01-17
JP6924898B2 (ja) 2021-08-25
EP3627359A4 (en) 2020-04-22
JP2020522830A (ja) 2020-07-30
KR102353141B1 (ko) 2022-01-19

Similar Documents

Publication Publication Date Title
CN109144994B (zh) 索引更新方法、系统及相关装置
US11003689B2 (en) Distributed database transaction protocol
US20200387443A1 (en) Systems and methods for testing source code
US11829349B2 (en) Direct-connect functionality in a distributed database grid
US10936578B2 (en) Client-driven commit of distributed write transactions in a database environment
US10296371B2 (en) Passive two-phase commit system for high-performance distributed transaction execution
US9529881B2 (en) Difference determination in a database environment
US8713046B2 (en) Snapshot isolation support for distributed query processing in a shared disk database cluster
CN110196856B (zh) 一种分布式数据读取方法及装置
US11263236B2 (en) Real-time cross-system database replication for hybrid-cloud elastic scaling and high-performance data virtualization
WO2018107772A1 (zh) 写入请求处理方法、装置及设备
US10152500B2 (en) Read mostly instances
US10747777B2 (en) Computer system and transaction processing management method
US20220229822A1 (en) Data processing method and device for distributed database, storage medium, and electronic device
US9703634B2 (en) Data recovery for a compute node in a heterogeneous database system
WO2022111188A1 (zh) 事务处理方法、系统、装置、设备、存储介质及程序产品
Chairunnanda et al. ConfluxDB: Multi-master replication for partitioned snapshot isolation databases
US20170212939A1 (en) Method and mechanism for efficient re-distribution of in-memory columnar units in a clustered rdbms on topology change
CN113157411B (zh) 一种基于Celery的可靠可配置任务系统及装置
WO2018223262A1 (zh) 一种事务处理方法、装置及设备
CN113886403A (zh) 一种针对高竞争电商业务的数据管理系统及事务处理方法
US20190384695A1 (en) Happens-before-based dynamic concurrency analysis for actor-based programs
JP2016194826A (ja) データベースの処理制御方法、処理制御プロラム及びデータベースサーバ
US11593030B2 (en) Cross-stream transactions in a streaming data storage system
WO2022132333A1 (en) Schema and data modification concurrency in query processing pushdown

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: 17912603

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020517246

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20197036437

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2017912603

Country of ref document: EP

Effective date: 20191219