CN111209093B - Processing method of distributed transaction in distributed database system - Google Patents
Processing method of distributed transaction in distributed database system Download PDFInfo
- Publication number
- CN111209093B CN111209093B CN202010046437.4A CN202010046437A CN111209093B CN 111209093 B CN111209093 B CN 111209093B CN 202010046437 A CN202010046437 A CN 202010046437A CN 111209093 B CN111209093 B CN 111209093B
- Authority
- CN
- China
- Prior art keywords
- transaction
- write
- current
- read
- abort
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a processing method of distributed transactions in a distributed database system, which is based on the analysis of the prior strict two-stage locking protocol and two-stage committing protocol and aims to overcome the influence of overlong lock holding time in the execution process of the distributed transactions. The invention effectively shortens the time of holding the lock by the distributed transaction, reduces the conflict rate among the transactions and improves the transaction processing performance.
Description
Technical Field
The invention relates to the technical field of databases, in particular to a processing method of distributed transactions in a distributed database system.
Background
With the increasing scale of business, it has been difficult for centralized database systems to scale to meet the performance requirements of business transactions. The distributed database system is a database system constructed on a distributed cluster, and can realize the expansion of transaction processing performance in a mode of dividing data into a plurality of nodes. When a transaction involves multiple nodes, it becomes a distributed transaction. To ensure atomicity, consistency, isolation, and persistence (ACID) of distributed transactions, a distributed database system needs to perform necessary synchronization between nodes through multiple network interactions. However, the transmission speed of data in the network at present is different from the local processing speed by more than ten times, which becomes a main reason for overhigh time delay of distributed transactions.
In the prior art, to ensure the correctness of the distributed transaction execution, Strict Two-Phase Locking (S2 PL) and Two-Phase Commit (2 PC) protocols are usually adopted. The execution flow of the strict two-phase lockout protocol: in the growth phase, a transaction may acquire a lock but cannot release the lock; during the shrink phase, the transaction may release the lock, but may not acquire the new lock, and may not release the write lock until the transaction commits or aborts; the execution flow of the two-phase submission protocol: in the preparation phase, the transaction manager node requests each resource manager to continuously vote whether to submit the transaction, and the resource manager node must respond; in the execution stage, the transaction manager node sends a final resolution whether the transaction is submitted or not to each resource manager node according to the voting result, and the resource manager node executes the resolution and returns confirmation information.
In the prior art, the following defects exist: the execution of the two-phase commit protocol requires multiple time-consuming network interactions during which the lock is continuously held by the transactions, which increases the probability of collisions between transactions and reduces the throughput of transactions, particularly under high-collision loads, which is particularly significant; in order to improve fault tolerance, a distributed database usually maintains multiple copies for data, and synchronization between copies further prolongs the holding time of the lock, and the performance of transaction processing is seriously degraded.
Disclosure of Invention
The invention aims to provide a distributed transaction processing method in a distributed database system for overcoming the influence of overlong lock holding time in the execution process of distributed transactions.
The specific technical scheme for realizing the purpose of the invention is as follows:
a processing method of distributed transaction in distributed database system includes the following steps:
step 1: transactional data access
Locking a record in a read/write lock mode, checking whether a transaction which updates the record newly is committed or aborted, if the transaction is committed or aborted, continuing to execute the transaction, and if the transaction is not committed or aborted, adding the transaction to an output dependency set of the current transaction, and adding one to an input dependency number of the current transaction;
step 2: transaction preparation
The transaction locks records in a write set and a read set of the transaction in an early write/early read mode, checks whether the input dependency number of the current transaction is zero or the state is an abort, continues to execute the current transaction if the current transaction is zero or the state is an abort, and blocks the current transaction if the current transaction is not zero or the state is an abort;
checking whether the current transaction is in an abort state or violates isolation, if the current transaction is in the abort state or violates isolation, replying a message that the transaction manager objections to commit, and if the current transaction is not in the abort state and does not violate isolation, unlocking records in a write set and a read set of the current transaction and replying the message that the transaction manager agrees to commit;
and 3, step 3: transaction commit
Checking whether the current transaction can be submitted, if so, executing the transaction submission, reducing the input dependency number of all output dependency transactions of the current transaction by one, setting the state of the current transaction as submitted, and replying a message for confirming the submission by the transaction manager;
and 4, step 4: transaction rollback
And if the current transaction can not be submitted, executing transaction rollback, locking the records in the current transaction write set in an abort lock mode, rolling back the output dependent transaction of the current transaction, then rolling back the current transaction, unlocking the records in the current transaction write set, setting the current transaction state as abort, and replying a message for confirming the abort by the transaction manager.
The lock mode comprises Read, Write, E-Read, E-Write and Abort, and is compatible with any lock mode when the lock mode is the E-Write/E-Read lock mode; when the current mode is any locking mode, the method is compatible with an Abort locking mode; currently in the Abort lock mode, it is incompatible with the Read and Write lock modes.
The invention has the beneficial effects that:
according to the processing method for the distributed transactions in the distributed database system, the lock resources are released in advance in the two-phase commit protocol preparation phase, so that the holding time of the lock is effectively shortened, the conflict rate among the transactions is reduced, and the performance of the distributed transactions is improved; the order of the submission and rollback of the transaction is determined by maintaining the input dependency information and the output dependency information of the transaction, so that the occurrence of abnormity is avoided, and the correctness is ensured. The technical scheme of the invention is easy to realize in engineering and can be quickly applied to the existing system.
Drawings
FIG. 1 is a flowchart of example 1 of the present invention;
FIG. 2 is a diagram illustrating transaction data access according to embodiment 2 of the present invention;
FIG. 3 is a schematic diagram of transaction preparation according to embodiment 2 of the present invention;
FIG. 4 is a schematic diagram of transaction commit involved in embodiment 2 of the present invention;
fig. 5 is a schematic diagram of transaction rollback according to embodiment 2 of the present invention.
Detailed Description
The present invention will be described in further detail with reference to the following specific examples and the accompanying drawings. The procedures, conditions, experimental methods and the like for carrying out the present invention are general knowledge and common general knowledge in the art except for the contents specifically mentioned below, and the present invention is not particularly limited.
Example 1
Referring to fig. 1, the present embodiment includes lock modes, data access, transaction preparation, transaction commit and transaction rollback, wherein the lock modes are used to implement data protection during transaction data access, early release lock and transaction rollback, and include five types, namely Read (Read), Write (Write), Read-ahead (E-Read), Write-ahead (E-Write) and Abort (Abort), and are compatible with any lock mode when the lock mode is currently the E-Write/E-Read lock mode, compatible with the Abort (Abort) lock when the lock mode is currently any lock mode, and incompatible with the Read lock and the Write lock when the lock mode is currently the Abort lock mode.
Wherein the data access step comprises the steps of:
step A1: the transaction locks record X in read/write mode;
step A2: the transaction finds out the In _ xact context of the transaction which updates the record X recently through the utid on the record X, judges whether the state is COMMITTED/ABORTED, and if yes, the process is ended;
step A3: adding the record X into a read record set rs/write record set ws of the transaction, judging whether the transaction exists In an output dependent set (outDepSet) of the transaction In _ xact, and if yes, ending the process;
step A4: adding the transaction to the output dependent set outpset of the transaction In _ xact, adding 1 to the input dependent transaction number (inDepCount) of the transaction, and ending the flow.
Wherein the transaction preparation step comprises the steps of:
step B1: setting the state of the transaction to PREPARING;
step B2: updating the latest update transaction identification number (utid) recorded in the transaction write set into the identification number (id) of the transaction;
step B3: E-Write/E-Read locks are added to records in a transaction Write set and a transaction Read set;
step B4: judging that the number of input dependent transactions of the transactions is not equal to 0 and the input dependent transactions are not cascaded for rollback, if yes, blocking the transactions, and if not, continuing to execute the subsequent steps;
step B5: judging whether the state of the transaction is ABORTED or violates the isolation, and if not, jumping to the step B7;
step B6: replying VOTE _ NO to the transaction manager, and ending the process;
step B7: unlocking records in the transaction write set and the transaction read set;
step B8: replying VOTE _ YES to the transaction manager, and setting the state of the transaction to PREPARED; the flow ends.
Wherein the transaction committing step comprises the steps of:
step C1: releasing all held locks, reducing the inDepCount of all output dependent transactions of the transactions by 1, and if the inDepCount of a certain output dependent transaction is 0, awakening the output dependent transaction;
step C2: setting the state of the transaction to COMMITTED;
step C3: and sending ACK _ COMMITTED to the transaction manager, and ending the process.
Wherein the transaction rollback step comprises the steps of:
step D1: adding an Abort lock to a record in a transaction write set ws, and setting an utid as an invalid transaction id;
step D2: awakening all output dependent transactions of the transaction, and recursively executing a transaction rollback step on the output dependent transactions;
step D3: performing Undo operation to recover data;
step D4: unlocking the records in the transaction write set ws;
step D5: the state of the transaction is set to ABORTED and the process ends.
Example 2
The lock modes used in the present embodiment include five lock modes of Read (Read), Write (Write), Read-ahead (E-Read), Write-ahead (E-Write), and Abort (Abort). It should be noted here that: when the current mode is the E-Write/E-Read lock mode, the method is compatible with any lock mode, and the effect is equivalent to no lock; when the current mode is any lock mode, the method is compatible with an Abort (Abort) lock; currently in Abort lock mode, are incompatible with read locks and write locks. The phase-locked capacitive matrix is shown below.
TABLE 1
The dependency relationship in this embodiment is defined as follows: assuming there are two transactions A and B, if transaction A accesses data written to transaction B, then transaction B is said to be an input dependency of transaction A, and transaction A is said to be an output dependency of transaction B.
To implement commit dependencies, for each transaction T, the following information is maintained in the context of the transaction: a read tuple set ws and a write tuple set rs of the transaction; a transaction id; the input dependency number of the current transaction, inDepCount; transaction set, outDepSet, dependent on the current transaction; a transaction state; a condition variable condition for controlling the critical condition. Meanwhile, on each tuple, the transaction utid of the corresponding latest update tuple needs to be recorded.
FIG. 2 depicts an example of a transaction accessing a tuple. In this example, transaction a writes a tuple with id 1 in data table T, updates the field name content from cc to aa, and is ready, and at the same time, transaction B writes this tuple, it locks this tuple with Write (Write), updates the name field content of this tuple to bb, then finds the context of transaction a according to the utid saved on this tuple, determines its transaction state, and adds this tuple to the Write record set ws of transaction B if this transaction has not been committed and has not rolled back. If transaction B does not have the output dependency set outDepSet for transaction A, and the input dependency number InDepCount for transaction B is incremented by 1.
FIG. 3 depicts an example of transaction preparation. In this example, transaction B, upon receiving the Prepare message, sets the transaction state to PREPARING. For all Write sets, the corresponding utid on each tuple is updated and the lock on the tuple is changed from a Write (Write) lock to an early released Write lock (E-Write). Transaction B then blocks waiting until the number of input dependencies inDepCount of commit dependencies is 0, or the transaction is cascaded back. After wakeup, the transaction manager sends transaction B response to the Prepare message, i.e. VOTE _ YES, setting the transaction status to PREPARED.
The following two examples illustrate the case of transaction commit and transaction rollback, respectively:
FIG. 4 depicts an example of a transaction commit. In this example, transaction A performs a Commit operation, releasing all held locks after the resource manager receives the Commit message. And the transaction A traverses the output dependent set (outDepSet), the number (InDepCount) of the input dependent transactions of the transaction B in the output dependent set (outDepSet) is reduced by 1, and the input dependent number of the transaction B is 0, so that the transaction B is awakened to finish the blocking waiting of the transaction B. At this point transaction a commits, changes the transaction state to COMMITTED, and sends an acknowledgement message to the transaction manager.
FIG. 5 depicts an example of transaction rollback. In this example, transaction A performs a rollback operation, updating the lock state of each tuple in write tuple set ws to Abort, and updating utid on the tuple to an invalid value. Thus, as can be seen from table 1, subsequent read and write operations to this tuple are blocked. For the output dependent transaction B of the transaction A, the rollback operation is recursively called, that is, all output dependent transactions are rolled back and then the transaction is rolled back again. Transaction B restores the tuple name field content to aa before updating, the update state is ABORTED after all locks are removed, then transaction A restores the tuple name field content to cc, and the data returns to the initial state. Transaction A then removes all locks, and transaction A updates the state to ABORTED.
The protection content of the present invention is not limited to the above embodiments. Variations and advantages that may occur to those skilled in the art are intended to be included within the invention without departing from the spirit and scope of the inventive concept, and the scope of the invention is to be determined by the appended claims.
Claims (2)
1. A processing method of distributed transaction in distributed database system is characterized in that the method comprises the following steps:
step 1: transactional data access
Locking the record in a read/write lock mode, checking whether a transaction B which updates the record newly is submitted or aborted, if the transaction B is submitted or aborted, continuing to execute the current transaction A, if the transaction B is not submitted or aborted, adding the current transaction A to an output dependency set of the transaction B, and adding one to an input dependency number of the current transaction A;
step 2: transaction preparation
Locking records in a write set and a read set of the current transaction in a write-ahead/read-ahead mode, judging that the input dependence number of the current transaction is not equal to zero and is not cascaded for rolling back, if the input dependence number is equal to zero, blocking the current transaction, and if the input dependence number is not equal to zero, continuing to execute the following steps: checking whether the current transaction is in an abort state or violates isolation, if the current transaction is in the abort state or violates isolation, replying a message that the transaction manager objections to commit, and if the current transaction is not in the abort state and does not violate isolation, unlocking records in a write set and a read set of the current transaction and replying the message that the transaction manager agrees to commit;
and step 3: transaction commit
Checking whether the current transaction can be submitted, if so, executing the transaction submission, reducing the input dependency number of all output dependency transactions of the current transaction by one, setting the state of the current transaction as submitted, and replying a message confirmed by the transaction manager to be submitted;
and 4, step 4: transaction rollback
And if the current transaction can not be submitted, executing transaction rollback, locking the records in the current transaction write set in an abort lock mode, rolling back the output dependent transaction of the current transaction, then rolling back the current transaction, unlocking the records in the current transaction write set, setting the current transaction state as abort, and replying a message for confirming the abort by the transaction manager.
2. The method of distributed transaction processing of claim 1 wherein the lock modes include Read-as-Read, Write-as-Write, Read-ahead, E-Read, Write-ahead, E-Write, and Abort, and when current is E-Write/E-Read lock mode, is compatible with any lock mode; when the current mode is any locking mode, the method is compatible with an Abort locking mode; currently in Abort lock mode, it is incompatible with Read and Write lock modes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010046437.4A CN111209093B (en) | 2020-01-16 | 2020-01-16 | Processing method of distributed transaction in distributed database system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010046437.4A CN111209093B (en) | 2020-01-16 | 2020-01-16 | Processing method of distributed transaction in distributed database system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111209093A CN111209093A (en) | 2020-05-29 |
| CN111209093B true CN111209093B (en) | 2022-07-22 |
Family
ID=70789749
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010046437.4A Active CN111209093B (en) | 2020-01-16 | 2020-01-16 | Processing method of distributed transaction in distributed database system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111209093B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111736964B (en) * | 2020-07-02 | 2021-08-06 | 腾讯科技（深圳）有限公司 | Transaction processing method and device, computer equipment and storage medium |
| US20220311595A1 (en) * | 2021-03-24 | 2022-09-29 | International Business Machines Corporation | Reducing transaction aborts in execute-order-validate blockchain models |
| CN115098228B (en) * | 2021-05-19 | 2023-04-14 | 腾讯科技（深圳）有限公司 | Transaction processing method and device, computer equipment and storage medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5752026A (en) * | 1994-04-28 | 1998-05-12 | The United States Of America As Represented By The Secretary Of The Navy | Early commit locking computer database protocol |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9396227B2 (en) * | 2012-03-29 | 2016-07-19 | Hewlett Packard Enterprise Development Lp | Controlled lock violation for data transactions |
-
2020
- 2020-01-16 CN CN202010046437.4A patent/CN111209093B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5752026A (en) * | 1994-04-28 | 1998-05-12 | The United States Of America As Represented By The Secretary Of The Navy | Early commit locking computer database protocol |
Non-Patent Citations (2)
| Title |
|---|
| 内存数据库事务提交的关键技术与挑战;胡爽等;《华东师范大学学报(自然科学版)》;20161231;全文 * |
| 新型OLTP系统的技术与实践;贺小龙等;《华东师范大学学报(自然科学版)》;20180925;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111209093A (en) | 2020-05-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111209093B (en) | Processing method of distributed transaction in distributed database system | |
| EP3117348B1 (en) | Systems and methods to optimize multi-version support in indexes | |
| EP3278239B1 (en) | Processing database transactions in a distributed computing system | |
| US7702741B2 (en) | Configuring or reconfiguring a multi-master information sharing environment | |
| US6978396B2 (en) | Method and system for processing replicated transactions parallel in secondary server | |
| JP4833590B2 (en) | Concurrent transactions (CONCURRENT TRANSACTIONS) and page synchronization (PAGESYNCHRONIZATION) | |
| US6823347B2 (en) | Propagating commit times | |
| US7490115B2 (en) | Commitment chains for conflict resolution between disconnected data sharing applications | |
| US7996363B2 (en) | Real-time apply mechanism in standby database environments | |
| CN113396407A (en) | System and method for augmenting database applications using blockchain techniques | |
| US9189502B2 (en) | Techniques for moving data files without interrupting access | |
| CN110716936B (en) | Database optimistic lock implementation method and system based on SpringBoot + JPA | |
| JP3052908B2 (en) | Transaction program parallel execution method and transaction program parallel execution method | |
| CN109947742B (en) | Multi-version database concurrency control method and system for two-stage lock | |
| EP4276651A1 (en) | Log execution method and apparatus, and computer device and storage medium | |
| JP2023509035A (en) | Transaction processing method, apparatus, computer device and computer program | |
| WO2022134876A1 (en) | Data synchronization method and apparatus, and electronic device and storage medium | |
| CN105786595A (en) | Transaction control method achieving two-stage submitting | |
| Mullen et al. | On the impossibility of atomic commitment in multidatabase systems | |
| US7051051B1 (en) | Recovering from failed operations in a database system | |
| WO2023124242A1 (en) | Transaction execution method and apparatus, device, and storage medium | |
| WO2001013202A2 (en) | Concurrent commit lock | |
| Bhargava et al. | An experimental analysis of replicated copy control during site failure and recovery | |
| CN109358817B (en) | Method, device and system for copying data | |
| US10459810B2 (en) | Technique for higher availability in a multi-node system using replicated lock information to determine a set of data blocks for recovery |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |