CN101706811B - Transaction commit method of distributed database system - Google Patents

Abstract

The invention discloses a transaction submission method of a distributed database system, which belongs to the technical field of computer networks. The method is as follows: 1) Allocate a cache area in the memory of the participant node and the coordinator node to cache the transaction log; 2) The coordinator node determines the participant node according to the transaction content and establishes a connection with it, and at the same time determines the Operation request information; 3) The coordinator node sends a single-step operation request message of the transaction to the participant node, and records the transaction request log of each operation request at the same time; 4) The participant node processes the local log according to the completion of each operation request, And send a corresponding message to the coordinator node; 5) The coordinator node judges whether the transaction is completed according to the received messages sent by all the participant nodes, and gives a final decision if it is completed. Compared with the prior art, the invention greatly reduces the number of log operations, improves system efficiency and transaction efficiency, and has extremely high availability.

Description

A Distributed Database System Transaction Submission Method

technical field

The invention relates to a method for submitting a transaction in a database system, in particular to a method for submitting a transaction in a distributed database system, and belongs to the technical field of computer networks.

Background technique

A distributed system is a multi-node system where data is stored in various databases. A node may be any data processing system, such as a computer system, and may be located at one site or distributed across multiple sites, connected to each other by a network such as a local or wide area network. Examples of distributed systems include database systems, mail server systems, and the like.

Since a transaction may modify the data of multiple nodes in the distributed system, in order to meet the data consistency of the distributed system, regardless of whether there is a failure (such as power supply interruption, hardware conflict, etc.), the following conditions must be met: the transaction is atomic , that is, the transaction either successfully executes all requests, or none of the requests are executed.

Distributed systems often utilize a two-phase commit (2PC) protocol to maintain data consistency. In the 2PC system, the coordinator node of each transaction, that is, the node where the client (such as an application) submits the transaction, identifies the resource corresponding to the request in the distributed system for each request in the transaction, and the node responsible for processing the request . Each node that holds the resource corresponding to the request and is assigned to process the request in the transaction is called a participant node. This step determines the transaction participant nodes and establishes the connection from the coordinator node to the participant nodes to prepare for the transaction.

Each participant node in the two-phase commit protocol votes to commit or roll back the transaction and sends its vote to the coordinator node. The coordinator node then makes the final decision to commit or roll back the transaction based on the votes from each participant node. If all participant nodes agree to commit, a log record is written to indicate the result and all participant nodes are notified to commit the transaction. If one or more participant nodes think that they cannot submit, they will write log records to indicate the result and notify all participant nodes that approve the submission to roll back the transaction.

Once the participant node votes to agree to submit, it must wait for the final decision of the coordinator before proceeding to the next step. If a participant's vote cannot be submitted, it can be rolled back by itself.

After the participant node executes the transaction commit or rollback, it needs to reply the transaction end message to the coordinator node. After the coordinator node receives the feedback message from all participant nodes, it records the transaction end log, and the transaction officially ends.

The two-phase commit protocol has the following disadvantages:

1) The log write operation of the two-phase commit protocol is frequent. In order to ensure the atomicity of the transaction and the recoverability of the system, during the execution of the two-phase commit protocol, the write operation of the log must be enforced. In a 2PC system consisting of n participant nodes and 1 coordinator node, to execute a two-phase commit protocol, 2n+1 mandatory log operations are required.

2) The two-phase commit protocol is not message-efficient. In a 2PC system composed of n participant nodes and 1 coordinator node, a two-phase commit protocol is executed once, and the number of messages transmitted is 4n.

3) The efficient execution of the two-phase commit protocol depends on the smooth flow of the entire network including the coordinator and all participant nodes. In a congested network environment, any participant node that votes to commit must wait for the final decision of the coordinator to complete the operation and release the held resources. During this time, any operations that request resources held by participants are queued. Moreover, the coordinator node cannot think that the transaction has ended without getting the reply message of the end of the transaction from the participant node, but must hold the transaction record and cannot "forget" (release the memory).

The current technology is mainly to seek a message efficient solution or a solution to reduce log operations, or to optimize only for the characteristics of a certain type of transaction, which cannot fully realize the efficient processing of transaction submission in a distributed system. Some commit techniques are more efficient distributed transaction commit methods.

Contents of the invention

Aiming at the problem of low transaction submission efficiency in the current distributed system, the purpose of the present invention is to provide a distributed database system transaction submission method, which can ensure less information transmission and mandatory The number of log operations.

Technical scheme of the present invention is:

A distributed database system transaction submission method, the steps of which are:

1) Allocate a cache area in the memory of the participant node and the coordinator node to cache the transaction log;

2) The coordinator node determines the participant node according to the transaction content and establishes a connection with it, and at the same time determines the operation request information of the transaction;

3) The coordinator node sends the single-step operation request message of the transaction to the participant node, and records the transaction request log of each operation request at the same time;

4) The participant node processes the local log according to the completion of each operation request, and sends a corresponding message to the coordinator node;

5) The coordinator node judges according to the received messages sent by all participant nodes:

a) If the transaction needs to be rolled back, the coordinator node caches the local transaction log, and sends a transaction rollback message to the participant node whose operation request of the transaction in the return message is completed successfully; then the participant node executes the received transaction rollback message and cache the transaction log;

b) If the transaction can be submitted, the coordinator node caches the local transaction log and sends a commit message to all participant nodes of the transaction; then the participant node executes the received commit message and caches the transaction log;

c) If all participant nodes return the operation request of the transaction in the message as successful, and the transaction has not been completed, repeat steps 3) to 5).

Further, the operation request information of the transaction includes: each operation request of the transaction, and the total number n of operation requests of the transaction.

Further, the coordinator node determines whether there is a cached transaction log in the current coordinator node at the beginning of each transaction, and if so, writes it to the disk at one time; if the cache area of the participant node is full or the cache When the set time is exceeded or a forced write to the cached transaction log occurs, the cached transaction log will be written to disk at one time.

Further, the operation request message of the transaction includes: transaction ID, coordinator ID, all participant IDs involved in this operation request, transaction single-step request content, i, coordinator local time stamp; The message includes: coordinator ID, coordinator transaction ID, local participant ID, i, vote, the latest timestamp sent by the coordinator node; the local log of the participant node includes: local transaction ID, coordinator ID, coordination Transaction ID of the server, IDs of all participants involved in this operation request, transaction single-step request content, vote, and the latest timestamp sent by the coordinator node; where i is the i-th step operation request of this transaction, and vote is the transaction operation request of this transaction Completion.

Further, the method for the coordinator node to record the transaction request log of each operation request is: if the operation request of the transaction is an operation request of a new transaction, the transaction start log of the new transaction is forced to be written to the disk; If the operation request is the i-th step request of the current transaction, the current log is cached.

Further, the transaction start log includes: transaction ID, coordinator ID, IDs of all participants involved in all operations of the transaction, the request content of the first step of the transaction, the start flag of this transaction, and the local time stamp of the coordinator; the transaction The log requested in step i of the transaction includes: transaction ID, coordinator ID, IDs of all participants involved in the operation of step i of the transaction, request content of step i of the transaction, i, and the local time stamp of the coordinator, where i>1.

Further, the method for the participant node to process the local log and send a corresponding message to the coordinator node is: if the participant node fails to complete the transaction operation request, it needs to cache the transaction log and return the information to the coordinator node And roll back the transaction; if the operation request of the participant node to the transaction is successful, it only needs to cache the transaction log, return the information to the coordinator node and wait for the coordinator node to send the operation request message of the transaction.

Further, in step 5), if one or more participant nodes do not return a message within the set time or the operation request of the transaction in the return message is completed as a failure, the coordinator node judges that the transaction needs to be rolled back ; If the operation requests of the transaction in the message returned by all participant nodes are completed successfully, and the number of operation requests of the transaction in the message returned by the participant node is equal to the total number of operation requests of this transaction, the coordinator node judges that the transaction can be submitted.

Further, in the step 5), the transaction rollback message includes: transaction ID, coordinator ID, participant ID, transaction rollback decision, transaction end flag, coordinator local timestamp; the transaction commit message includes : transaction ID, coordinator ID, participant ID, transaction commit decision, transaction end flag, coordinator local timestamp; the local transaction log cached by the coordinator node includes: transaction ID, coordinator ID, participant ID, transaction final decision , transaction end flag, coordinator local timestamp; the transaction log cached by the participant node includes: local transaction ID, coordinator ID, coordinator transaction ID, participant ID, transaction end flag, transaction final decision, coordinator node sent The latest timestamp; the final decision of the transaction is a transaction rollback decision or a transaction commit decision.

Further, if all participant nodes do not receive the rollback message or commit message sent by the coordinator node within the set time, the participant nodes will first query each other according to the received list of participants performing the same transaction steps:

a) If the operation request of any participant fails, all transaction participants execute the transaction rollback message;

b) If the operation requests of all participants are completed successfully, the participant node continues to wait for the message sent by the coordinator node;

c) If a participant node receives a rollback message or a commit message, the rest of the participants refer to it;

d) If a participant node cannot be contacted within a limited time and cannot determine whether the transaction can be rolled back, continue to wait.

Further, if the coordinator node fails, after the coordinator node restarts, first look for the timestamp of the last local transaction end log, and then ask all participant nodes for transaction records initiated by the coordinator that have not ended before this time:

a) If one or more participant nodes reply to the log indicating that the transaction has rolled back by itself, the coordinator node sorts the received log to restore the local log, saves the transaction rollback record and re-notifies all participants that the transaction rolls back ;

b) If the log replied by all participants indicates that the transaction is still waiting, the coordinator node sorts the received log to restore the local log, and decides whether to commit or roll back the transaction according to the execution of the transaction;

c) If a participant has not recovered from the failure of the participant node and does not have all the logs; or if a participant cannot be contacted, it is considered that the transaction is rolled back, and the coordinator node organizes the received logs to restore the local log and writes Roll back the log and send the transaction decision to the participant node after contact with the participant node is restored.

In order to reduce the forced log operation with frequent transactions, the present invention first allocates a certain cache area in the memory of the system participant node and the coordinator node to cache the transaction log. For participant nodes, when the cache area is full or the cache exceeds a certain period of time or when the log is forced to be written, the cache log is written to the disk at one time. For the coordinator node, the cache log is written once at the beginning of each transaction.

Before the transaction starts, the coordinator node searches for the corresponding participant according to the transaction content, and sends each instruction of the transaction to the corresponding participant node for execution. Then, the atomicity of the entire transaction execution process and the recoverability in case of failure are guaranteed through the information transfer between the coordinator node and the participant node and the time stamp of the coordinator node, and the flexibility of the system is increased. The whole method is divided into two aspects:

The first aspect is business preparation. Including: looking for the resources involved according to the content of the transaction, determining the node where the resource is located; establishing a connection to each of the multiple resources for the application; determining the context of the current transaction.

The second aspect is to ensure the smooth progress of affairs, strictly implement the steps and requirements of information transmission.

Specifically, the distributed transaction submission scheme of the present invention can be realized through the following steps:

1) The coordinator node searches for the resources to be used according to the transaction content, determines the node where the resource is located (that is, determines the participant node); establishes a connection to the resource; determines whether there is a cache log in the current coordinator node, and determines each operation request of the transaction , and the total number of requests.

2) The coordinator node sends an operation request message of the transaction to the participant node. This message contains the coordinator ID, the coordinator's local timestamp TimeStamp, the content of the transaction's single-step request, and the IDs of all participants involved in this single-step request,

Coordinator-local transaction ID. The message format is as follows:

Transaction ID Coordinator ID Participant ID Transaction single-step request content i TimeStamp

Where i indicates that this request is the i-th step operation of the transaction.

At the same time, the coordinator node writes the log according to the transaction request:

① If it is a new transaction, it is forced to write to the transaction start log. If it is confirmed in 1) that there is a transaction cache log in the current coordinator node, the cache log and the transaction start log are flushed to the disk together. If it is confirmed in 1) that the current coordinator node does not have a transaction cache log, only the transaction start log is forced to be written.

The transaction start log format is as follows:

