A transaction commit method and apparatus

Abstract

The specification discloses a transaction submission method and device. In a submission stage, a participant submits the to-be-submitted data stored by the participant according to a transaction submission request, and forwards the transaction submission request to a migration node. The migration node submits the to-be-submitted data stored by the migration node according to the transaction submission request. Then, the participant returns an execution result corresponding to the transaction submission request according to the submission result of the participant and the submission result of the migration node, so as to complete the submission of the database transaction. The method records the corresponding migration node of the participant, and forwards the transaction submission request to the migration node by the participant in the submission stage, so as to complete the submission of the to-be-submitted data in the migration node. The execution efficiency and accuracy of the database transaction are ensured.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of computer, and particularly relates to a transaction submission method and device. BACKGROUND

[0002] At present, with the needs of computer technology and business deep integration, the emergence of distributed computing, block chain and other business scenarios, the demand for using distributed databases to execute business is increasing. In the process of executing database transactions by each node of the distributed database, in order to avoid that individual nodes are down due to excessive load, the load balancing of each node needs to be ensured. The database transaction usually includes an execution phase and a submission phase.

[0003] Therefore, how to perform load balancing in the submission phase, the present specification provides a transaction submission method. SUMMARY

[0004] The present specification provides a transaction submission method and device to partially solve the above problems existing in the prior art.

[0005] The present specification adopts the following technical solutions:

[0006] The present specification provides a transaction submission method, which is applied to a participant in a distributed database, and the method comprises:

[0007] In response to a transaction submission request, the participant itself stores the to-be-submitted data for submission, determines the submission result of the participant itself, and forwards the transaction submission request to a migration node according to the node identifier of the migration node stored, so that the migration node stores the to-be-submitted data for submission according to the transaction submission request, and the migration node is another participant to which the participant migrates data;

[0008] The submission result returned by the migration node is received;

[0009] According to the submission result of the participant itself and the submission result returned by the migration node, the execution result of the transaction submission request is returned, so that the distributed database completes the submission of the database transaction according to the execution result.

[0010] The present specification provides a transaction submission method, which is applied to a participant in a distributed database, and the method comprises:

[0011] in response to a pre-commit request, pre-commiting to-be-committed data stored by the participant itself, determining a pre-commit result of the participant itself, and forwarding the pre-commit request to a migration node according to a node identifier of the migration node stored, so that the migration node pre-commits to-be-committed data stored by the migration node according to the pre-commit request, the migration node being another participant to which data of the participant is migrated;

[0012] receiving a pre-commit result returned by the migration node;

[0013] returning an execution result of the pre-commit request according to the pre-commit result of the participant itself and the pre-commit result returned by the migration node, so that the distributed database completes pre-committing of the database transaction according to the execution result.

[0014] The specification provides a transaction committing apparatus for a participant in a distributed database, comprising:

[0015] a processing module configured to, in response to a transaction committing request, commit to-be-committed data stored by the participant itself, determine a committing result of the participant itself, and forward the transaction committing request to a migration node according to a node identifier of the migration node stored, so that the migration node commits to-be-committed data stored by the migration node according to the transaction committing request, the migration node being another participant to which data of the participant is migrated;

[0016] a receiving module configured to receive a committing result returned by the migration node;

[0017] a committing module configured to return an execution result of the transaction committing request according to the committing result of the participant itself and the committing result returned by the migration node, so that the distributed database completes committing of the database transaction according to the execution result.

[0018] The specification provides a transaction committing apparatus for a participant in a distributed database, comprising:

[0019] a preprocessing module configured to, in response to a pre-commit request, pre-commit to-be-committed data stored by the participant itself, determine a pre-commit result of the participant itself, and forward the pre-commit request to a migration node according to a node identifier of the migration node stored, so that the migration node pre-commits to-be-committed data stored by the migration node according to the pre-commit request, the migration node being another participant to which data of the participant is migrated;

[0020] a receiving module configured to receive a pre-commit result returned by the migration node;

[0021] The pre-commit module is configured to return an execution result of the pre-commit request according to a pre-commit result of the participant itself and a pre-commit result returned by the migration node, so that the distributed database completes the pre-commit of the database transaction according to the execution result.

[0022] The present specification provides a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the transaction commit method.

[0023] The present specification provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor implements the transaction commit method when executing the program.

[0024] The above at least one technical solution adopted by the present specification can achieve the following beneficial effects:

[0025] In the commit phase, the participant submits the to-be-committed data stored by the participant itself according to the received transaction commit request, and forwards the transaction commit request to the migration node. The migration node submits the to-be-committed data stored by the migration node itself according to the transaction commit request. Then, the participant returns an execution result corresponding to the transaction commit request according to the commit result of the participant itself and the commit result of the migration node received, so as to complete the commit of the database transaction.

[0026] The present method records the corresponding migration node of the participant, and forwards the transaction commit request to the migration node in the commit phase, so as to complete the commit of the to-be-committed data in the migration node. The execution efficiency and accuracy of the database transaction are ensured. BRIEF DESCRIPTION OF DRAWINGS

[0027] The accompanying drawings, which are included to provide a further understanding of the present specification, constitute a part of the present specification, and the illustrative embodiments of the present specification and their description serve to explain the present specification, and do not constitute an improper limitation on the present specification. In the drawings:

[0028] In the drawings:

[0029] Figure 1 The present specification provides a flowchart of the transaction commit method;

[0030] Figure 2A The present specification provides a schematic diagram of data migration;

[0031] Figure 2B The present specification provides a schematic diagram of the forwarding process of the transaction commit request;

[0032] Figure 3A pre-commit flowchart of a transaction commit method provided for the present specification;

[0033] Figure 4 A two-phase commit flowchart of a transaction commit method provided for the present specification;

[0034] Figure 5 A flowchart of a transaction commit method provided for the present specification;

[0035] Figure 6 A structure diagram of a transaction commit device provided for the present specification;

[0036] Figure 7 A structure diagram of a transaction commit device provided for the present specification;

[0037] Figure 8 An electronic device diagram corresponding to Figure 1 , 3 , 4 provided for the present specification. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical scheme and advantages of the present specification clearer, the technical scheme of the present specification will be described clearly and completely below in combination with specific embodiments of the present specification and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present specification, not all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present specification.

[0039] In a distributed database, a coordinator and a participant are usually provided. The coordinator is used to distribute tasks, and the participant is used to execute the tasks distributed by the coordinator. In a database, a business can usually be provided externally by executing a database transaction, so the task executed by the participant is often an operation contained in a database transaction. The database transaction usually contains an execution phase and a commit phase. The execution phase is a phase of executing each operation corresponding to the database transaction, and the commit phase is a phase of persisting the data generated when each operation corresponding to the database transaction is executed.

[0040] Taking a database transaction of "A transfers 100 yuan to B" as an example, the execution phase is a phase of executing the operation of "subtracting 100 yuan from the account of A" and the operation of "adding 100 yuan to the account of B". The commit phase is a phase of recording the data after "subtracting 100 yuan from the account of A" and the data after "adding 100 yuan to the account of B" as a log, and storing the data and the log.

[0041] Generally, the database transaction allocation in the distributed database is performed by the coordinator, and the load balancing of each participant is responsible by the control center. Among them, the common load balancing method is data migration. That is, the data in the high-load participant is migrated to the low-load participant to reduce the database transactions that the high-load participant needs to process. Since the load balancing is usually performed in real time, it does not consider whether there is a database transaction being executed. Therefore, it is easy to cause the database transaction execution to fail after data migration.

[0042] The data migration cases in the execution phase and the commit phase are described respectively.

[0043] When the participant is overloaded in the execution phase of the database transaction, the control center in the distributed database can send a migration instruction to the participant. The participant can migrate data according to the received migration instruction, and return migration success information to the control center after migrating the data, and the control center can update the correspondence between the data and the participant. If the migrated data is used to execute the database transaction, the participant can determine that the received database operation cannot be executed, and return a prompt information to the coordinator, and the coordinator can determine that the participant does not store the data required to execute the database operation according to the prompt information. Then, the coordinator can query the correspondence between the data and the participant from the control center, and send an execution instruction carrying the database operation to the participant that stores the latest data required to execute the database operation according to the query result.

[0044] When the participant is overloaded in the commit phase of the database transaction, the control center in the distributed database can also send a migration instruction to the participant. The participant can migrate data according to the received migration instruction, and return migration success information to the control center after migrating the data, and the control center can update the correspondence between the data and the participant. If the migrated data is the to-be-committed data generated by executing the database transaction, the participant can determine that the commit fails, and return a reply information representing the commit failure to the control center. Then, the coordinator cannot determine whether the failure reason is that the participant fails to execute the database transaction, or that the to-be-committed data stored in the participant is migrated, causing the participant to not store the corresponding data, resulting in commit failure, when receiving the reply information. In this case, the coordinator can only determine that the database transaction execution fails, and sends a rollback instruction to the participant, so that the processing result is rolled back according to the received rollback instruction, and the database transaction is treated as a database transaction that is not executed successfully. This makes the current database transaction commit efficiency and execution efficiency low.

[0045] Therefore, the present specification provides a new transaction commit method to solve the problem that the accuracy and efficiency of database transaction commit cannot be guaranteed under the premise of load balancing in the commit phase.

[0046] The technical solutions provided by the embodiments of the present specification are described in detail below with reference to the accompanying drawings.

[0047] Figure 1 The flowchart of the transaction submission method provided by the present specification specifically includes the following steps:

[0048] S100: In response to a transaction submission request, the participant stores the to-be-submitted data in itself and submits the to-be-submitted data in itself, determines the submission result of the participant itself, and forwards the transaction submission request to the migration node according to the node identifier of the stored migration node, so that the migration node stores the to-be-submitted data in itself and submits the to-be-submitted data in itself according to the transaction submission request. The migration node is another participant to which the participant migrates data.

[0049] In one or more embodiments provided by the present specification, the transaction submission method is applied to a participant of a distributed database, so that the participant can perform transaction submission through the process shown in the figure. That is, the execution subject of the transaction submission method provided by the present specification is the participant in the distributed database. Figure 1

[0050] In order to solve the problem that the database transaction cannot be submitted after data migration occurs in the submission stage, resulting in low submission efficiency and execution efficiency of the database transaction, the present specification provides a new transaction submission method. In the submission stage, the participant stores the to-be-submitted data in itself and submits the to-be-submitted data in itself, and at the same time, forwards the transaction submission request to the migration node, so that the migration node stores the to-be-submitted data in itself and submits the to-be-submitted data in itself according to the transaction submission request. In order to achieve the purpose of submitting the to-be-submitted data stored in the participant itself and the to-be-submitted data migrated to the migration node at the same time, to ensure the smooth execution of the database transaction.

[0051] Specifically, the participant can determine the to-be-submitted data stored in the participant itself according to the transaction submission request. Since data migration may occur in the execution stage and the submission stage, the to-be-submitted data stored in the participant itself may be data corresponding to each database operation executed by the participant in the execution stage, or may be data corresponding to at least part of the database operation. Of course, the to-be-submitted data stored in the participant itself can also be empty. The amount of data of the to-be-submitted data stored in the participant itself can be set as needed, and the present specification does not limit this.

[0052] ​It should be noted that the transaction to be submitted in the embodiments of the present specification is still the transaction corresponding to the transaction submission request, that is, the database transaction jointly executed by each participant in the distributed database. Since the participant needs to perform database transaction submission based on the data stored by itself when performing database transaction submission, the data to be submitted is the data based on which the database transaction to be submitted is submitted. That is, in the present specification, the data based on which the submitted transaction is based is referred to as the data to be submitted.

[0053] Therefore, the participant can determine whether the to-be-submitted data stored by itself is empty. If yes, the participant can determine that the submission result of itself is execution success. If no, the participant can submit the to-be-submitted data stored by itself according to the transaction submission request, and determine the submission result of itself.

[0054] Meanwhile, the participant can determine the migration node according to the stored node identifier of the migration node, and forward the transaction submission request to the migration node. The migration node is another node to which the participant migrates data. That is, for each database transaction, the participant corresponding to the database transaction can receive a migration instruction, and send data to another participant according to the received migration instruction. The other participant to which the data is migrated is the migration node.

[0055] Therefore, after receiving the transaction submission request, the node identifier of the migration node stored in the participant can be the node identifier of another participant to which the data corresponding to the database transaction corresponding to the transaction submission request is migrated. Then the participant can determine the node identifier stored by itself before receiving the database transaction, and determine the node identifier as the node identifier of the migration node.

[0056] Then the migration node can receive the transaction submission request sent by the participant, and determine the to-be-submitted data generated by the executed database transaction stored in the migration node from the received migration data. Then, the migration node can submit the to-be-submitted data generated by the executed database transaction stored in the migration node according to the transaction submission request, and determine the submission result. After determining the submission result, the migration node returns the submission result to the participant. The submission result can be submission success or submission failure.

[0057] Further, if the data generated by the executed database transaction is migrated to the migration node, the migration node can be considered as a new participant corresponding to the database transaction. Therefore, when the migration node receives the transaction submission request sent by the participant, the migration node can determine whether the node identifier of the migration node stored by itself exists.

[0058] If the migration node exists, the migration node can send the transaction commit request to the specified migration node with the stored node identifier of the migration node. If the migration node does not exist, the migration node can directly determine the stored to-be-committed data of the migration node to be committed, determine a commit result, and return the commit result.

[0059] Further, multiple database transactions can be executed in the participant at the same time. When the participant receives the transaction commit request, the participant can first determine the database transaction corresponding to the transaction commit request. Then, according to the determined database transaction, the participant can determine the to-be-committed data corresponding to the database transaction, and commit the to-be-committed data corresponding to the database transaction. Then, according to the migration node corresponding to the database transaction, the participant can forward the transaction commit request to the migration node, and the migration node can commit the to-be-committed data corresponding to the database transaction stored in the migration node according to the transaction commit request. That is, when the participant receives the migration instruction, the participant can store the migration node according to the database transaction corresponding to the data identified by the data in the migration instruction, as a unit of one database transaction. In order to subsequently forward the transaction commit request to the migration node corresponding to the database transaction according to the database transaction corresponding to the transaction commit request when the participant receives the transaction commit request.

[0060] S102: receiving the commit result returned by the migration node.

[0061] S104: returning an execution result of the transaction commit request according to the commit result of the participant itself and the commit result returned by the migration node, so that the distributed database completes the commit of the database transaction according to the execution result.

[0062] In one or more embodiments provided in the specification, as described above, the participant can return an execution result corresponding to the transaction commit request according to the commit result of the participant itself and the commit result of the migration node received, so as to complete the commit of the database transaction. That is, in the specification, only when the participant and the migration node are both successfully committed, the execution of the transaction commit request is considered to be successful.

[0063] Specifically, the participant can receive the commit result returned by the migration node. According to each commit result, the participant can determine whether each commit result is successfully committed.

[0064] If yes, the participant can return an execution result of the transaction commit request that is successfully executed. If no, it indicates that there is still a node that is not successfully committed, and the participant can return an execution result of the transaction commit request that is unsuccessfully executed.

[0065] If the node sending the transaction commit request is the coordinator, the participant can return the execution result of the transaction commit request to the coordinator. Then the coordinator can determine whether the commit is successful according to the execution results of the transaction commit requests corresponding to the database transaction received.

[0066] When the coordinator determines that the commit is successful, the coordinator can execute other database transactions. When the coordinator determines that the commit fails, the coordinator can send a rollback instruction to the participant sending the execution result of the transaction commit request corresponding to the database transaction, to ensure the atomicity of the database transaction. That is, either all commits or none commits.

[0067] Further, due to the database transaction commit phase, the data corresponding to the database transaction is prohibited from being accessed by other database transactions. Therefore, in order to avoid the situation that the database transaction commit time is too long, causing other database transactions to be unable to access the corresponding data, and further causing the execution efficiency of the database transaction to be low, in this specification, for each migration node, if the migration node does not return the commit result within a preset time period, the participant can determine that the commit result corresponding to the migration node fails. Then, the participant can return the execution result of the transaction commit request execution failure according to the "commit failure" commit result.

[0068] In addition, since the database transaction has atomicity, that is, either all commits or none commits. Therefore, when any commit failure commit result is received, the participant can directly return the execution result of the transaction commit request execution failure.

[0069] Based on Figure 1 The transaction commit method, by in the commit phase, for each participant, the participant submits the stored to-be-committed data according to the received transaction commit request, and at the same time, forwards the transaction commit request to the migration node, the migration node submits the stored to-be-committed data according to the transaction commit request. Then, the participant returns the execution result corresponding to the transaction commit request according to the commit result of itself and the received commit result of the migration node, so as to complete the commit of the database transaction.

[0070] The method records the corresponding migration node of the participant, and in the commit phase, the participant forwards the transaction commit request to the migration node, to complete the commit of the to-be-committed data in the migration node. The execution efficiency and accuracy of the database transaction are guaranteed.

[0071] In one or more embodiments provided in the specification, for each participant, the participant needs to perform transaction commit only when the participant contains the to-be-committed data generated by executing the database transaction. Therefore, before step S100, the participant can first determine the to-be-committed data generated by executing the database transaction.

[0072] Specifically, the participant can determine, from the data stored by the participant itself, the data generated by the participant itself when executing the database transaction, as the to-be-committed data generated by executing the database transaction.

[0073] The to-be-committed data can include two types of data, one is data on which a database operation is performed, and the other is a transaction log corresponding to the database operation. The database operation can be an operation such as "add, delete, or modify". If the data in the database is stored in the form of a table, the above-mentioned data on which the database operation is performed can be row data corresponding to a row in which a unit performing the operation such as "add, delete, or modify" is located, or column data corresponding to a column in which the unit is located.

[0074] Further, in the database, data can also be stored in units of partitions. Therefore, when determining the to-be-committed data generated by executing the database transaction, the participant can also determine the to-be-committed data generated by executing the database transaction from a partition in which data on which a database operation corresponding to the database transaction is performed is located.

[0075] Further, only in the case of data migration, data in the participant can be migrated to other participants. Therefore, before performing step S100, the participant can first determine each migration node corresponding to the participant. As described above, the distributed database is provided with a control center for coordinating the loads of nodes in the distributed database, and the control center can monitor the load conditions of the nodes in the distributed database. When the control center detects that a participant has a load that is too high, the control center can migrate data in the participant with the load that is too high. That is, when the load of the participant is too high, the control center can also migrate data in the participant.

[0076] Specifically, first, when the control center detects that the load condition of the participant is greater than a preset threshold, the control center can determine that data migration needs to be performed on the participant. Therefore, the control center can determine, according to the load conditions of other nodes in the distributed system, other nodes to which the data of the participant needs to be migrated, as the migration nodes of the participant. Of course, the control center can also determine, according to the amount of data stored in the participant and the amount of data stored in each of the other nodes, data in the participant that needs to be migrated and the migration nodes of the participant.

[0077] Afterwards, the control center can send a migration instruction carrying the data identifier and the node identifier to the participant according to the data identifier of the data to be migrated and the node identifier of the migration node.

[0078] Then, the participant can receive the migration instruction sent by the control center and parse the migration instruction to determine the data identifier and the node identifier.

[0079] Finally, the participant can send the data corresponding to the data identifier to the migration node corresponding to the node identifier, and store the node identifier, so that the data is migrated to the migration node when the database transaction is executed, and the transaction commit request can be forwarded according to the stored node identifier when a transaction commit request is received subsequently.

[0080] In addition, since the data in the participant can be stored in a partitioned form, the migrated data can be migrated in units of partitions when the data is migrated. That is, the participant can directly migrate the data of the entire partition.

[0081] Specifically, the control center can send a migration instruction carrying a partition identifier and a node identifier to the participant.

[0082] Then, the participant can receive the migration instruction and parse the migration instruction to determine the partition identifier and the node identifier.

[0083] Finally, the participant can send the data of the partition corresponding to the partition identifier to the migration node corresponding to the node identifier, and store the node identifier.

[0084] Further, for a participant, the participant can process multiple database transactions simultaneously. For each database transaction processed by the participant, the partition corresponding to the database transaction is not the same partition as the partitions corresponding to other database transactions simultaneously processed by the participant. The partition corresponding to the database transaction is the partition where the data corresponding to the database operation of the database transaction is located.

[0085] Therefore, when storing the node identifier of the migration node, the participant can store the node identifier of the migration node corresponding to each database transaction in units of database transactions.

[0086] Further, when the participant sends the migrated data to the migration node, the migration node can receive the migrated data sent by the participant and store the received data as migration data.

[0087] It should be noted that the migration instruction in the present specification can also be sent to the participant by the user at any stage of the database execution through the control center. That is, the user can control the control center by sending a control request or the like to the control center, and send the migration instruction to the participant according to the data that the user wants to migrate. That is, the sending reason of the migration instruction can not only be load balancing. The sending reason of the migration instruction can be set as needed, and the present specification does not limit this.

[0088] In addition, the participant can also receive data migrated by other participants. That is, the participant can also be a migration node of other participants. Then the participant needs to submit not only the to-be-submitted data generated when the participant executes the database transaction, but also the to-be-submitted data corresponding to the database transaction in the migration data. Therefore, when receiving the transaction submission request, the participant can determine the data corresponding to the database transaction stored by the participant itself and the data corresponding to the database transaction migrated by other nodes to the participant as to-be-submitted data, and submit the to-be-submitted data.

[0089] Further, since each participant only stores the node identifier of the migration node corresponding to itself, and does not store the node identifier of the specified migration node corresponding to the migration node of itself, the participant can also receive transaction submission requests sent by different nodes. If the participant executes each step of the transaction submission method in the present specification upon receiving each transaction submission request, the participant will repeatedly execute the transaction submission method, causing resource waste. Therefore, in the present specification, for each participant, the node can only execute the transaction submission method when the participant first receives the transaction submission request.

[0090] Specifically, when receiving the transaction submission request, the participant can determine whether the participant first receives the transaction submission request of the database transaction.

[0091] If so, the participant determines the to-be-submitted data stored by the participant itself, submits the determined to-be-submitted data, determines the submission result of the participant itself, and forwards the transaction submission request to the migration node of the participant according to the stored node identifier of the migration node. That is, the steps S104-S108 are executed.

[0092] If not, the participant can determine that the participant has received the transaction commit request. Then, the participant can query whether the participant has generated the execution result of the transaction commit request corresponding to the database transaction. If yes, the participant can directly return the query result as the execution result according to the received transaction commit request. If not, the participant can return the query result as the execution result according to the received transaction commit request after generating the execution result of the transaction commit request corresponding to the database transaction.

[0093] Based on the same idea, the present specification provides a flowchart of data migration and a flowchart of forwarding of a transaction commit request, as shown in Figure 2A and Figure 2B .

[0094] Figure 2A The flowchart of data migration provided by the present specification includes three nodes: participant A, participant B and participant C. The arrow direction is the direction of data migration, and the number on the arrow edge represents the stage. Taking the data migration process containing two stages as an example, in stage 1, the data in the participant A is migrated to the participant B and the participant C, and in stage 2, the data in the participant B is migrated to the participant C.

[0095] Figure 2B The flowchart of forwarding of a transaction commit request provided by the present specification is shown in the figure. The arrow direction is the direction of forwarding of a transaction commit request. Then, in the figure, the participant can forward the transaction commit request to the participant B and the participant C when receiving the transaction commit request. The participant B can receive the transaction commit request and forward the transaction commit request to the participant C. Then, the participant C can receive the transaction commit request sent by the participant A and the transaction commit request sent by the participant B, respectively.

[0096] Of course, the execution result returned by the participant when not receiving the transaction commit request for the first time can also be information for representing that the node has been accessed. Taking the participant B sending a transaction commit request to the participant C in Figure 2B as an example, if the participant C has received the transaction commit request sent by the participant A before receiving the transaction commit request sent by the participant B, the participant C can send information for representing that the node has been accessed to the participant B. The participant B can determine the execution result returned to the participant A according to the corresponding commit result of the participant B according to the information returned by the participant C. The information returned by the participant when not receiving the transaction commit request for the first time can be set according to needs, which is not limited in the present specification.

[0097] In addition, in the field of databases, the commit phase of a database transaction often includes two phases: a pre-commit phase and a final commit phase. Therefore, the transaction commit request described above can include a pre-commit request or a final commit request. The pre-commit phase can be regarded as a prepare phase, which is used to determine whether the operation corresponding to the database transaction has been completed and whether the to-be-committed data can be committed. The final commit phase can be regarded as a commit phase, which is used to persist the to-be-committed data. That is, the transaction log and the data corresponding to the database transaction are both stored.

[0098] Specifically, when the participant of the distributed database performs pre-commit of a database transaction, the participant can perform pre-commit on the to-be-committed data stored by the participant itself, as shown in the following step S100. Figure 3

[0099] Figure 3 A schematic diagram of a transaction commit process provided by an embodiment of the present specification.

[0100] S200: In response to the pre-commit request, pre-commit is performed on the to-be-committed data stored by the participant itself, the pre-commit result of the participant itself is determined, and the pre-commit request is forwarded to the migration node according to the node identifier of the migration node stored, so that the migration node performs pre-commit on the to-be-committed data stored by the migration node according to the pre-commit request. The migration node is another participant to which the participant migrates data.

[0101] In one or more embodiments of the present specification, when the transaction commit request received by the participant is a pre-commit request, the participant can first perform pre-commit, similar to step S100. When performing pre-commit, the participant can determine whether the database transaction corresponding to the pre-commit request is successfully executed according to the data stored by the participant, and if so, generate a transaction log corresponding to the pre-commit request, and determine that the state of the transaction log is a pre-commit state, i.e., a “prepare” state.

[0102] Similarly, the participant can also forward the pre-commit request according to the node identifier of the migration node stored, as in step S100. Of course, since the migration node also participates in the database transaction processing process, the migration node is a newly added participant. However, the coordinator does not need to update the participant information, and can also realize pre-commit of the database transaction through the transaction commit process provided by the present specification.

[0103] The migration node can also perform pre-commit according to the pre-commit request received and the data stored by the migration node.

[0104] S202: Receive the pre-commit result returned by the migration node.

[0105] ​After step S200, the participant can further receive the pre-commit result returned by the migration node after performing the pre-commit.

[0106] S204: According to the pre-commit result of the participant itself and the pre-commit result returned by the migration node, return the execution result of the pre-commit request, so that the distributed database completes the pre-commit of the database transaction according to the execution result.

[0107] When the transaction commit request received by the participant is a pre-commit request, the participant can determine that it is currently in the transaction pre-commit phase, and then the participant can determine the execution result of the pre-commit request according to the pre-commit result of the participant itself and the pre-commit result returned by the migration node, and return the execution result, so that the distributed database completes the pre-commit of the database transaction according to the execution result of the pre-commit request.

[0108] After completing the pre-commit of the database transaction, the distributed database can further generate a final commit request and perform the final commit of the database transaction. Therefore, for the participant of the distributed database, the process of executing the two-phase transaction commit can be as shown in Figure 4 .

[0109] S300: In response to the pre-commit request, pre-commit the to-be-committed data stored by the participant itself, determine the pre-commit result of the participant itself, and forward the pre-commit request to the migration node according to the stored node identifier of the migration node, so that the migration node performs pre-commit on the to-be-committed data stored by the migration node according to the pre-commit request, and the migration node is another participant to which the participant migrates data.

[0110] S302: Receive the pre-commit result returned by the migration node.

[0111] S304: According to the pre-commit result of the participant itself and the pre-commit result returned by the migration node, return the execution result of the pre-commit request, so that the distributed database completes the pre-commit of the database transaction according to the execution result.

[0112] The above steps S300-S304 can refer to the contents of the above Figure 1 and the transaction commit process in FIG. 2, and the present specification will not repeat them.

[0113] S306: In response to the final commit request, performing final commit on the participant's own stored to-be-committed data, determining the final commit result of the participant itself, and forwarding the final commit request to the migration node according to the stored node identifier of the migration node, so that the migration node performs final commit on the to-be-committed data stored by the migration node according to the final commit request, and the migration node is another participant to which the participant migrates data.

[0114] In one or more embodiments of the present specification, the participant can perform final commit of the database transaction according to the data stored by the participant after receiving the final commit request. Meanwhile, when the final commit is successful, the state of the transaction log generated in step S300 can be changed to a final commit state, i.e., a "commit" state.

[0115] Similarly, the final commit request can also be sent to the migration node according to the stored node identifier of the migration node.

[0116] It should be noted that the migration node determined in step S300 and the migration node determined in step S306 can not be completely the same. Because the data migration process and the database transaction commit process are two parallel independent processes, the data migration can also be performed during the database transaction commit. That is, for the participant, the data migration can be performed between steps S302-306, which can be data migration out or data migration in. When data is migrated out and the migration node is not the migration node determined in step S300, the participant needs to send a final commit request to more migration nodes.

[0117] Of course, for any node of the distributed database, the node can become an actual participant at any stage of the database transaction commit due to data migration in. The node only needs to execute the business according to the received request and return the result.

[0118] In addition, it is also possible that a node migrates data to other nodes according to the data migration instruction after becoming a participant, and then the participant needs to send the received request to the migration node, including one of the pre-commit request and the final commit request.

[0119] S308: Receiving the final commit result returned by the migration node.

[0120] S310: According to the final commit result of the participant itself and the final commit result returned by the migration node, returning the execution result of the final commit request, so that the distributed database completes the final commit of the database transaction according to the execution result; wherein the final commit request is generated after the distributed database completes the pre-commit of the database transaction.

[0121] When the transaction commit request received by the participant is a final commit request, the participant can determine that it is currently in the transaction final commit phase, and then determine the execution result of the final commit request according to the final commit result of the participant itself and the final commit result returned by the migrated node, and return the execution result, so that the distributed database completes the final commit of the database transaction according to the execution result of the final commit request.

