CN111522631B - Distributed transaction processing method, device, server and medium - Google Patents
Distributed transaction processing method, device, server and medium Download PDFInfo
- Publication number
- CN111522631B CN111522631B CN202010209587.2A CN202010209587A CN111522631B CN 111522631 B CN111522631 B CN 111522631B CN 202010209587 A CN202010209587 A CN 202010209587A CN 111522631 B CN111522631 B CN 111522631B
- Authority
- CN
- China
- Prior art keywords
- transaction
- log
- service
- business
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 18
- 238000000034 method Methods 0.000 claims abstract description 31
- 238000012545 processing Methods 0.000 claims description 35
- 238000004590 computer program Methods 0.000 claims description 11
- 230000006870 function Effects 0.000 claims description 7
- 238000003860 storage Methods 0.000 claims description 4
- 238000005096 rolling process Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 10
- 239000003999 initiator Substances 0.000 description 9
- 238000012986 modification Methods 0.000 description 6
- 230000004048 modification Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000010076 replication Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The embodiment of the specification provides a distributed transaction processing method, a device, a server and a medium, wherein the method firstly queries a primary key of service data to be updated from a service database according to an intercepted service SQL, then executes the service SQL to update the service data, generates a row lock according to the queried primary key and a transaction identifier of a current local transaction after successful execution, stores the transaction identifier into a log of the service database corresponding to the current local transaction, and if a rollback instruction is received in two stages, searches a transaction update log of the local transaction from the log of the service database according to the transaction identifier contained in the rollback instruction to rollback.
Description
Technical Field
Embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a distributed transaction processing method, device, server, and medium.
Background
Distributed transactions refer to the participants of the transaction, the servers supporting the transaction, the resource servers, and the transaction manager being located on different nodes of different distributed systems, respectively. The current distributed transaction solutions mainly have non-invasive and invasive schemes for services. The non-invasive scheme is widely applied due to the advantage of non-invasive to service codes, but has high requirements on system performance.
Disclosure of Invention
The embodiment of the specification provides a distributed transaction processing method, a distributed transaction processing device, a server and a medium.
In a first aspect, embodiments of the present disclosure provide a distributed transaction processing method, including: 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 for the updated service data according to the queried main key and the transaction identifier of the current local transaction after the execution is successful, and storing the transaction identifier into a log corresponding to the current local transaction of the service database; and if the rollback instruction is received, inquiring a transaction update log of the current local transaction from a log of the service database according to the transaction identifier contained in the rollback instruction, and rollback the current local transaction according to the transaction update log.
In a second aspect, embodiments of the present disclosure provide a distributed transaction processing apparatus, including: the query module is used for querying a main key of 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 for the updated service data according to the queried main key and the transaction identifier of the current local transaction after successful execution, and storing the transaction identifier into a log corresponding to the current local transaction of the service database; and the rollback module is used for inquiring the transaction update log of the current local transaction from the log of the service database according to the transaction identifier contained in the rollback instruction if the rollback instruction is received, and rollback the current local transaction according to the transaction update log.
In a third aspect, embodiments of the present disclosure provide a server, including: a memory, a processor and a computer program stored on the memory and executable on the processor, which when executed implements the steps of the distributed transaction method provided in the first aspect described above.
In a fourth aspect, embodiments of the present description provide a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the distributed transaction method provided in the first aspect described above.
According to the distributed transaction processing method provided by the embodiment of the specification, firstly, a primary key of service data to be updated is queried from a service database according to the intercepted service SQL, then the service SQL is executed to update the service data, after the service SQL is successfully executed, a row lock aiming at the updated service data is generated according to the queried primary key and a transaction identifier of a current local transaction, the transaction identifier is stored into a log corresponding to the local transaction of the service database, and if a rollback instruction is received in two stages, the transaction update log of the local transaction can be searched from the log of the service database according to the transaction identifier contained in the rollback instruction to rollback. The processing process does not need to specially inquire and save the data mirror image of the business data before and after updating in one stage of the transaction processing, reduces the operation steps of the transaction processing flow, and utilizes the database replication technology to roll back the local transaction according to the transaction update log in two stages of the transaction processing. Therefore, the transaction processing flow of the non-invasive mode can be effectively optimized while the normal realization of two stages of distributed transactions is effectively ensured, and the consumption of system performance is reduced. In addition, because the data mirror image does not need to be specially stored in the service database, the system performance consumption is irrelevant to the data quantity needing to be updated, the influence of the data quantity requesting to be updated on the system performance consumption can be eliminated, and the system performance consumption is further reduced.
Drawings
Fig. 1 is a schematic diagram of an application scenario of a distributed transaction processing method according to an embodiment of the present disclosure;
FIG. 2 is a flowchart illustrating steps of a method for distributed transaction processing according to a first aspect of the present embodiment;
FIG. 3 is a flowchart illustrating one operation of the distributed transaction processing method according to the first aspect of the present embodiment;
FIG. 4 is a block diagram of a distributed transaction processing arrangement according to a second aspect of the embodiments of the present disclosure;
fig. 5 is a schematic structural diagram of a server according to a third aspect of the embodiments of the present disclosure.
Detailed Description
With the development of services, the services are more and more complex, and many service platforms split services, so that one service activity can be completed only by calling a plurality of services and accessing a plurality of databases. Taking a money transfer scenario in a financial service scenario as an example, the money transfer service needs to complete the following operations: 1. calling a transaction system service to create a transaction order; 2. invoking a payment system to record payment details; 3. calling an accounting system to execute A money deduction; 4. and calling the accounting system to execute B money adding. The above four operations are to access four databases across three business systems. In such a scenario, the data consistency problem across services, across databases, may be solved by distributed transaction middleware.
The distributed transaction middleware has an intrusion mode such as an AT mode of a distributed transaction open source product, seata, or an FMT (frame-managed transaction) mode of DTX (Distributed Transaction-eXtended). The AT/FMT mode has the greatest advantage of being transparent to the application and non-intrusive, but has the disadvantage of having a large performance overhead. The embodiment of the specification provides a distributed transaction processing method in a non-invasive mode, which can effectively optimize the transaction processing flow in the non-invasive mode and reduce the system performance overhead.
Fig. 1 is a schematic diagram of an application scenario of a distributed transaction processing method according to an embodiment of the present disclosure. In the distributed system shown in fig. 1, a server 100 as a coordinator, and a server 101 and a server 102 as participants are included. Server 101 and server 102 are connected to server 100 via a network. The number of the participants may be plural, and the specific number is determined according to the actual application scenario, and the number of the servers as the participants in fig. 1 is only illustrative and not limiting. When a transaction needs to be split into multiple sub-transactions, which are executed by multiple different servers, the transaction may become a global transaction, and the corresponding sub-transactions may be referred to as branch transactions. The server responsible for the generation of global transactions, as well as the processing of branch transactions, may be referred to as a coordinator. The server responsible for the processing of the branch transaction may act as a participant.
The distributed transaction processing method provided by the embodiment of the specification can be applied to the server serving as a participant in the distributed system and serve as a distributed transaction middleware to realize a distributed transaction processing flow which is non-invasive to the business.
In order to better understand the technical solutions provided by the embodiments of the present specification, the following detailed description of the technical solutions of the embodiments of the present specification is made through the accompanying drawings and the specific embodiments, and it should be understood that the specific features of the embodiments of the present specification are detailed descriptions of the technical solutions of the embodiments of the present specification, and not limit the technical solutions of the present specification, and the technical features of the embodiments of the present specification may be combined with each other without conflict. In the present specification embodiment, the term "plurality" means "two or more", that is, includes a case of two or more.
In a first aspect, fig. 2 shows a flowchart of a distributed transaction processing method according to an embodiment of the present disclosure, which is applied to a server as a party to a transaction. Referring to fig. 2, the method may include the following steps S101-S103.
Step S101, inquiring a main key of service data to be updated from a service database according to the intercepted service SQL.
The user triggers the business operations such as payment operation, transfer operation and the like which are required to be completed by the coordination of a plurality of participants through an application program installed on the user terminal, namely a client, and the client sends a business processing request to a server side of the client. After receiving the service processing request, the server registers the global transaction as a transaction initiator, namely a coordination direction transaction manager. And, the transaction manager will assign a transaction identifier, txid (transaction id), to the global transaction for uniquely identifying the global transaction, and send it to the server side of the application for saving.
After the transaction initiator opens the global transaction, the user-triggered business operation is realized by calling the participant to execute the business SQL (Structured Query Language). The service SQL is an SQL statement for executing service operation. The global transaction includes a plurality of transaction branches, each transaction branch corresponding to a participant, and the transaction initiator generates a corresponding business SQL for each transaction branch, thereby executing the business SQL at the corresponding participant to complete the branch transaction. For example, a global transaction is a 30-element transfer to B, then two transaction branches are included. One is deducting 30 elements from account A, the business SQL executed by the branch transaction is the balance of account A in the corresponding business database minus 30, the other is adding 30 elements to account B, and the business SQL executed by the branch transaction is the balance of account B in the corresponding business database plus 30.
In the embodiment of the specification, in a stage of transaction execution, by intercepting execution of a participant service SQL, before the execution of the service SQL, a primary key of service data to be updated is queried from a service database according to the intercepted service SQL, and the primary key is used for generating a row lock according to the primary keys, so that data corresponding to the primary keys is ensured to be locked before the final submission of the transaction, so that dirty data is avoided.
Specifically, as shown in FIG. 3, the semantics of the business SQL may be parsed and then the table metadata extracted. The purpose of parsing the service SQL semantics is to facilitate finding service data to be updated by the service, while the purpose of extracting table metadata is to find primary keys and unique constraint keys of service tables in a service database, so that row locks are generated conveniently. The table metadata may include Schema information for the table, such as a primary key, a unique key, and a column name for the table. Thus, the selected part of the SQL statement can be generated through the primary key column name of the table, and the sphere part is intercepted from the service SQL, so that the SQL statement for inquiring the primary key can be generated, and the SQL statement is executed to inquire the primary key list of the service data to be updated. After the primary key of the service data to be updated is queried, the local transaction of the participant can be started, and the following step S102 is executed without querying and saving the data mirror image of the service data before updating.
It will be appreciated that the business database managed by the participants stores business tables, which are stored in the form of two-dimensional tables. Each row in the service table is a record, or tuple, and each column is a field, or attribute.
Step S102, updating the service data to be updated by executing the service SQL, generating a row lock for the updated service data according to the queried main key and the transaction identifier of the current local transaction after the execution is successful, and storing the transaction identifier into a log corresponding to the current local transaction of the service database.
As shown in fig. 3, after the primary key of the service data to be updated is queried, the local transaction can be started so as to perform database operation. By executing the service SQL, the corresponding service data in the service database (i.e., the service DB in fig. 3) is updated. In addition, in order to ensure that the data corresponding to the primary keys are locked before the transaction is submitted so as to avoid dirty data, after the execution of the service SQL is successful, a row lock for the updated service data needs to be generated according to the primary key queried in the step S101 and the transaction identifier of the current local transaction, and the generated row lock is stored. In the implementation process, the generated line lock can be sent to a transaction server for storage, and can also be stored in a transaction database. For example, the FMT co-library schema is stored in a business database and the Seata AT schema is stored in a transaction server.
Thereafter, the local transaction may be committed, i.e., an acknowledgment that the local transaction was successfully executed is committed. So that the transaction initiator triggers a two-phase commit/rollback operation based on the acknowledgement submitted by the respective participants.
It should be noted that, in the step S102, after the execution of the service SQL, the data mirror image of the updated service data does not need to be queried and stored.
In the embodiment of the present disclosure, the business database managed by the participant has a master-slave replication function, and the business database automatically generates a local transaction log for recording all local transactions and modifications made to the database by each local transaction. Therefore, in the execution process of each local transaction, the service database automatically generates a local transaction log containing data images before and after service data update when executing the service SQL, and the local transaction log is stored in a file system of a server where the service database is located. Of course, the local transaction log of the service database record includes other data, such as time stamps, in addition to the data images before and after the service data update, and the different data types record slightly differ.
The local transaction log automatically generated by the service database belongs to stream data and comprises start and end marks of the local transaction. By identifying the start and end flags of the local transaction, individual local transactions can be resolved, but the correspondence of the log of local transactions to global transactions is unknown. Therefore, in order to be able to find the required local transaction log from the logs of the service database, it is necessary to save the transaction identifier of the local transaction currently being executed to the log corresponding to the local transaction in the service database while generating the line lock. In this way, by matching the transaction identifier inserted in the local transaction log in the log of the transaction database, a transaction update log corresponding to the local transaction currently to be rolled back can be found.
That is, in the step S102, the implementation process of generating the line lock for the updated service data according to the queried primary key and the transaction identifier of the current local transaction may include: acquiring a transaction identifier of a current local transaction; and inserting the queried primary key and the transaction identifier into a preset row lock record table in a service database. In the specific implementation process, the table name of the service table where the updated service data is located and the primary key information of the updated service data in the service table are recorded in the row lock record table corresponding to the transaction identifier of the current local transaction. Therefore, the service data is marked in a line lock mode and cannot be accessed by other distributed transactions, dirty data is avoided when the data is accessed, and the strong consistency of the distributed transaction access data is improved. It will be appreciated that the names of the service tables are unique and the primary key value within each service table is also unique, so that a piece of data can be uniquely determined by the names of the service tables and updating the primary key information of the service data in the service tables.
For example, an insert statement in the log may be utilized, in which two fields are inserted, one being the transaction identifier and the other being the value of the global lock. The global lock value is the table name of the service table where the updated service data is located and the primary key information of the updated service data in the service table, for example, a character string formed by the table name and the primary key information. Meanwhile, the insert statement is 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.
The transaction initiator, upon receiving the transaction identifier of the global transaction assigned by the transaction manager, may save the transaction identifier in the context of the thread to which the application belongs. Before executing step S101, the transaction initiator, when invoking the service provided by the participant to request the participant to execute the corresponding branch transaction, sends the transaction identifier to the participant, and may intercept the transaction identifier at the service portal of the participant and store it in the context of the belonging thread. When a line lock needs to be generated, a transaction identifier can be acquired from the context, and the transaction identifier and the primary key queried in the step S101 are correspondingly inserted into a preset line lock record table in the service database.
Once the participant commits the local transaction, a one-phase transaction is completed. If the transaction initiator monitors that more than one participant does not submit local transactions on time, that is, indicates that a participant has an error in one stage, a rollback operation in two stages is triggered, and a rollback instruction is sent to each participant, so that the participants execute the following step S103. If the transaction initiator monitors that all the participants submit the local transaction, that is, indicates that all the participants in one stage successfully execute, the two-stage commit operation is triggered, and a commit instruction is sent to each participant, so that the participants execute the following step S104.
Step S103, if a rollback instruction is received, inquiring a transaction update log of the current local transaction from a log of the service database according to a transaction identifier contained in the rollback instruction, and rollback the current local transaction according to the transaction update log.
When receiving the two-stage rollback instruction, the participant needs to rollback the local transaction submitted in the step S102, and restore the service data updated by the service SQL executed in the step S102 to the state before updating. In the embodiment of the present specification, the image data before and after updating required for rollback is obtained from the log of the service database. It should be noted that, for different database types, the manner of querying the update log is different, and specifically, the query is performed according to the interface submitted by the actual database type.
The rollback instruction sent by the transaction initiator includes a transaction identifier of the global transaction to be rolled back. The process of querying the transaction update log of the current local transaction from the log of the transaction database according to the transaction identifier included in the rollback instruction may include: extracting a transaction identifier from the rollback instruction; searching a log containing the transaction identifier in a log of a service database, namely searching a local transaction log containing the transaction identifier in a rollback instruction; and taking the searched local transaction log as a transaction update log of the current local transaction.
The logs of the business database comprise logs of a plurality of local transactions, namely a plurality of local transaction logs, and different local transaction logs are distinguished through start marks and end marks of the local transactions. Each local transaction log stores a transaction identifier of the local transaction, namely, a transaction identifier of a global transaction associated with the local transaction, so that the local transaction log of the local transaction to be rolled back at the time can be filtered out from a plurality of local transaction logs by matching the transaction identifiers.
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: extracting data images of service data to be updated before and after updating from the transaction update log; the current local transaction is rolled back through the pre-update and post-update data mirroring. It will be appreciated that the transaction update log of the business database may include time stamps, and data images before and after the business data update, and the like.
In a specific implementation, first, dirty writes need to be checked. The dirty writing is checked by comparing the updated mirror image data extracted from the transaction update log with the current value of the service data in the service database, if the two data are completely consistent, the dirty writing does not occur, and if the two data are inconsistent, the dirty writing occurs. If dirty writing occurs, the processing needs to be manually changed, and the extracted updated mirror data rollback service data cannot be used any more.
The traffic data is then restored. If no dirty write occurs, the service data is restored to the pre-update value using the pre-update mirror data rollback service data extracted from the transaction update log.
And finally, deleting the intermediate data. After the service data is restored, all the intermediate data stored in one stage can be deleted, and the rollback operation is completed. Since the distributed transaction processing method provided in the embodiments of the present disclosure only stores the line lock in one stage, only the line lock needs to be deleted.
Step S104, if the participant receives the commit instruction, deleting the generated row lock. Because the business SQL is submitted to the business database in one stage, the two-stage submission only needs to delete the intermediate data saved in one stage. Since the distributed transaction processing method provided in the embodiments of the present disclosure only stores the line lock in one stage, only the line lock needs to be deleted. Compared with the AT mode of the Seata or the FMT mode of the DTX, the method reduces the intermediate data to be deleted, is beneficial to reducing the operation steps of the transaction processing flow, and therefore reduces the consumption of system performance.
According to the distributed transaction processing method provided by the embodiment of the specification, query and data mirror images of business data before and after updating are not needed in one stage of distributed transaction processing, the operation steps of a transaction processing flow are reduced, and a database replication technology is utilized to search a transaction update log in a log of a transaction identifier Fu Zaiye business database in two stages of transaction processing to roll back. Compared with the AT mode of the Seata or the FMT mode of the DTX, the method can ensure the normal implementation of two stages of distributed transactions, effectively optimize the transaction processing flow of the non-invasive mode, and is beneficial to reducing the consumption of system performance. In addition, because the data images before and after the service data update do not need to be specially stored in the data files of the service database, the system performance consumption is irrelevant to the data volume updated by the service SQL, so that the influence of the data volume required to be updated on the system performance consumption can be eliminated, and the system performance consumption is further reduced.
In a second aspect, based on the same inventive concept as the distributed transaction method provided in the foregoing first aspect, embodiments of the present disclosure further provide a distributed transaction processing apparatus that operates on a server that is a party to a transaction. As shown in fig. 4, the distributed transaction processing apparatus 40 includes:
the query module 41 is configured to query a service database for a primary key of service data to be updated according to the intercepted service SQL;
the transaction processing module 42 is configured to update the service data to be updated by executing the service SQL, generate a line lock for the updated service data according to the queried primary key and a transaction identifier of a current local transaction after the execution is successful, and store the transaction identifier in a log corresponding to the current local transaction in the service database;
and the rollback module 43 is configured to query a transaction update log of the current local transaction from a log of the service database according to a transaction identifier included in the rollback instruction if the rollback instruction is received, and rollback the current local transaction according to the transaction update log.
In an alternative embodiment, the rollback module 43 includes: a log query sub-module 431, configured to search, from logs in a service database, a local transaction log that includes a transaction identifier in the rollback instruction; and taking the searched local transaction log as a transaction update log of the local transaction.
In an alternative embodiment, the rollback module 43 includes:
an extracting sub-module 432, configured to extract, from the transaction update log, data images of the service data to be updated before and after updating;
and the rollback module 433 is configured to rollback the current local transaction through the pre-update and post-update data images.
In an alternative embodiment, the transaction module 42 is configured to: acquiring a transaction identifier of the current local transaction; and inserting the queried primary key and the transaction identifier into a preset row lock record table in the service database.
In an alternative embodiment, the distributed transaction processing apparatus 40 further includes: and a commit module 44, configured to delete the line lock if a commit instruction is received.
It should be noted that, the specific manner in which the operations of the respective modules of the distributed transaction processing device 40 provided in the embodiment of the present invention are performed has been described in detail in the embodiment of the method provided in the first aspect, and the specific implementation process may refer to the embodiment of the method provided in the first aspect, which will not be described in detail herein.
In a third aspect, embodiments of the present disclosure further provide a server based on the same inventive concept as the distributed transaction processing method provided in the foregoing embodiments. As shown in fig. 5, the server includes a memory 504, one or more processors 502, and a computer program stored on the memory 504 and executable on the processor 502, which when executed by the processor 502 implements the steps of any of the embodiments of the distributed transaction method provided in the first aspect above.
Where in FIG. 5 a bus architecture (represented by bus 500), bus 500 may include any number of interconnected buses and bridges, with bus 500 linking together various circuits, including one or more processors, represented by processor 502, and memory, represented by memory 504. Bus 500 may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., as 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. The receiver 501 and the transmitter 503 may be the same element, i.e. a transceiver, providing a means for communicating with various other apparatus 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 will be appreciated that the configuration shown in fig. 5 is merely illustrative, and that the server provided by the embodiments of the present disclosure may also include more or fewer components than those shown in fig. 5, or have a different configuration than that shown in fig. 5. The components shown in fig. 5 may be implemented in hardware, software, or a combination thereof.
In a fourth aspect, based on the same inventive concept as the distributed transaction method provided in the previous embodiments, the present description embodiments also provide a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of any implementation of the distributed transaction method provided in the previous first aspect.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying 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 present description 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 of 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 a processor of a general purpose computer, special purpose computer, embedded processor, 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 flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may 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 instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may 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 functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present description have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the disclosure.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present specification without departing from the spirit or scope of the specification. Thus, if such modifications and variations of the present specification fall within the scope of the claims and the equivalents thereof, the present specification is also intended to include such modifications and variations.
Claims (10)
1. A distributed transaction processing method applied to non-intrusive distributed transaction middleware in a server as a transaction participant, the 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 for the updated service data according to the queried primary key and a transaction identifier of a 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, wherein the service database automatically generates a local transaction log containing data images before and after the service data update when executing the service SQL by starting a master-slave copy function, and stores the local transaction log in a file system of a server where the service database is located;
if a rollback instruction is received, according to a transaction identifier contained in the rollback instruction, inquiring a transaction update log of the current local transaction from a log of the service database, and rollback the current local transaction according to the transaction update log, wherein the rollback method comprises the following steps: and extracting data images of the business data to be updated before and after updating from the transaction update log, and rolling back the current local transaction through the data images before and after updating.
2. The method of claim 1, the querying the transaction update log of the current local transaction from the log of the transaction database according to the transaction identifier included in the rollback instruction, comprising:
searching a local transaction log containing a transaction identifier in the rollback instruction from a log 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 generating a row lock for updated business data based on the queried primary key and the transaction identifier of the current local transaction, comprising:
acquiring a transaction identifier of the current local transaction;
and inserting the queried primary key and the transaction identifier into a preset row lock record table in the service database.
4. The method of claim 1, further comprising:
and if a commit instruction is received, deleting the row lock.
5. A distributed transaction processing apparatus for use in a non-intrusive distributed transaction middleware in a server acting as a party to a transaction, the apparatus comprising:
the query module is used for querying a main key of service data to be updated from the service database according to the intercepted service SQL;
the business processing module is used for updating the business data to be updated by executing the business SQL, generating a row lock for the updated business data according to the queried main key and a business identifier of a current local business after the business SQL is successfully executed, and storing the business identifier into a log of the business database corresponding to the current local business, wherein the business database automatically generates a local business log containing data images before and after the business data updating by starting a master-slave copy function when executing the business SQL and stores the local business log in a file system of a server where the business database is located;
the rollback module is configured to query a transaction update log of the current local transaction from a log of the service database according to a transaction identifier included in the rollback instruction if the rollback instruction is received, and rollback the current local transaction according to the transaction update log, where the rollback module includes: and extracting data images of the business data to be updated before and after updating from the transaction update log, and rolling back the current local transaction through the data images before and after updating.
6. The apparatus of claim 5, the rollback module comprising:
the log query sub-module is used for searching a local transaction log containing the transaction identifier in the rollback instruction from the log of the service database; and taking the searched local transaction log as a transaction update log of the local transaction.
7. The apparatus of claim 5, the transaction module to:
acquiring a transaction identifier of the current local transaction;
and inserting the queried primary key and the transaction identifier into a preset row lock record table in the service database.
8. The apparatus of claim 5, further comprising:
and the submitting module is used for deleting the row lock if a submitting instruction is received.
9. A server, comprising: memory, a processor and a computer program stored on the memory and executable on the processor, which processor implements the steps of the method of any one of claims 1-4 when the program is executed.
10. A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the method of any of claims 1-4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010209587.2A CN111522631B (en) | 2020-03-23 | 2020-03-23 | Distributed transaction processing method, device, server and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010209587.2A CN111522631B (en) | 2020-03-23 | 2020-03-23 | Distributed transaction processing method, device, server and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111522631A CN111522631A (en) | 2020-08-11 |
| CN111522631B true CN111522631B (en) | 2024-02-06 |
Family
ID=71900960
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010209587.2A Active CN111522631B (en) | 2020-03-23 | 2020-03-23 | Distributed transaction processing method, device, server and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111522631B (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112182082B (en) * | 2020-09-24 | 2021-07-06 | 广州巨杉软件开发有限公司 | System and method for realizing strong consistency of transactions across different database engines |
| CN112395102A (en) * | 2020-10-15 | 2021-02-23 | 北京仿真中心 | Distributed database middleware solution method |
| CN114385320A (en) * | 2020-10-22 | 2022-04-22 | 支付宝(杭州)信息技术有限公司 | Distributed transaction processing method and system |
| CN112764888B (en) * | 2021-01-21 | 2023-03-24 | 中信银行股份有限公司 | Distributed transaction checking and judging method and system based on log analysis |
| CN112995304B (en) * | 2021-02-08 | 2022-09-23 | 中国工商银行股份有限公司 | Method and device for processing routing service node by two-stage distributed transaction |
| CN113010495B (en) * | 2021-03-19 | 2023-01-06 | 北京三快在线科技有限公司 | Database optimization method and device |
| CN113342481B (en) * | 2021-07-07 | 2024-03-26 | 中国工商银行股份有限公司 | Transaction state confirmation method and device |
| CN114064664A (en) * | 2022-01-17 | 2022-02-18 | 北京奥星贝斯科技有限公司 | Method and device for inquiring transaction modification content in database |
| CN116627769A (en) * | 2022-09-26 | 2023-08-22 | 北京奥星贝斯科技有限公司 | Method and device for processing transaction log |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102831156A (en) * | 2012-06-29 | 2012-12-19 | 浙江大学 | Distributed transaction processing method on cloud computing platform |
| US9171019B1 (en) * | 2013-02-19 | 2015-10-27 | Amazon Technologies, Inc. | Distributed lock service with external lock information database |
| CN106033439A (en) * | 2015-03-13 | 2016-10-19 | 阿里巴巴集团控股有限公司 | Method and system for processing distributed transaction |
| CN106033437A (en) * | 2015-03-13 | 2016-10-19 | 阿里巴巴集团控股有限公司 | Method and system for processing distributed transaction |
| WO2016180164A1 (en) * | 2015-09-29 | 2016-11-17 | 中兴通讯股份有限公司 | Method and apparatus for rolling back distributed transaction |
| CN106610876A (en) * | 2015-10-23 | 2017-05-03 | 中兴通讯股份有限公司 | Method and device for recovering data snapshot |
| US9830223B1 (en) * | 2015-01-26 | 2017-11-28 | Intel Corporation | Methods for repairing a corrupted database to a new, correct state |
| CN109783204A (en) * | 2018-12-28 | 2019-05-21 | 咪咕文化科技有限公司 | A kind of distributed transaction processing method, device and storage medium |
| CN110888718A (en) * | 2019-11-27 | 2020-03-17 | 武汉虹旭信息技术有限责任公司 | Method and device for realizing distributed transaction |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013033345A (en) * | 2011-08-01 | 2013-02-14 | Internatl Business Mach Corp <Ibm> | Transaction processing system, method and program |
| US9396227B2 (en) * | 2012-03-29 | 2016-07-19 | Hewlett Packard Enterprise Development Lp | Controlled lock violation for data transactions |
| US10474668B2 (en) * | 2016-11-17 | 2019-11-12 | Sap Se | Database systems architecture incorporating distributed log |
| US10977143B2 (en) * | 2017-12-15 | 2021-04-13 | Vmware, Inc. | Mirrored write ahead logs for data storage system |
-
2020
- 2020-03-23 CN CN202010209587.2A patent/CN111522631B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102831156A (en) * | 2012-06-29 | 2012-12-19 | 浙江大学 | Distributed transaction processing method on cloud computing platform |
| US9171019B1 (en) * | 2013-02-19 | 2015-10-27 | Amazon Technologies, Inc. | Distributed lock service with external lock information database |
| US9830223B1 (en) * | 2015-01-26 | 2017-11-28 | Intel Corporation | Methods for repairing a corrupted database to a new, correct state |
| CN106033439A (en) * | 2015-03-13 | 2016-10-19 | 阿里巴巴集团控股有限公司 | Method and system for processing distributed transaction |
| CN106033437A (en) * | 2015-03-13 | 2016-10-19 | 阿里巴巴集团控股有限公司 | Method and system for processing distributed transaction |
| WO2016180164A1 (en) * | 2015-09-29 | 2016-11-17 | 中兴通讯股份有限公司 | Method and apparatus for rolling back distributed transaction |
| CN106610876A (en) * | 2015-10-23 | 2017-05-03 | 中兴通讯股份有限公司 | Method and device for recovering data snapshot |
| CN109783204A (en) * | 2018-12-28 | 2019-05-21 | 咪咕文化科技有限公司 | A kind of distributed transaction processing method, device and storage medium |
| CN110888718A (en) * | 2019-11-27 | 2020-03-17 | 武汉虹旭信息技术有限责任公司 | Method and device for realizing distributed transaction |
Non-Patent Citations (1)
| Title |
|---|
| SQL Server数据库的备份与恢复;张淑玉;;潍坊学院学报(06);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111522631A (en) | 2020-08-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111522631B (en) | Distributed transaction processing method, device, server and medium | |
| KR102141234B1 (en) | Versioned hierarchical data structure within a distributed data store | |
| US9672017B2 (en) | Object storage and synchronization hooks for occasionally-connected devices | |
| US11392588B2 (en) | Active queries filter extraction | |
| US7552149B2 (en) | Querying past versions of data in a distributed database | |
| US5920857A (en) | Efficient optimistic concurrency control and lazy queries for B-trees and other database structures | |
| US9928255B2 (en) | Method for generating indexes for downloading data | |
| US6178425B1 (en) | Method of determining the visibility to a remote database client of a plurality of database transactions using simplified visibility rules | |
| US7366738B2 (en) | Method and system for object cache synchronization | |
| US9747356B2 (en) | Eager replication of uncommitted transactions | |
| US7895172B2 (en) | System and method for writing data dependent upon multiple reads in a distributed database | |
| US20030135523A1 (en) | Method of using cache to determine the visibility to a remote database client of a plurality of database transactions | |
| CN111259083A (en) | Distributed transaction processing method and device | |
| CN111881223B (en) | Data management method, device, system and storage medium | |
| US20020026448A1 (en) | Caching of distributed dynamic sql statements in a multiple node rdbms. | |
| US9171036B2 (en) | Batching heterogeneous database commands | |
| JP2005532615A (en) | Providing usable versions of data items | |
| US20060136443A1 (en) | Method and apparatus for initializing data propagation execution for large database replication | |
| US11449550B2 (en) | Ad-hoc graph definition | |
| US20090187599A1 (en) | Generating identity values in a multi-host database management system | |
| US20050144299A1 (en) | System and method for supporting XA 2-phase commit protocols with a loosely coupled clustered database server | |
| WO2023124242A1 (en) | Transaction execution method and apparatus, device, and storage medium | |
| US11423003B2 (en) | Optimistic concurrency control for database transactions | |
| US20040015508A1 (en) | Object-level conflict detection in an object-relational database system | |
| US20190220531A1 (en) | Consistency check for foreign key definition |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |