CN111522631A - Distributed transaction processing method, device, server and medium - Google Patents

Abstract

The embodiments of this specification provide a distributed transaction processing method, device, server and medium. The method firstly queries the primary key of the service data to be updated from the service database according to the intercepted service SQL, and then executes the service SQL to update the service data. After successful execution, a row lock is generated according to the queried primary key and the transaction identifier of the current local transaction, and the transaction identifier is saved in the log corresponding to the current local transaction in the business database. If a rollback instruction is received in the second stage , then according to the transaction identifier contained in the rollback instruction, the transaction update log of the above-mentioned local transaction is searched from the log of the business database to perform the rollback.

Description

Distributed transaction processing method, apparatus, server and medium

technical field

The embodiments of this specification relate to the field of computer technologies, and in particular, to a distributed transaction processing method, apparatus, server, and medium.

Background technique

Distributed transaction means that transaction participants, transaction-supporting servers, resource servers, and transaction managers are located on different nodes of different distributed systems. At present, the distributed transaction solutions mainly include non-intrusive and intrusive solutions to the business. Among them, the non-intrusion scheme is widely used because it has the advantage of non-intrusion to business codes, but it has high requirements on system performance.

SUMMARY OF THE INVENTION

The embodiments of this specification provide a distributed transaction processing method, device, server, and medium.

In a first aspect, the embodiments of this specification provide a distributed transaction processing method, including: querying a primary key of service data to be updated from a service database according to intercepted service SQL; executing the service SQL for the service to be updated The data is updated. After the execution is successful, a row lock for the updated business data is generated according to the queried primary key and the transaction identifier of the current local transaction, and the transaction identifier is saved in the business database corresponding to the In the log of the current local transaction; if a rollback instruction is received, the transaction update log of the current local transaction is queried from the log of the business database according to the transaction identifier contained in the rollback instruction, and according to the The transaction update log rolls back the current local transaction.

In a second aspect, the embodiments of this specification provide a distributed transaction processing device, including: a query module for querying the primary key of business data to be updated from a business database according to intercepted business SQL; a transaction processing module for Execute the business SQL to update the business data to be updated. After the execution is successful, a row lock for the updated business data is generated according to the queried primary key and the transaction identifier of the current local transaction, and the transaction identifier is is stored in the log corresponding to the current local transaction of the business database; the rollback module is configured to, if a rollback instruction is received, retrieve data from the business database according to the transaction identifier included in the rollback instruction The transaction update log of the current local transaction is queried in the log of the current local transaction, and the current local transaction is rolled back according to the transaction update log.

In a third aspect, an embodiment of this specification provides a server, including: a memory, a processor, and a computer program stored in the memory and running on the processor, where the processor implements the first aspect when executing the program Steps of the provided distributed transaction method.

In a fourth aspect, embodiments of the present specification provide a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, implements the steps of the distributed transaction processing method provided in the first aspect.

In the distributed transaction processing method provided by an embodiment of this specification, the primary key of the service data to be updated is first queried from the service database according to the intercepted service SQL, and then the service SQL is executed to update the service data. The primary key and the transaction identifier of the current local transaction generate a row lock for the updated business data, and save the transaction identifier in the log corresponding to the local transaction in the above-mentioned business database. If a rollback instruction is received in the second stage, Then, according to the transaction identifier included in the rollback instruction, the transaction update log of the local transaction can be found from the log of the business database to perform rollback. This processing process does not require special query and data mirroring of business data before and after the update in the first stage of transaction processing, which reduces the operation steps of the transaction processing process, and uses database replication technology to perform local transactions according to the transaction update log in the second stage of transaction processing. rollback. In this way, the transaction processing flow of the non-intrusive mode can be effectively optimized while effectively ensuring the normal realization of the two-phase distributed transaction, which is beneficial to reduce the consumption of system performance. In addition, because there is no need to store data mirroring in the business database, the system performance consumption is independent of the amount of data to be updated, the impact of the amount of data requested to be updated on the system performance consumption can be eliminated, and the system performance consumption can be further reduced.

Description of drawings

FIG. 1 is a schematic diagram of an application scenario of a distributed transaction processing method provided by an embodiment of the present specification;

FIG. 2 is a flow chart of steps of the distributed transaction processing method provided in the first aspect of the embodiment of the present specification;

FIG. 3 is an operational flowchart of the distributed transaction processing method provided in the first aspect of the embodiment of the present specification;

FIG. 4 is a block diagram of a module of a distributed transaction processing apparatus according to the second aspect of the embodiment of the present specification;

FIG. 5 is a schematic structural diagram of a server according to a third aspect of an embodiment of the present specification.

Detailed ways

With the development of the business, the business becomes more and more complex, and many business platforms have divided the business into services, so that a business activity usually needs to call multiple services and access multiple databases to complete. Taking the transfer scenario in the financial business scenario as an example, the transfer service needs to complete the following operations: 1. Invoke the transaction system service to create a transaction order; 2. Invoke the payment system to record the payment details; 3. Invoke the accounting system to perform A deduction; 4. Call the accounting system to execute B to add money. The above four operations need to access four databases across three business systems. In this scenario, data consistency across services and databases can be resolved through distributed transaction middleware.

Distributed transaction middleware has no intrusive mode, such as the AT mode of the distributed transaction open source product Seata, or the FMT (Framework-managed transaction) mode of DTX (Distributed Transaction-eXtended). The biggest advantage of AT/FMT mode is that it is transparent and non-invasive to the application, but the disadvantage is that the performance overhead is high. The embodiments of this specification provide a distributed transaction processing method in a non-intrusive mode, which can effectively optimize the transaction processing flow in the non-intrusive mode and reduce system performance overhead.

FIG. 1 shows a schematic diagram of an application scenario of the distributed transaction processing method provided by the embodiment of this specification. The distributed system shown in FIG. 1 includes a server 100 as a coordinator, and a server 101 and a server 102 as participants. Both the server 101 and the server 102 are connected to the server 100 through a network. There may be multiple participants, and the specific number is determined according to the actual application scenario. The number of servers serving as participants in FIG. 1 is for illustration only and is not limited. When a transaction needs to be split into multiple sub-transactions and executed by multiple different servers, the transaction can become a global transaction, and the corresponding sub-transactions can be called branch transactions. The server responsible for the generation of global transactions and the processing of branch transactions can be called the coordinator. The server responsible for the processing of branch transactions can act as a participant.

The distributed transaction processing method provided by the embodiments of this specification can be applied to the server as a participant in the above-mentioned distributed system, as a distributed transaction middleware, to realize a distributed transaction processing process without business intrusion.

In order to better understand the technical solutions provided by the embodiments of the present specification, the technical solutions of the embodiments of the present specification will be described in detail below with reference to the accompanying drawings and specific embodiments. The detailed description of the technical solutions of the embodiments is not a limitation on the technical solutions of the present specification, and the embodiments of the present specification and the technical features in the embodiments may be combined with each other under the condition of no conflict. In the embodiments of the present specification, the term "plurality" means "two or more", that is, the case of two or more than two is included.

In the first aspect, FIG. 2 shows a flowchart of a distributed transaction processing method provided by an embodiment of the present specification, which is applied to a server as a transaction participant. Referring to FIG. 2, the method may include the following steps S101-S103.

Step S101, according to the intercepted service SQL, query the primary key of the service data to be updated from the service database.

When a user triggers a business operation that needs to be coordinated and completed by multiple participants through the application program installed on the user terminal, such as a payment operation, a transfer operation, etc., the client terminal will send a business processing request to its server side. After the server side receives the business processing request, as the transaction initiator, the coordinator registers the global transaction with the transaction manager. In addition, the transaction manager assigns a transaction identifier for uniquely identifying the global transaction, namely txid (transaction id), to the global transaction, and sends it to the server side of the application for storage.

After the transaction initiator opens the global transaction, it calls the participant to execute the business SQL (Structured QueryLanguage) to realize the business operation triggered by the user. Business SQL is the SQL statement for executing business operations. A global transaction includes multiple transaction branches, each transaction branch corresponds to a participant, and the transaction initiator generates corresponding business SQL for each transaction branch, so as to execute the business SQL on the corresponding participant to complete the branch transaction. For example, the global transaction is that A transfers 30 yuan to B, which includes two transaction branches. One of them is to deduct 30 yuan from account A. The business SQL executed by the transaction branch is to reduce the balance of account A in the corresponding business database by 30. The other is to add 30 yuan to account B. The business executed by the branch office SQL is to add 30 to the balance of account B in the corresponding business database.

In the embodiment of this specification, in the first stage of transaction execution, by intercepting the execution of the participant's business SQL, before the business SQL is executed, the primary key of the business data to be updated is queried from the business database according to the intercepted business SQL, for Generate row locks based on these primary keys to ensure that the data corresponding to these primary keys are locked before the transaction is finally committed, so as to avoid dirty data.

Specifically, as shown in Figure 3, the semantics of the business SQL can be parsed first, and then the table metadata can be extracted. The purpose of parsing the business SQL semantics is to find the business data to be updated by the business, and the purpose of extracting table metadata is to find the primary key and unique constraint key of the business table in the business database, so as to facilitate the generation of row locks. Table metadata can include schema information of the table, such as the primary key, unique key, and column name of the table. In this way, the select part of the SQL statement can be generated through the primary key column name of the table, and the where part can be intercepted from the business SQL to generate the SQL statement for querying the primary key, so that the SQL statement can be executed to query the primary key list of the business data to be updated. After the primary key of the business data to be updated is queried, the local transaction of the participant can be started, and the following step S102 is performed, without querying and saving the data mirror of the business data before updating.

It can be understood that the business database managed by the participant stores business tables, and the business tables are stored in the form of two-dimensional tables. Each row in the business table is a record, or a tuple, and each column is a field, or an attribute.

Step S102, the business data to be updated is updated by executing the business SQL. After the execution is successful, a row lock for the updated business data is generated according to the queried primary key and the transaction identifier of the current local transaction, and the The transaction identifier is stored in a log of the business database corresponding to the current local transaction.

As shown in FIG. 3 , after the primary key of the business data to be updated is queried, a local transaction can be opened to perform database operations. By executing the business SQL, the corresponding business data in the business database (ie, the business DB in FIG. 3 ) is updated. In addition, in order to ensure that the data corresponding to these primary keys are locked before the transaction is committed, so as not to cause dirty data, after the business SQL is successfully executed, it is necessary to generate a post-update transaction identifier based on the primary key queried in the above step S101 and the transaction identifier of the current local transaction. The row lock of the business data, and the generated row lock is stored. In the specific implementation process, the generated row lock may be sent to the transaction server for storage, or may be stored in the business database. For example, the FMT same-database mode is stored in the business database, and the Seata AT mode is stored in the transaction server.

Thereafter, the local transaction can be submitted, that is, a confirmation of the successful execution of the local transaction is submitted. So that the transaction initiator can trigger the two-phase commit/rollback operation according to the confirmation information submitted by each participant.

It should be noted that, in the above step S102, after the service SQL is executed, there is no need to query and save the data image of the updated service data.

In the embodiments of this specification, the master-slave replication function is enabled for the business databases managed by the participants, and the business databases automatically generate local transaction logs for recording all local transactions and the modifications made to the database by each local transaction. Therefore, during the execution of each local transaction, the business database automatically generates a local transaction log containing data mirroring before and after business data update when executing business SQL, and stores it in the file system of the server where the business database is located. Of course, the local transaction log recorded by the business database includes other data, such as timestamps, in addition to the data mirrors before and after the business data is updated. The records of different data types are slightly different.

The local transaction log automatically generated by the business database belongs to streaming data and contains the start and end marks of the local transaction. By identifying the start and end signs of a local transaction, one can distinguish one local transaction, but the corresponding relationship between the log of the local transaction and the global transaction is unknown. Therefore, in order to find the required local transaction log from the log of the business database, when the row lock is generated, the transaction identifier of the currently executed local transaction needs to be saved to the log corresponding to the local transaction in the business database middle. In this way, by matching the transaction identifier inserted in the local transaction log in the log of the business database, the transaction update log corresponding to the current local transaction to be rolled back can be found.

That is to say, in the above step S102, the implementation process of generating a row lock for the updated business data according to the queried primary key and the transaction identifier of the current local transaction may include: obtaining the transaction identifier of the current local transaction; The primary key and the transaction identifier are inserted into the preset row lock record table in the business database. In the specific implementation process, the table name of the business table where the updated business data is located and the primary key information of the updated business data in the business table are recorded in the row lock record table corresponding to the transaction identifier of the current local transaction. In this way, the business data is marked by row locks and will not be accessed by other distributed transactions, avoiding dirty data when accessing data, and improving the strong consistency of distributed transactions accessing data. It can be understood that the name of the business table is unique, and the primary key value within each business table is also unique. Therefore, a single item can be uniquely determined by the name of the business table and the primary key information of the updated business data in the business table. data.

For example, you can use the insert statement in the log to insert two fields into the insert, one is the transaction identifier, and the other is the value of the global lock. The value of the global lock is the table name of the business table where the updated business data is located and the primary key information of the updated business data in the business table, such as a string composed of the two. At the same time, the insert statement is also recorded in the log of the business database corresponding to the current local transaction, so that the transaction identifier of the current local transaction can be saved in the log of the current local transaction.

After receiving the transaction identifier of the global transaction assigned by the transaction manager, the transaction initiator can save the transaction identifier in the context of the thread to which the application belongs. Before performing the above step S101, when invoking the service provided by the participant to request the participant to execute the corresponding branch transaction, the transaction initiator will send the transaction identifier to the participant, and the transaction identifier can be intercepted at the service entry of the participant, and saved in the context of the owning thread. When a row lock needs to be generated, the transaction identifier can be obtained from the context, and the transaction identifier and the primary key queried in the above step S101 are correspondingly inserted into the preset row lock record table in the business database.

After a participant submits a local transaction, one-phase transaction processing is completed. If the transaction initiator detects that more than one participant fails to submit the local transaction on time, it means that there is an error in the first stage of the participant, triggers the rollback operation in the second stage, and sends a rollback instruction to each participant, so that the participant executes the following Step S103. If the transaction initiator detects that all the participants have submitted the local transaction, which means that all the participants in the first stage have successfully executed the transaction, then the second-stage commit operation is triggered, and a commit instruction is sent to each participant, so that the participants perform the following step S104 .

Step S103, if a rollback instruction is received, query the transaction update log of the current local transaction from the log of the business database according to the transaction identifier included in the rollback instruction, and update the log according to the transaction The current local transaction is rolled back.

When the participant receives the two-stage rollback instruction, it needs to roll back the local transaction submitted in the above step S102, and restore the business data updated by the business SQL in the step S102 to the state before the update. In the embodiment of this specification, the mirror data before and after the update required for rollback are obtained from the log of the business database. It should be noted that, for different database types, the method of querying the update log is different, and the query is based on the interface submitted by the actual database type.

The rollback command sent by the transaction initiator contains the transaction identifier of the global transaction to be rolled back. The above process of querying the transaction update log of the current local transaction from the log of the business database according to the transaction identifier contained in the rollback instruction may include: extracting the transaction identifier from the rollback instruction; in the log of the business database, searching for The log containing the transaction identifier is to find the local transaction log containing the transaction identifier in the rollback instruction; the found local transaction log is used as the transaction update log of the current local transaction.

The logs of the business database include logs of multiple local transactions, that is, multiple local transaction logs, and different local transaction logs are distinguished by the start and end flags of the local transactions. Each local transaction log stores the transaction identifier of the local transaction, that is, the transaction identifier of the global transaction associated with the local transaction. Therefore, by matching the transaction identifier, the local transaction log can be filtered out of the local transaction log. The local transaction log for the local transaction that was minor rolled back.

Further, after finding the transaction update log of the current local transaction, the process of rolling back the current local transaction according to the transaction update log may include: from the transaction update log, extracting the business data to be updated before updating and updating After the data mirroring; through the data mirroring before and after the update, the current local transaction is rolled back. It can be understood that the transaction update log of the business database may include time stamps and data mirroring before and after the business data is updated.

In the specific implementation process, first, the dirty write needs to be verified. The method of verifying dirty writing is to compare the updated mirror data extracted from the transaction update log with the current value of the business data in the business database. If the two pieces of data are completely consistent, it means that there is no dirty writing. Inconsistent, it means that there is dirty writing. If dirty writing occurs, manual processing is required, and the extracted and updated mirror data cannot be used to roll back business data.

Then, restore the business data. If no dirty writing occurs, the business data is rolled back using the pre-update mirror data extracted from the transaction update log to restore the business data to the pre-update value.

Finally, remove the intermediate data. After the business data is restored, all the intermediate data saved in the first stage can be deleted to complete the rollback operation. Since the distributed transaction processing method provided by the embodiments of this specification only saves row locks in one stage, it is only necessary to delete the row locks.

Step S104, if the participant receives the commit instruction, it deletes the generated row lock. Since the business SQL has been submitted to the business database in the first stage, the second stage submission only needs to delete the intermediate data saved in the first stage. Since the distributed transaction processing method provided by the embodiments of this specification only saves row locks in one stage, it is only necessary to delete the row locks. Compared with the AT mode of Seata or the FMT mode of DTX, the intermediate data that needs to be deleted is reduced, which is beneficial to reduce the operation steps of the transaction processing process, thereby reducing the consumption of system performance.

The distributed transaction processing method provided by the embodiments of this specification does not need to query and save the data mirroring of the business data before and after the update in the first stage of the distributed transaction processing, which reduces the operation steps of the transaction processing process, and uses the database replication technology. The second stage of the rollback is performed by looking up the transaction update log in the log of the business database by the transaction identifier. Compared with Seata's AT mode or DTX's FMT mode, this can effectively optimize the transaction processing flow of non-intrusive mode while ensuring the normal realization of two-phase distributed transactions, which is beneficial to reduce the consumption of system performance. In addition, because there is no need to store the data images before and after the business data update in the data file of the business database, the system performance consumption has nothing to do with the data volume of the business SQL update, which can eliminate the impact of the requested update data volume on the system performance consumption. It is beneficial to further reduce system performance consumption.

In the second aspect, based on the same inventive concept as the distributed transaction processing method provided by the embodiments of the first aspect, the embodiments of the present specification further provide a distributed transaction processing apparatus that runs on a server that is a transaction participant. As shown in Figure 4, the distributed transaction processing device 40 includes:

The query module 41 is used to query the primary key of the service data to be updated from the service database according to the intercepted service SQL;

The transaction processing module 42 is configured to update the business data to be updated by executing the business SQL, and after successful execution, generate a row lock for the updated business data according to the queried primary key and the transaction identifier of the current local transaction , and save the transaction identifier to the log of the business database corresponding to the current local transaction;

The rollback module 43 is configured to, if a rollback instruction is received, query the transaction update log of the current local transaction from the log of the business database according to the transaction identifier contained in the rollback instruction, and The transaction update log rolls back the current local transaction.

In an optional embodiment, the rollback module 43 includes: a log query submodule 431, configured to search for a local transaction log containing the transaction identifier in the rollback instruction from the log of the business database ; Use the found local transaction log as the transaction update log of the local transaction.

In an optional embodiment, the rollback module 43 includes:

Extraction submodule 432, for extracting the data images of the service data to be updated before and after the update from the transaction update log;

The rollback submodule 433 is configured to roll back the current local transaction through the data mirroring before and after the update.

In an optional embodiment, the transaction processing module 42 is configured to: obtain the transaction identifier of the current local transaction; insert the queried primary key and the transaction identifier into the business database In the preset row lock record table.

In an optional embodiment, the above-mentioned distributed transaction processing apparatus 40 further includes: a commit module 44, configured to delete the row lock if a commit instruction is received.

It should be noted that, in the distributed transaction processing apparatus 40 provided by the embodiments of this specification, the specific manner in which each module performs operations has been described in detail in the method embodiments provided in the first aspect, and the specific implementation process may refer to the above The method embodiments provided by the first aspect will not be described in detail here.

In the third aspect, based on the same inventive concept as the distributed transaction processing method provided by the foregoing embodiments, an embodiment of the present specification further provides a server. As shown in FIG. 5 , the server includes a memory 504, one or more processors 502, and a computer program stored in the memory 504 and executable on the processor 502. When the processor 502 executes the program, the foregoing first aspect provides The steps of any embodiment of the distributed transaction processing method.

5, the bus architecture (represented by bus 500), bus 500 may include any number of interconnected buses and bridges, bus 500 will include one or more processors represented by processor 502 and memory 504 The various circuits of the memory are linked together. The bus 500 may also link together various other circuits, such as peripherals, voltage regulators and power management circuits, etc., which are well known in the art and therefore will not be described further herein. Bus interface 505 provides an interface between bus 500 and receiver 501 and transmitter 503 . Receiver 501 and transmitter 503 may be one and the same element, a transceiver, providing a means for communicating with various other devices over a transmission medium. The processor 502 is responsible for managing the bus 500 and general processing, while the memory 504 may be used to store data used by the processor 502 in performing operations.