[0122] However, due to the pre-commit phase and the final commit phase, the coordinator needs to wait for the return of information from each participant before executing the next step, which makes the current commit phase often take a long time. In order to avoid the above situation, the principle of transaction first write is often followed in the transaction commit phase. That is, the transaction log and data that need to be persisted can only be performed in the final commit phase, and the pre-persistence is performed in the pre-commit phase, and after receiving the final commit request, only the state of the transaction and the state of the data corresponding to the transaction need to be modified.

[0123] In the pre-commit phase, the participant can take the transaction log and data corresponding to the database transaction as the to-be-committed data, and pre-commit the to-be-committed data. In the final commit phase, the participant can change the state of the transaction and the state of the data in the to-be-committed data from the "pre-commit" state to the "final commit" state. That is, change from the "prepare" state to the "commit" state.

[0124] Based on the same idea, the present specification provides a flowchart of a transaction commit method, as shown in Figure 5 .

[0125] Figure 5 The flowchart of the transaction commit method provided by the present specification. In the figure, the coordinator is node A, and the participants are node B and node C.

[0126] Figure 5 The flowchart of the transaction commit method provided by the present specification. In the figure, the coordinator is node A, and the participants are node B and node C.

[0127] In the pre-commit phase, the coordinator A can send a pre-commit request to the participant B and the participant C.

[0128] The participant B can forward the pre-commit request according to the stored node identifier of the migrated node after receiving the pre-commit request. However, in the figure, the participant B has no migrated node before receiving the pre-commit request, so the participant B can pre-commit the to-be-committed data stored by itself according to the received pre-commit request, and return the execution result of the pre-commit request to the coordinator A.

[0129] Similarly, the participant C can also return the execution result of the pre-commit request to the coordinator A.

[0130] The coordinator A can pre-commit according to the received execution result, and when it is determined that the pre-commit is successful according to the received execution result, the distributed database can determine that the database transaction pre-commit is successful, and the phase of the database transaction can be adjusted to the final commit phase.

[0131] In the final commit phase, the coordinator A can send a final commit request to the participant B and the participant C.

[0132] Then the participant B can send the final commit request to the migration nodes: node D and node E according to the node identifier of the migration node stored by the participant B before the final commit request. The node D and the node E are new processing results, and the participant D and the participant E can respectively perform final commit on the to-be-committed data that has been pre-committed according to the final commit request, and return the final commit result to the participant B. The participant B can return the execution result of the final commit request to the participant A according to the final commit result of itself and the received final commit result.

[0133] Similarly, the participant C can also return the execution result of the final commit request to the coordinator A.

[0134] Then the coordinator A can determine whether the final commit result of the database transaction is commit success according to the received execution result of each final commit request, so as to complete the commit of the database transaction.

[0135] It should be noted that, Figure 5 The example in the above description is that the data migration process only occurs in the final commit phase. However, in the actual execution process of the database transaction, the migration phase can only occur in the pre-commit phase. It can also occur in the pre-commit phase and the final commit phase, that is, data migration occurs in the pre-commit phase and the final commit phase. That is, in the present specification, the transaction commit method can be executed only in the pre-commit phase of the transaction commit phase, and the transaction commit method can also be executed only in the final commit phase of the transaction commit phase, and of course the transaction commit method can also be executed in the pre-commit phase and the final commit phase. The specific phase in which the transaction commit method is executed can be set as needed, and the present specification does not limit this.

[0136] The above is the transaction commit method provided by one or more embodiments of the present specification, based on the same idea, the present specification also provides a corresponding transaction commit device, as shown in Figure 6 .

[0137] Figure 6 The transaction commit device provided by the present specification is a structural schematic diagram of the transaction commit device. The transaction commit device is used for a participant in a distributed database. Wherein:

[0138] The processing module 400 is configured to, in response to the transaction commit request, commit the to-be-committed data stored by the participant itself, determine a commit result of the participant itself, and forward the transaction commit request to the migration node according to the stored node identifier of the migration node, so that the migration node commits to-be-committed data stored by the migration node according to the transaction commit request, the migration node being another participant to which the participant migrates data.

[0139] The receiving module 402 is configured to receive a commit result returned by the migration node.

[0140] The committing module 404 is configured to return an execution result of the transaction commit request according to the commit result of the participant itself and the commit result returned by the migration node, so that the distributed database completes the commit of the database transaction according to the execution result.

[0141] Optionally, the processing module 400 is configured to, when the transaction commit request is received, determine whether the transaction commit request is received for the first time, if yes, commit the to-be-committed data, determine the commit result of the participant itself, and forward the transaction commit request to the migration node according to the stored node identifier of the migration node, and if no, return information that the execution result of the transaction commit request has been fed back.

[0142] Optionally, the committing module 404 is configured to determine, according to each commit result, whether there is any commit result of a failed commit, if yes, return an execution result of a failed execution of the transaction commit request, and if no, return an execution result of a successful execution of the transaction commit request.

[0143] Optionally, the processing module 400 is configured to determine, as the to-be-committed data, data corresponding to the database transaction stored by the participant itself and data corresponding to the database transaction migrated by other participants to the participant, and commit the determined to-be-committed data.

[0144] Optionally, the receiving module 402 is configured to, for each migration node, if the migration node does not return a commit result within a preset time period, determine that a commit result corresponding to the migration node is a failed commit.

[0145] Based on the same idea, Figure 3 the present specification also provides a corresponding transaction commit apparatus, as shown in Figure 7 The apparatus shown in Figure 6 is also applied to a participant of a distributed database. Figure 7

[0146] ​The preprocessing module 500 is configured to, in response to a pre-commit request, perform pre-commit on the to-be-committed data stored by the participant itself, determine a pre-commit result of the participant itself, and forward the pre-commit request to a migration node according to a node identifier of the migration node, so that the migration node performs pre-commit on the to-be-committed data stored by the migration node according to the pre-commit request, the migration node being another participant to which data of the participant is migrated.

[0147] The receiving module 502 is configured to receive a pre-commit result returned by the migration node.