Transaction ID Coordinator ID Participant ID Transaction single-step request content start TimeStamp

Among them, start is the start flag of this transaction, which indicates the start of this transaction, and can also be represented by "1". Participant IDs are the IDs of all participants participating in all steps of this transaction.

②If it is the i-th step request of the transaction, cache this log.

Transaction step i request log format

Transaction ID Coordinator ID Participant ID Transaction single-step request content i TimeStamp

Wherein, i>1. Participant ID is the ID of the participant participating in step i of the transaction.

3) The participant processes the local log according to the completion of the operation request of the transaction, and sends a message to the coordinator node. Both local logs and messages need to add corresponding information according to the messages received in step 2).

The message format is as follows:

Coordinator ID Coordinator transaction ID This participant ID i vote TimeStamp

Among them, "coordinator transaction ID" is the "transaction ID" corresponding to the transaction in the coordinator node transmitted in step 2); "this participant ID" is the ID information of the local participant; "i" indicates that this transaction The operation request is the i-th request of the transaction, which can be obtained according to the information transmitted in step 2); "vote" is the completion status of the operation request of the transaction, which can be "yes" or "no", corresponding to the success of the operation request of the transaction or fail; "TimeStamp" is the timestamp contained in the coordinator message corresponding to this message.

The log format is as follows:

local transaction ID Coordinator ID Coordinator transaction ID Participant ID OP vote TimeStamp

Among them, the "local transaction ID" is the transaction ID corresponding to the operation request of this transaction in the participant node. "OP" is the transaction single-step request content, which can be obtained from the message delivered by the coordinator node.

If the participant node does not complete the operation request of the transaction, it needs to cache the log, return the information to the coordinator node and roll back the transaction immediately. If the participant node completes the operation request of the transaction, it only needs to cache the log, return the information to the coordinator node and wait for further instructions from the coordinator node.

If before the log is cached, it is checked that the local log cache area is full, or the oldest log reaches the maximum cache time, the log is forced to be written, and a corresponding message is sent to the coordinator node.

4) The coordinator node receives the participant node information, analyzes the voting results, and sends a message to the participant node.

① If one or more participant nodes fail to vote in time or the voting result is "no", the transaction needs to be rolled back. In this case, the coordinator node caches the local log and sends a transaction rollback message to all participant nodes that voted "yes". This cached log can be written with the next coordinator node's forced logging operation. Go to step 5).

The message format is as follows:

Transaction ID Coordinator ID Participant ID Abort end TimeStamp

The log format is as follows:

Transaction ID Coordinator ID Participant ID Abort end TimeStamp

Among them, "end" indicates the end of the transaction, which can be represented by "0".

②If all participants vote "yes", and the number of operation requests i of the transaction indicated in the information returned by the participant node also conforms to the total number of operation requests of this transaction determined in 1), the transaction can be submitted. In this case, the coordinator node caches the local log and sends a commit message to all participant nodes of the transaction. This cached log can be written with the next coordinator node's forced logging operation. Go to step 5).

The message format is as follows:

Transaction ID Coordinator ID Participant ID Commit end TimeStamp

The log format is as follows:

Transaction ID Coordinator ID Participant ID Commit end TimeStamp

Among them, "end" indicates the end of the transaction, which can be represented by "0".

③If all participant nodes vote "yes" and the transaction has not been completed, go back to step 2).

5) Participant nodes execute and cache logs according to the final decision. The log structure is as follows:

local transaction ID Coordinator ID Coordinator transaction ID Participant ID end fi TimeStamp

Among them, "end" indicates the end of the transaction; "fi" is the final decision of the transaction, which is "commit" or "abort".

If before the log is cached, it is checked that the local log cache area is full, or the oldest log reaches the maximum cache time, the log is forced to be written, and then the required operation is performed.

The faults in the distributed system are divided into two categories: one is the communication failure caused by the network, and the other is the coordinator node or participant node failure (site failure). The following describes how to deal with these two faults.

For communication failures, if it occurs in step 2), all participant nodes may not be able to accept the request of the coordinator node, and the coordinator node can decide to roll back the transaction independently after waiting for a timeout; or some participant nodes have not received the request , in this case, the coordinator node will think that the non-responsive participant node has rolled back the transaction, so the coordinator node decides to roll back the transaction.

If it appears in step 3), it is possible that the coordinator node cannot receive the votes of all participant nodes. In this case, the coordinator node believes that the participant nodes without votes have rolled back the transaction, so it decides to roll back the transaction .

If it appears in step 4), it is possible that all participant nodes have not received the final decision. In this case, the participant nodes will first ask each other according to the received list of participants performing the same transaction: If the vote of the participant is to roll back the transaction, all transaction participants can roll back the transaction accordingly, and reply the transaction rollback message to the participant who has inquired about this message; if the vote of all the participants who can be contacted is to commit the transaction , because the participant node cannot judge whether the transaction has completed all requests, nor can it judge whether the participant list it holds includes all participants, so it needs to continue to wait for the final decision of the coordinator node; or some participants receive the final If the decision is made, the rest of the participants can implement the final decision accordingly, and reply the final decision of the transaction to the participant who has inquired about this message; if some participant nodes cannot be contacted within the limited time, and it is impossible to determine whether the transaction can be rolled back , you should continue to wait.

The failure of the coordinator node can be divided into two categories for discussion.

If the coordinator node fails, after the coordinator node restarts, it will first look for the timestamp of the last local transaction end log. Then ask all participant nodes for transaction records initiated by the coordinator that have not ended before this time. Each participant node returns the log related to this transaction, which can be divided into three situations: ① The log indicates that the transaction has rolled back by itself. Since the message of the coordinator node cannot be obtained for a long time, the participant nodes must wait for the timeout, and then initiate inquiries with each other. If any participant node votes no, the transaction can be rolled back by itself. If the coordinator node receives a transaction rollback message from one or more participant nodes, the coordinator node sorts the received logs to restore the local log, and re-informs all participants that the transaction rolls back. ② The log indicates that the transaction is still waiting. If all participant nodes reply that the transaction is waiting, at this time, the coordinator node sorts the received log to restore the local log, and decides to commit or roll back the transaction according to the execution of the transaction. ③If a participant has not recovered from the failure of the participant node, does not have all the logs, or cannot get in touch, it is considered that the transaction is rolled back, and the coordinator node sorts the received logs to restore the local log, writes the rollback log and Send the decision to the participant node after contact with the participant node is restored.

During this process, if a participant node is notified of a transaction rollback, but the participant itself has lost transaction-related records, it needs to request the coordinator node transaction-related logs again.

If the participant node fails, after the participant node restarts, it will first find the last timestamp of the local static log, and then ask the coordinator node about the transaction after this time. It is enough to recover according to the log records of the coordinator node.

Compared with traditional 2PC, this transaction submission method has the following advantages:

1) For a distributed system with n participant nodes and 1 coordinator node, only one mandatory log record is required, compared with traditional 2PC which requires 2n mandatory log records, which greatly reduces the number of log operations and improves system efficiency .

2) The number of information exchanges is changed from 4n to 2n_op+n, where n_op is the total number of operations performed by the transaction. For example, assuming that the total number of transaction requests is k steps, about 60% of the participant nodes participate in the transaction for each request, then n_op=k*60%*n. For a transaction containing only one request under normal circumstances, n_op=60%*n, the number of information exchanges at this time is 2.2n, which is much smaller than the 4n information exchanges of traditional 2PC.

3) Use the participant list to inquire among participants, which can reduce the waiting time of participants in some cases of communication failure, improve transaction efficiency, and have extremely high availability. Effectively solve the traditional 2PC situation where transactions are queued and waited in the case of network congestion. Restricting the list of participants in the message to those participating in the same transaction step also controls the size of the query.

The logs of the participant nodes all adopt a cache strategy. When the cache space is full or the upper limit of the cache time is reached, they can be written to the disk at one time. The security of the log is briefly described as follows:

Assuming that the probability of failure of a host is a constant λ, the mean time between failures (MTTF) of the host is 1/λ. Since the probability of failure among hosts is independent of each other, and the number of hosts is n, the probability of failure of all hosts should be p=(1-e ^-λt ) ⁿ within time 0 to t. Let the MTTF of a single host be T, then λ=1/T, so $p={(1-e^{(-\frac{t}{T})})}^{\mathrm{no}}.$ Assume that the fault-free time of a single host is 100 hours, and the transaction time is 1 minute. During this time, all hosts fail, logs are lost, and the probability that they cannot be queried is:

p=(0.00016665277854932547) ⁿ ≈(2×10 ^-4 ) ^nBecause the coordinator node will write all the cached logs in the system to the disk for each mandatory logging operation, the log cache time is shortened, and the corresponding log loss less likely.

Description of drawings

Figure 1 is the flow of the traditional two-phase commit protocol.

Fig. 2 is the transaction submission process of the present invention.

Detailed ways

The present invention will be described in further detail below with reference to the accompanying drawings and an example, but the scope of the present invention is not limited in any way.

Consider the following example. A commercial chain has a central organization and n different sales outlets. The central organization is used to save employee data, the types of goods of the entire chain store and the inventory types of each point of sale, etc.; the sales store keeps the sales and inventory data of the store. If the manager wants to query all stores, find out the inventory quantity of toothbrushes in all stores, and make up the inventory of all stores with less than 300 to 300.

Suppose the data situation is as follows:

Stores 1, 2, 3, 4, and 5 contain toothpaste in inventory, and the inventory is 100, 200, 300, 400, and 500 respectively. The coordinator node transaction ID is 654321; each participant node transaction ID is 154321, 254321, 354321, 454321, 554321 respectively; the coordinator node ID is "X", and the other participant node IDs are "A" and "B"" C" "D" "E"; the transaction request can be divided into two completions, namely the query request op_1 and the update request op_2. The voting results of the participant nodes are yes or no.

The execution steps of the transaction are as follows:

1) The node that submits the transaction, that is, the node where the manager is located automatically becomes the coordinator node. The coordinator node determines from the records it keeps which stores have toothpaste in its inventory category and establishes connections to these databases. That is, determine stores 1, 2, 3, 4, and 5 as participant nodes and establish connections to these nodes. Check its own log cache area to determine whether there are cached logs that have not been written to the static storage system.

2) The coordinator node sends transaction messages to all participant nodes. The message format is:

654321 x A, B, C, D, E Op_1 1 TimeStamp

At the same time, the coordinator node is forced to write to the log. log structure

654321 x A, B, C, D, E Op_1 start TimeStamp

If it is determined in 1) that the cached logs are not written to the static storage system, write them together.

3) If the participant node completes the Op_1 transaction request, cache the local log and send the vote to the coordinator node. The log structure and sent messages of each participant node are as follows:

Participant node 1:

Log format:

154321 x 654321 A, B, C, D, E Op_1 Yes TimeStamp

Message format:

x 654321 A 1 Yes TimeStamp

Participant node 2:

Log format:

254321 x 654321 A, B, C, D, E Op_1 Yes TimeStamp

Message format:

x 654321 B 1 Yes TimeStamp

Participant node 3:

Log format:

354321 x 654321 A, B, C, D, E Op_1 yes TimeStamp

Message format:

x 654321 C 1 Yes TimeStamp

Participant node 4:

Log format:

454321 x 654321 A, B, C, D, E Op_1 Yes TimeStamp

Message format:

x 654321 D 1 Yes TimeStamp

Participant node 5:

Log format:

554321 x 654321 A, B, C, D, E Op_1 Yes TimeStamp

Message format:

x 654321 E 1 Yes TimeStamp

If the participant node does not complete the transaction request, the transaction rollback log is cached and the transaction is rolled back. The log structure and message format are the same as above, just replace the corresponding yes with no.

Before caching the log, check whether it is necessary to force the log to be written, and if so, force the log to be written first before performing other operations.

4) The coordinator node analyzes the voting results. If all participant nodes in step 3) return a yes message, the transaction enters step 5); otherwise, enters step 7).

5) The coordinator node sends transaction messages to all participant nodes. The message format is:

654321 x A, B Op_2 2 TimeStamp

Meanwhile, the coordinator node caches the logs. log structure

654321 x A, B Op_2 2 TimeStamp

6) If the participant node completes the Op_2 transaction request, cache the local log and send the vote to the coordinator node. The log structure and sent messages of each participant node are as follows:

Participant node 1:

Log format:

154321 x 654321 A, B Op_2 Yes TimeStamp

Message format:

x 654321 A 2 Yes TimeStamp

Participant node 2:

Log format:

254321 x 654321 A, B Op_2 Yes TimeStamp

Message format:

x 654321 B 2 Yes TimeStamp

If the participant node does not complete the Op_2 transaction request, cache the transaction rollback log and roll back the transaction. The log structure and message format are the same as above, just replace the corresponding yes with no.

Before caching the log, check whether it is necessary to force the log to be written, and if so, force the log to be written first before performing other operations.

7) The coordinator node decides the next step of the transaction according to the voting result.

If one or more participant nodes fail to vote in time or vote "no", the transaction needs to be rolled back. In this case, the coordinator node caches the local log and sends a transaction rollback message to all nodes that voted yes. This cached log can be written with the next coordinator node's forced logging operation.

The message format is as follows:

654321 x A, B, C, D, E Abort end TimeStamp

The log format is as follows:

654321 x A, B, C, D, E Abort end TimeStamp

If all participant nodes vote "yes" and the number of steps for the transaction is 2, the transaction can be committed. In this case, the coordinator node caches the local log and sends commit messages to all participant nodes.

The message format is as follows:

654321 x A, B, C, D, E Commit end TimeStamp

The log format is as follows:

654321 x A, B, C, D, E Commit end TimeStamp

8) The participant node caches the log and executes it according to the final decision. The log structure is as follows:

When the final decision is submitted:

Participant node 1:

154321 x 654321 A, B, C, D, E end Commit TimeStamp

The remaining participant nodes only need to replace the local transaction ID.

If the final decision is to roll back the transaction, just replace Commit with Abort.

According to this process, the successful execution of this transaction requires 19 pieces of exchanged information, and one forced log record. According to the traditional 2PC, excluding the communication in the transaction request sending stage, 20 pieces of information need to be exchanged, and 11 times of forced log records are required. It can be seen that the method adopted in the present invention has obvious advantages.

Claims (7)

1. a transaction commit method of distributed database system the steps include:

1) in participant's node and coordinator node internal memory, respectively distributes a buffer zone, be used for the buffer memory transaction journal;

2) coordinator node is confirmed participant's node according to the affairs content and is connected with it, confirms the operation requests information of affairs simultaneously;

3) coordinator node is sent the single-step operation request message of affairs, the transactions requests daily record of writing down each operation requests simultaneously to participant's node; Its method is:

If a) operation requests of affairs is operation requests of new affairs, affairs that then will these new affairs begin daily record forces to write disk; Said affairs begin daily record and comprise: affairs ID, telegon ID, all participant ID that relate to the affairs all operations, the 1st step of affairs request content, this affairs opening flag and telegon local time stamp;

B) if the operation requests of affairs is i step requests of current affairs, then this daily record of buffer memory; The daily record of the i of said affairs step request comprises: affairs ID, telegon ID, relate to all participant ID of affairs i step operation, affairs i goes on foot request content, i and telegon local time stamp, i＞1 wherein;

4) participant's node is handled local daily record according to the performance of each operation requests, and sends corresponding message to coordinator node; Its method is: if participant's node is accomplished to failure the operation requests of affairs, then need the buffer memory transaction journal, return message is given coordinator node and rollback affairs; If it is successfully that participant's node is accomplished the operation requests of affairs, then only need the buffer memory transaction journal, return message is given coordinator node and is waited for the operation requests message of coordinator node transmission affairs;

5) coordinator node is judged according to the message that all participant's nodes that receive send:

Be failure if a) have one or more participant's node in setting-up time, not have the operation requests of affairs in return messages or the return messages to accomplish, then coordinator node is judged as affairs needs rollback; The daily record of coordinator node buffer memory local matter, and the operation requests completion of affairs is sent transaction rollback message for successful participant's node in return messages; Participant's node is carried out transaction rollback message and the buffer memory transaction journal that receives then;

B) if in all participant's node return messages the operation requests of affairs to accomplish be successfully, and in participant's node return messages the operation requests number of affairs to equal the operation requests of these affairs total, then coordinator node is judged as affairs and can submits to; The daily record of coordinator node buffer memory local matter, and send to all participant's nodes of these affairs and to submit message to; Participant's node is carried out submission message and the buffer memory transaction journal that receives then;

C) if the completion of the operation requests of affairs is successfully in all participant's node return messages, and affairs completion as yet, then repeating step 3)～5).

2. the method for claim 1 is characterized in that the operation requests information of said affairs comprises: each operation requests of affairs, and the operation requests of affairs sum n.

3. according to claim 1 or claim 2 method is characterized in that said coordinator node when each affairs begin, confirms whether there is the buffer memory transaction journal in the current coordinator node, if exist then with its one-time write disk; If the buffer zone of said participant's node completely perhaps buffer memory surpasses setting-up time or pressure takes place when writing the buffer memory transaction journal, with buffer memory transaction journal one-time write disk.

4. method as claimed in claim 2 is characterized in that the operation requests message of said affairs comprises: affairs ID, telegon ID, relate to all participant ID of this operation requests, affairs single step request content, i and telegon local time stamp; Saidly send corresponding message to coordinator node and comprise: the up-to-date timestamp that telegon ID, telegon affairs ID, local participant ID, i, vote and coordinator node are sent; The local daily record of said participant's node comprises: local matter ID, telegon ID, telegon affairs ID, relate to the up-to-date timestamp that all participant ID of this operation requests, affairs single step request content, vote and coordinator node are sent; Wherein i is the i step operation requests of these affairs, and vote is this transaction operation request performance.

5. the method for claim 1 is characterized in that in the said step 5), and said transaction rollback message comprises: affairs ID, telegon ID, participant ID, transaction rollback decision, affairs end mark and telegon local time stamp; Said affairs submit to message to comprise: affairs ID, telegon ID, participant ID, affairs are for decision, affairs end mark and telegon local time stamp; The local matter daily record of coordinator node buffer memory comprises: affairs ID, telegon ID, participant ID, affairs final decision, affairs end mark and telegon local time stamp; The transaction journal of participant's nodal cache comprises: the up-to-date timestamp that local matter ID, telegon ID, telegon affairs ID, participant ID, affairs end mark, affairs final decision and coordinator node are sent; Said affairs final decision is that transaction rollback decision or affairs are for decision.

6. the method for claim 1; It is characterized in that then participant's node is at first inquired mutually according to participant's list of the same affairs step of execution that receives if all participant's nodes are not all received the rollback message that coordinator node is sent or submitted message in setting-up time:

If a) have participant's operation requests to accomplish to failing, then all affairs participants all carry out transaction rollback message;

B) if it is successfully that all participants' operation requests is accomplished, then participant's node continues the message that the wait coordinator node is sent;

C) if there is participant's node to receive rollback message or submission message, then all the other participants consult and carry out;

D) if there is participant's node in the time that limits, can't get in touch, but and can't confirm whether rollback of affairs,

Then continue to wait for.

7. the method for claim 1; It is characterized in that if coordinator node lost efficacy; Then after coordinator node is restarted, at first search the time stamp of the last affairs end log in this locality, inquire unclosed transaction journal that telegon is initiated before between all participant's nodes are at this moment then:

If the daily record that a) has or above participant's node to reply shows affairs rollback voluntarily, then the daily record that receives of coordinator node arrangement is preserved the transaction rollback record and is notified all participants this transaction rollback again to recover local daily record;

B) if the daily record that all participants all reply shows affairs still to be waited for, then the daily record that receives of coordinator node arrangement is submitted to or rollback according to the implementation status decision affairs of affairs to recover local daily record;

C) if having in the participant Shang Weicong participant node failure and recover, do not have whole daily records; Perhaps have the participant to get in touch, then think transaction rollback, the daily record that the coordinator node arrangement receives to be to recover local daily record, writes the rollback daily record and sends the affairs decision to participant's node recovering getting in touch the back with participant's node.

Images