It can be understood that the structure shown in FIG. 5 is only for illustration, and the server provided in this embodiment of the present specification may further include more or less components than those shown in FIG. 5 , or have different configurations from those shown in FIG. 5 . Each component shown in FIG. 5 can be implemented in hardware, software, or a combination thereof.

In the fourth aspect, based on the same inventive concept as the distributed transaction processing method provided in the foregoing embodiments, the embodiments of the present specification further provide a computer-readable storage medium on which a computer program is stored, and the program is executed by a processor When implementing the steps of any implementation manner of the distributed transaction processing method provided in the first aspect above.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The specification is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the specification. It will be understood that each flow and/or block in the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce A device that implements the functions specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory result in an article of manufacture comprising the instruction apparatus, the instructions The device implements the functions specified in the flow or flows of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in the flow or blocks of the flowcharts and/or the block or blocks of the block diagrams.

While the preferred embodiments of this specification have been described, additional changes and modifications to these embodiments may occur to those skilled in the art once the basic inventive concepts are known. Therefore, the appended claims are intended to be construed to include the preferred embodiment and all changes and modifications that fall within the scope of this specification.

Obviously, those skilled in the art can make various changes and modifications to this specification without departing from the spirit and scope of this specification. Thus, provided that these modifications and variations of the present specification fall within the scope of the claims of the present specification and technical equivalents thereof, the present specification is also intended to include these modifications and variations.

Claims (12)

1. A distributed transaction processing method, comprising:

inquiring a main key of service data to be updated from a service database according to the intercepted service SQL;

updating the service data to be updated by executing the service SQL, generating a row lock aiming at the updated service data according to the inquired main key and the transaction identifier of the current local transaction after the execution is successful, and storing the transaction identifier into a log of the service database corresponding to the current local transaction;

and if a rollback instruction is received, inquiring a transaction update log of the current local transaction from the logs of the service database according to a transaction identifier contained in the rollback instruction, and rolling back the current local transaction according to the transaction update log.

2. The method of claim 1, wherein the querying a transaction update log of the current local transaction from a log of the traffic database according to a transaction identifier included in the rollback instruction comprises:

searching a local transaction log containing the transaction identifier in the rollback instruction from logs of a service database;

and taking the searched local transaction log as a transaction update log of the current local transaction.

3. The method of claim 1, the rolling back the current local transaction from the transaction update log, comprising:

extracting data mirror images of the service data to be updated before and after updating from the transaction update log;

and rolling back the current local transaction through the data mirror images before and after the update.

4. The method of claim 1, wherein generating a row lock for the updated business data according to the queried primary key and the transaction identifier of the current local transaction comprises:

acquiring a transaction identifier of the current local transaction;

and inserting the inquired primary key and the transaction identifier into a row lock record table preset in the service database.

5. The method of claim 1, further comprising:

and if a submitting instruction is received, deleting the row lock.

6. A distributed transaction processing apparatus, comprising:

the query module is used for querying a main key of the service data to be updated from the service database according to the intercepted service SQL;

the transaction processing module is used for updating the service data to be updated by executing the service SQL, generating a row lock aiming at the updated service data according to the inquired main key and the transaction identifier of the current local transaction after the execution is successful, and storing the transaction identifier into a log of the service database corresponding to the current local transaction;

and the rollback module is used for inquiring the transaction update log of the current local transaction from the logs of the service database according to the transaction identifier contained in the rollback instruction and performing rollback on the current local transaction according to the transaction update log if the rollback instruction is received.

7. The apparatus of claim 6, the rollback module comprising:

the log query submodule is used for searching a local transaction log containing the transaction identifier in the rollback instruction from the logs of the service database; and taking the searched local transaction log as a transaction update log of the local transaction.

8. The apparatus of claim 6, the rollback module comprising:

the extraction submodule is used for extracting data mirror images of the service data to be updated before and after updating from the transaction update log;

and the rollback sub-module is used for rolling back the current local transaction through the data mirror images before and after the update.

9. The apparatus of claim 6, the transaction processing module to:

acquiring a transaction identifier of the current local transaction;

and inserting the inquired primary key and the transaction identifier into a row lock record table preset in the service database.

10. The apparatus of claim 6, further comprising:

and the submitting module is used for deleting the row lock if a submitting instruction is received.

11. A server, comprising: memory, processor and computer program stored on the memory and executable on the processor, the processor implementing the steps of the method of any one of claims 1-5 when executing the program.

12. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 5.

Images