[0148] The pre-commit module 504 is configured to return an execution result of the pre-commit request according to the pre-commit result of the participant itself and the pre-commit result returned by the migration node, so that the distributed database completes pre-commit of the database transaction according to the execution result.

[0149] Optionally, the apparatus further includes:

[0150] The final processing module 506 is configured to, in response to a final-commit request, perform final-commit on the to-be-committed data stored by the participant itself, determine a final-commit result of the participant itself, and forward the final-commit request to a migration node according to a node identifier of the migration node, so that the migration node performs final-commit on the to-be-committed data stored by the migration node according to the final-commit request, the migration node being another participant to which data of the participant is migrated.

[0151] The receiving module 502 is further configured to receive a final-commit result returned by the migration node.

[0152] The final-commit module 508 is configured to return an execution result of the final-commit request according to the final-commit result of the participant itself and the final-commit result returned by the migration node, so that the distributed database completes final-commit of the database transaction according to the execution result, the final-commit request being generated after the distributed database completes pre-commit of the database transaction.

[0153] The present specification also provides a computer-readable storage medium, which stores a computer program, the computer program being used to execute the transaction commit method provided in the above Figure 1 、 3 、4.

[0154] The present specification also provides an electronic device as shown in Figure 8 The present specification also provides an electronic device as shown in Figure 8At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 1 , 3 The transaction commit method described in section 4. Of course, in addition to the software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0155] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) such as a field programmable gate array (FPGA) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a piece of PLD by the designer programming it by himself, without having to ask a chip manufacturer to design and manufacture a special integrated circuit chip. Moreover, instead of manually fabricating an integrated circuit chip, this programming is now mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing a program, and the original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there are many types of HDL, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit that implements the logical method flow can be easily obtained.

[0156] The controller can be implemented in any suitable way, e.g. the controller can take the form of a microprocessor or processor and a computer readable medium storing computer readable program code, e.g. software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91 SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to being implemented in pure computer readable program code form, the controller can perfectly well be implemented by means of logic programmed into logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, etc. to perform the same functions. The controller can thus be considered as a hardware component, and the means comprised therein for performing various functions can be considered as structures within the hardware component. Alternatively, or even additionally, the means for performing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0157] The systems, apparatuses, modules or units illustrated by the above embodiments can be implemented by computer chips or entities, or products with certain functions. A typical implementation device is a computer. Specifically, the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0158] For the sake of description, the above apparatuses are described in various units by functions respectively. Of course, the functions of each unit can be implemented in one or more software and / or hardware in the implementation of the present specification.

[0159] Those skilled in the art will understand that the embodiments of the present specification can be provided as a method, a system or a computer program product. Therefore, the present specification can take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0160] The specification is presented with reference to flow diagrams and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the specification. It will be understood that each block of the flow diagrams and / or block diagrams, and combinations of blocks in the flow diagrams and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing element or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flow diagrams and / or block diagrams block or blocks. Figure 1 The flow diagrams and / or block diagrams in the specification can present a method, apparatus or computer program product according to embodiments of the specification. Flow diagrams and / or block diagrams can also present a method, apparatus or computer program product to achieve functions specified in flow diagrams and / or block diagrams block or blocks. Figure 1 The flow diagrams and / or block diagrams in the specification can present a method, apparatus or computer program product according to embodiments of the specification. Flow diagrams and / or block diagrams can also present a method, apparatus or computer program product to achieve functions specified in flow diagrams and / or block diagrams block or blocks.

[0161] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the flow diagrams and / or block diagrams block or blocks. Figure 1 The flow diagrams and / or block diagrams in the specification can present a method, apparatus or computer program product according to embodiments of the specification. Flow diagrams and / or block diagrams can also present a method, apparatus or computer program product to achieve functions specified in flow diagrams and / or block diagrams block or blocks. Figure 1 The flow diagrams and / or block diagrams in the specification can present a method, apparatus or computer program product according to embodiments of the specification. Flow diagrams and / or block diagrams can also present a method, apparatus or computer program product to achieve functions specified in flow diagrams and / or block diagrams block or blocks.

[0162] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flow diagrams and / or block diagrams block or blocks. Figure 1 The flow diagrams and / or block diagrams in the specification can present a method, apparatus or computer program product according to embodiments of the specification. Flow diagrams and / or block diagrams can also present a method, apparatus or computer program product to achieve functions specified in flow diagrams and / or block diagrams block or blocks. ​ The flow diagrams and / or block diagrams in the specification can present a method, apparatus or computer program product according to embodiments of the specification. Flow diagrams and / or block diagrams can also present a method, apparatus or computer program product to achieve functions specified in flow diagrams and / or block diagrams block or blocks.

[0163] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0164] The memory can include non-persistent memory and / or storage mechanisms such as, for example, random access memory (RAM), non-volatile memory (NVM), and / or a persistent memory such as, for example, read-only memory (ROM) or flash memory. The memory is an example of computer-readable media.

[0165] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0166] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not only include those elements, but also other elements not explicitly listed or inherent to such process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0167] Those skilled in the art will appreciate that embodiments of the present specification can be provided as methods, systems or computer program products. Therefore, the present specification can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, the present specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0168] The present specification can be described in the general context of computer-executable instructions, such as program modules, executed by computers. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media, including storage devices.

[0169] The various embodiments described in this specification are described using a numbering of embodiments approach: these are each individually integrated contributions pertaining to different aspects of the description. For each embodiment, the description focuses on the differences from the other embodiments. Each embodiment is to be read in isolation, with the understanding that the same or similar features from other embodiments can be combined with the features of the respective embodiment. In particular, the description of the system embodiments is kept relatively short, as the system embodiments are largely analogous to the method embodiments.

[0170] The above only describes the embodiments of the present specification and is not intended to limit the present specification. The present specification can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present specification shall be included in the scope of claims of the present specification.

Claims

1. A transaction commit method applied to a participant in a distributed database, the method comprising: in response to a transaction commit request, committing to-be-committed data stored by the participant itself, determining a commit result of the participant itself, and forwarding the transaction commit request to a migration node according to a node identifier of the migration node stored by the participant, so that the migration node commits to-be-committed data stored by the migration node according to the transaction commit request, the migration node being another participant to which the participant migrates data; receiving a commit result returned by the migration node; and returning an execution result of the transaction commit request according to the commit result of the participant itself and the commit result returned by the migration node, so that the distributed database completes commit of the database transaction according to the execution result. 2.The method of claim 1, wherein in response to a transaction commit request, committing to-be-committed data stored by the participant itself, determining a commit result of the participant itself, and forwarding the transaction commit request to a migration node according to a node identifier of the migration node stored by the participant, specifically comprises: when the transaction commit request is received, determining whether the transaction commit request is received for the first time; if yes, committing to the to-be-committed data, determining the commit result of the participant itself, and forwarding the transaction commit request to the migration node according to the node identifier of the migration node stored by the participant; and if no, returning information that the execution result of the transaction commit request has been fed back. 3.The method of claim 1, wherein returning an execution result of the transaction commit request specifically comprises: determining whether there is any commit result of a failed commit according to each commit result; if yes, returning an execution result of a failed execution of the transaction commit request; and if no, returning an execution result of a successful execution of the transaction commit request. 4.The method of claim 1, wherein committing to-be-committed data stored by the participant itself specifically comprises: determining data corresponding to the database transaction stored by the participant itself and data corresponding to the database transaction migrated by other participants to the participant as to-be-committed data; and committing the determined to-be-committed data. 5.The method of claim 1, wherein receiving a commit result returned by the migration node specifically comprises: for each migration node, if the migration node does not return a commit result within a preset time period, determining that a commit result corresponding to the migration node is a failed commit. 6.A transaction commit method applied to a participant in a distributed database, the method comprising: in response to a pre-commit request, pre-committing to-be-committed data stored by the participant itself, determining a pre-commit result of the participant itself, and forwarding the pre-commit request to a migration node according to a node identifier of the migration node stored by the participant, so that the migration node pre-commits to-be-committed data stored by the migration node according to the pre-commit request, the migration node being another participant to which the participant migrates data. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ receiving a pre-commit result returned by the migration node; returning an execution result of the pre-commit request according to the pre-commit result of the participant itself and the pre-commit result returned by the migration node, so that the distributed database completes the pre-commit of the database transaction according to the execution result.

7. The method of claim 6, further comprising: in response to a final commit request, performing final commit on the to-be-committed data stored by the participant itself, determining a final commit result of the participant itself, and forwarding the final commit request to the migration node according to the stored node identifier of the migration node, so that the migration node performs final commit on the to-be-committed data stored by the migration node according to the final commit request, the migration node being another participant to which the participant migrates data; receiving a final commit result returned by the migration node; returning an execution result of the final commit request according to the final commit result of the participant itself and the final commit result returned by the migration node, so that the distributed database completes the final commit of the database transaction according to the execution result; wherein the final commit request is generated after the distributed database completes the pre-commit of the database transaction.

8. A transaction commit apparatus for a participant in a distributed database, comprising: a processing module configured to, in response to a transaction commit request, perform commit on to-be-committed data stored by the participant itself, determine a commit result of the participant itself, and forward the transaction commit request to a migration node according to a stored node identifier of the migration node, so that the migration node performs commit on to-be-committed data stored by the migration node according to the transaction commit request, the migration node being another participant to which the participant migrates data; a receiving module configured to receive a commit result returned by the migration node; a commit module configured to return an execution result of the transaction commit request according to the commit result of the participant itself and the commit result returned by the migration node, so that the distributed database completes commit of the database transaction according to the execution result.

9. The apparatus of claim 8, wherein the processing module is configured to, when receiving a transaction commit request, determine whether the transaction commit request is received for the first time; if yes, perform commit on the to-be-committed data, determine the commit result of the participant itself, and forward the transaction commit request to the migration node according to the stored node identifier of the migration node; and if no, return information that the execution result of the transaction commit request has been fed back.

10. The apparatus of claim 8, wherein the commit module is configured to determine, according to each commit result, whether there is any commit result of commit failure, if yes, return an execution result that the transaction commit request fails to execute, and if no, return an execution result that the transaction commit request succeeds to execute. 11.The apparatus of claim 8, wherein the processing module is configured to determine data corresponding to the database transaction stored by the participant itself and migrated to the data corresponding to the database transaction of the participant as to-be-committed data, and commit the determined to-be-committed data. 12.The apparatus of claim 8, wherein the receiving module is configured to determine, for each migration node, that a commit result corresponding to the migration node is a commit failure if the migration node does not return the commit result within a preset time period. 13.A transaction commit apparatus for a participant in a distributed database, comprising: a preprocessing module configured to, in response to a pre-commit request, pre-commit to-be-committed data stored by the participant itself, determine a pre-commit result of the participant itself, and forward the pre-commit request to migration nodes according to stored node identifiers of the migration nodes, so that the migration nodes pre-commit to-be-committed data stored by the migration nodes according to the pre-commit request, the migration nodes being other participants to which the participant migrates data; a receiving module configured to receive pre-commit results returned by the migration nodes; a pre-commit module configured to return an execution result of the pre-commit request according to the pre-commit result of the participant itself and the pre-commit results returned by the migration nodes, so that the distributed database completes pre-commit of the database transaction according to the execution result. 14.The apparatus of claim 13, further comprising: a final processing module configured to, in response to a final commit request, final-commit to-be-committed data stored by the participant itself, determine a final commit result of the participant itself, and forward the final commit request to the migration nodes according to stored node identifiers of the migration nodes, so that the migration nodes final-commit to-be-committed data stored by the migration nodes according to the final commit request, the migration nodes being other participants to which the participant migrates data; the receiving module is further configured to receive final commit results returned by the migration nodes; a final commit module configured to return an execution result of the final commit request according to the final commit result of the participant itself and the final commit results returned by the migration nodes, so that the distributed database completes final commit of the database transaction according to the execution result; wherein the final commit request is generated after the distributed database completes pre-commit of the database transaction. 15.A computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the method of any one of claims 1-7. 16.An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the method of any one of claims 1-7 when executing the program.

Images