Distributed transaction processing methods, devices, and systems

Abstract

This application provides a method, apparatus, and system for processing distributed transactions, belonging to the field of distributed technology. In the solution provided by this application, the database operation instructions sent by the business client to the business database can carry the context of a distributed transaction, enabling the network proxy node to create and process transaction branches based on this context and the database operation statement. Since transaction branches can be created and processed through the network proxy node, there is no need for the business client to deploy an interface for creating and processing transaction branches, thereby effectively reducing the development cost of applying the distributed transaction processing system to the business client.

Description

[0001] This application claims priority to Chinese Patent Application No. 202010132037.5, filed on February 29, 2020, entitled "A Transaction Processing System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of distributed technology, and in particular to a method, apparatus and system for processing distributed transactions. Background Technology

[0003] A transaction is a sequence of one or more resource management operations. A distributed transaction refers to a sequence of operations that involves multiple databases (DBs). Because distributed transactions involve operations on multiple databases, it is necessary to ensure the consistency of the operations across all databases.

[0004] In related technologies, the Try-Confirm-Cancel (TCC) technique is commonly used to handle distributed transactions. Business clients on resource servers (also called business servers) employing this TCC technique have three interfaces deployed: try, confirm, and cancel. The TCC process consists of two phases: In the first phase (also called the try phase), the master business client initiating the distributed transaction calls the try interfaces of all other slave business clients involved in the transaction to request them to reserve business resources. In the second phase (also called the confirm / cancel phase), if the master business client determines that the business resources of all slave business clients have been successfully reserved, it can send a commit command to the transaction server. The transaction server can then call the confirm interface of each slave business client to instruct them to perform operations on the reserved business resources, i.e., to perform the commit operation. If the master business client determines that the reservation of business resources for any slave business client has failed, it can send a rollback instruction to the transaction server. The transaction server can then call the cancel interface of each slave business client to instruct each slave business client to cancel the operation on the reserved business resources, that is, to perform a rollback operation to release the reserved business resources.

[0005] However, because this TCC technology requires each business client participating in distributed transactions to deploy the three interfaces try, confirm, and cancel, the development cost of the business clients is relatively high. Summary of the Invention

[0006] This application provides a method, apparatus, and system for processing distributed transactions, which can solve the technical problem of high development costs for business clients when implementing distributed transactions in related technologies.

[0007] On one hand, a method for processing distributed transactions is provided. This method is applied to a distributed transaction processing system, which includes multiple business servers, a transaction server, and a business database. Each business server includes a network proxy node and a business client, and the method is executed by the network proxy node. The method includes: obtaining one or more database operation instructions sent by the business client, each database operation instruction including a database operation statement and a context of a distributed transaction, wherein the database operation instructions included in the one or more database operation instructions are used to implement a transaction branch of the distributed transaction, and the context of the distributed transaction includes an identifier of the distributed transaction; executing the database operation statement included in each database operation instruction in the business database, and sending a transaction branch creation request to the transaction server, the transaction branch creation request including the identifier of the distributed transaction.

[0008] The distributed transaction processing method provided in this application involves sending database operation instructions from the business client that carry the context of the distributed transaction. This allows network proxy nodes to create and process transaction branches based on these instructions. Since the business client does not need to create and process transaction branches, the impact on the original business logic is minimal, effectively reducing the development cost for business clients applying to distributed transaction processing systems.

[0009] Optionally, the method further includes: obtaining lock information for a dataset, which is the target of the database operation statements included in the one or more database operation instructions, the lock information of which is used to identify the dataset in the business database; correspondingly, the transaction branch creation request also includes the lock information of the dataset.

[0010] Carrying the lock information of the dataset in the transaction branch creation request makes it easier for the transaction server to determine whether the dataset is locked and whether the transaction branch can be created.

[0011] Optionally, the network proxy node confirms that the auto-commit function of the business database is enabled. After receiving the first creation response from the transaction server indicating that the transaction branch has been successfully created, the network proxy node can then execute the database operation statements included in each database operation instruction in the business database. Furthermore, in response to the first creation response, the network proxy node can also send a first commit instruction to the business database for the transaction branch of the distributed transaction, instructing the business database to commit the transaction branch.

[0012] By ensuring the transaction branch is successfully created, the network proxy node executes the database operation statement. This avoids the problem of previously executed database operation statements becoming invalid if the transaction branch creation fails after execution. In other words, by not executing database operation statements in scenarios where transaction branch creation fails, the computational resources of the application server are not wasted.

[0013] Optionally, the network proxy node may also receive a second creation response from the transaction server indicating that the creation of the transaction branch has failed; and in response to the second creation response, send a first rollback instruction for the transaction branch of the distributed transaction to the business database, the first rollback instruction being used to instruct the business database to roll back the transaction branch.

[0014] Optionally, the network proxy node confirms that the auto-commit function of the business database is disabled, and can send the execution result of the database operation statement to the business client after each database operation instruction is executed; furthermore, the network proxy node can acquire the lock information of the dataset after receiving the second commit instruction for the transaction branch of the distributed transaction sent by the business client; wherein, if the number of database operation statements used to implement the transaction branch of the distributed transaction is greater than 1, the auto-commit function of the business database is set to disabled by the business client; the second commit instruction is sent by the business client after determining, based on the execution result sent by the network proxy node, that all database operation statements included in each database operation instruction used to implement the transaction branch of the distributed transaction have been executed successfully.

[0015] Since the network proxy node can determine that there are multiple database operation instructions used to implement the transaction branch when it detects that the auto-commit function of the business database is turned off, the network proxy node can obtain the lock information of the dataset after receiving the second commit instruction, and then send a transaction branch creation request.

[0016] Optionally, after sending the execution result of the database operation statement included in each database operation instruction to the business client, if the network proxy node obtains the second rollback instruction for the transaction branch of the distributed transaction sent by the business client, it can also delete the lock information of the dataset and send the second rollback instruction to the business database; wherein, the second rollback instruction is sent by the business client after determining that the database operation statement included in any database operation instruction used to implement the transaction branch has failed to execute.

[0017] If a network proxy node receives a second rollback instruction, it can determine that the transaction branch has failed. Therefore, it can delete the lock information of the dataset it stores to avoid the lock information of the dataset occupying too much storage space.

[0018] Optionally, the network proxy node can obtain a first setting instruction sent by the service client and record that the auto-commit function of the service database is enabled based on the first setting instruction. Alternatively, the network proxy node can obtain a second setting instruction sent by the service client and record that the auto-commit function of the service database is disabled based on the second setting instruction; wherein, the first setting instruction is sent by the service client when it determines that the number of database operation statements used to implement the transaction branch is equal to 1; and the second setting instruction is sent by the service client when it determines that the number of database operation statements used to implement the transaction branch is greater than 1.

[0019] The network proxy node records the status of the auto-commit function of the business database based on the first or second setting instruction it receives. This ensures that when creating a transaction branch, it can accurately determine whether the auto-commit function of the business database is enabled based on the recorded status.

[0020] Optionally, the first creation response may carry an identifier assigned by the transaction server to the transaction branch; after receiving the first creation response from the transaction server indicating that the transaction branch of the distributed transaction has been successfully created, the network proxy node may also store the identifier of the transaction branch and the corresponding relationship of the dataset in the transaction log of the distributed transaction; then, the network proxy node may receive the third commit instruction for the transaction branch sent by the transaction server and clear the identifier of the transaction branch and the dataset recorded in the transaction log; or, the network proxy node may receive the third rollback instruction for the transaction branch sent by the transaction server, obtain the dataset from the transaction log according to the identifier of the transaction branch, and roll back the transaction branch according to the dataset.

[0021] Specifically, the third commit instruction is sent by the transaction server after receiving the commit instruction for the distributed transaction from the business client, and the third rollback instruction is sent by the transaction server after receiving the rollback instruction for the distributed transaction from the business client.

[0022] Optionally, after sending the first commit instruction for the transaction branch of the distributed transaction to the business database, the network proxy node can also delete the lock information of the dataset. Furthermore, if the network proxy node determines that the transaction branch has been successfully committed, it can send a commit result to the business client indicating that the transaction branch of the distributed transaction has been successfully committed. If the network proxy node determines that the transaction branch of the distributed transaction has failed to commit, it can send a commit result to the business client indicating that the transaction branch of the distributed transaction has failed, send a fourth rollback instruction for the transaction branch of the distributed transaction to the business database, and send a notification message carrying the identifier of the transaction branch of the distributed transaction to the transaction server. This notification message instructs the transaction server to delete the lock information of the dataset corresponding to the transaction branch of the distributed transaction.

[0023] After the network proxy node sends the first commit instruction for the transaction branch, it feeds back the commit result of the transaction branch to the business client, which makes it easier for the business client to determine whether to commit or roll back the distributed transaction based on the commit result.

[0024] Optionally, the network proxy node can intercept data packets sent by the business client. If it detects that the recipient of the data packet sent by the business client is the business database, the network proxy node can obtain and parse the data packet. If it detects that the recipient of the data packet sent by the business client is not the business database, the network proxy node can directly forward the data packet to the recipient.

[0025] In the solution provided in this application, since the network proxy node only needs to parse the data packets sent by the business client to the business database, and the business clients all interact with the business database based on the database protocol, the network proxy node only needs to support the database protocol to be compatible with business clients developed in different programming languages. That is, the solution provided in this application can be applied to distributed transaction processing systems that span multiple programming languages.

[0026] On the other hand, a method for processing distributed transactions is provided, applied to a distributed transaction processing system. This system includes multiple business servers, a transaction server, and a business database. Each business server includes a network proxy node and a business client. The method can be executed by a first business client. The method may include: generating one or more database operation statements for implementing the transaction branch of the distributed transaction based on the transaction branch to be executed by the first business client; generating one or more database operation instructions based on the one or more database operation statements, each database operation instruction including at least one database operation statement and a context of the distributed transaction, the context including an identifier of the distributed transaction; and sending the one or more database operation instructions to the first business database, wherein the first network proxy node and the first business client are deployed on the same business server.

[0027] Because the database operation commands sent by the business client carry the context of a distributed transaction, the network proxy node that obtains the database operation command can create and process transaction branches based on the database operation statement and the context of the distributed transaction. Since the business client does not need to create and process transaction branches, the impact on the original business logic of the business client is minimal, thereby effectively reducing the development cost of applying the distributed transaction processing system to the business client.

[0028] Optionally, the first business client can be the main business client that initiates the distributed transaction. Accordingly, the first business client can also respond to the business request by sending a creation request for the distributed transaction to the transaction server; receiving the identifier of the distributed transaction sent by the transaction server; and sending a service call request to the second business client participating in the distributed transaction, the service call request carrying the identifier of the distributed transaction. Furthermore, the first business client can determine the transaction branch to be executed by the first business client in the distributed transaction based on the business request.

[0029] Optionally, the first business client, acting as the primary business client, may also perform the following operations: receive the commit result of the transaction branch sent by the first network proxy node; and receive the service call response sent by the second business client in response to the service call request; then, based on the commit result and the service call response, send a commit instruction or a rollback instruction for the distributed transaction to the transaction server; wherein, the commit instruction for the distributed transaction is used to instruct the commit of each transaction branch included in the distributed transaction, and the commit instruction for the distributed transaction is used to instruct the rollback of each transaction branch included in the distributed transaction.

[0030] In the solution provided in this application, the first business client, acting as the main business client, only needs to send a distributed transaction creation request, generate database operation instructions, and send a distributed transaction commit or rollback instruction during the distributed transaction implementation process. These operations have minimal impact on the original business logic of the main business client, meaning they are less intrusive to the main business client's operations. Therefore, this effectively reduces the cost of adapting the main business client to the distributed transaction processing architecture to achieve distributed business transformation.

[0031] Optionally, the first business client can also be a slave business client participating in the distributed transaction. Correspondingly, the first business client can also receive service call requests sent by the second business client (i.e., the master business client), which carry the context of the distributed transaction. Based on the service call request, the transaction branch to be executed by the first business client in the distributed transaction is determined.

[0032] As a business client, the first business client only needs to generate database operation instructions during the implementation of distributed transactions, which can effectively reduce the cost of adapting the business client to the distributed transaction processing architecture and realizing the distributed transformation of the business.

[0033] Optionally, the method may further include: a first business client determining that the number of database operation statements for the transaction branch used to implement the distributed transaction is equal to 1, and sending a first setting instruction to the first business database to indicate that the auto-commit function is set to the enabled state; or, a first business client determining that the number of database operation statements for the transaction branch used to implement the distributed transaction is greater than 1, and sending a second setting instruction to the first business database to indicate that the auto-commit function is set to the disabled state.

[0034] The first and second setting instructions mentioned above can be intercepted by the first network proxy node. The first network proxy node can accurately determine the status of the automatic commit function of the first business database based on the first or second setting instruction. That is, it can accurately determine whether the number of database operation statements used to implement the transaction branch of the distributed transaction is greater than 1.

[0035] Optionally, after sending a second setting instruction to the first business database to indicate that the auto-commit function is set to the off state, the first business client can also receive the execution results of the database operation statements included in each database operation instruction sent by the first network proxy node; if the execution results determine that the database operation statements included in each database operation instruction used to implement the transaction branch of the distributed transaction have been executed successfully, the first business client can send a second commit instruction for the transaction branch of the distributed transaction to the first business database; if the execution results determine that the database operation statements included in any database operation instruction used to implement the transaction branch of the distributed transaction have failed to execute, the first business client can send a second rollback instruction for the transaction branch of the distributed transaction to the first business database.

[0036] The aforementioned second commit instruction and second rollback instruction can be intercepted by the first network proxy node. The first network proxy node can create a transaction branch based on the second commit instruction, or roll back the transaction branch based on the second rollback instruction.

[0037] On another front, a network proxy node is provided for use in a distributed transaction processing system. This system includes multiple business servers, transaction servers, and a business database. Each business server includes a network proxy node and a business client. The network proxy node includes:

[0038] The parsing module is used to obtain one or more database operation instructions sent by the business client. Each database operation instruction includes a database operation statement and the context of the distributed transaction. The database operation statement included in the one or more database operation instructions is used to implement the transaction branch of the distributed transaction, and the context of the distributed transaction includes the identifier of the distributed transaction.

[0039] The transaction branch processing module is used to execute the database operation statements included in each database operation instruction in the business database, and to send a transaction branch creation request to the transaction server, which includes the identifier of the distributed transaction.

[0040] Optionally, the transaction branch processing module is also used to: obtain lock information of a dataset, which is the target of the database operation statement included in the one or more database operation instructions, and the lock information of the dataset is used to identify the dataset in the business database; the transaction branch creation request also includes the lock information of the dataset.

[0041] Optionally, the transaction branch processing module is configured to: confirm that the auto-commit function of the business database is enabled; after receiving a first creation response from the transaction server indicating that the transaction branch has been successfully created, execute the database operation statements included in each database operation instruction in the business database; the transaction branch processing module is further configured to: in response to the first creation response, send a first commit instruction for the transaction branch to the business database.

[0042] Optionally, the transaction branch processing module is further configured to: receive a second creation response sent by the transaction server indicating that the creation of the transaction branch has failed; and in response to the second creation response, send a first rollback instruction for the transaction branch to the business database.

[0043] Optionally, the transaction branch processing module is further configured to: confirm that the auto-commit function of the business database is in a disabled state; send the execution result of the database operation statements included in each database operation instruction to the business client; and after receiving the second commit instruction for the transaction branch sent by the business client, obtain the lock information of the dataset; wherein the second commit instruction is sent by the business client after determining, based on the execution result, that all database operation statements included in each database operation instruction have been executed successfully.

[0044] Optionally, the transaction branch processing module is further configured to: after sending the execution result of the database operation statement included in each database operation instruction to the business client, obtain the second rollback instruction sent by the business client for the transaction branch, delete the lock information of the dataset; and send the second rollback instruction to the business database; wherein the second rollback instruction is sent by the business client after determining that the database operation statement included in any database operation instruction has failed to execute.

[0045] Optionally, the transaction branch processing module is further configured to: obtain a first setting instruction sent by the business client; record that the automatic commit function of the business database is enabled according to the first setting instruction; wherein the first setting instruction is sent by the business client when it determines that the number of database operation statements used to implement the transaction branch is equal to 1.

[0046] Optionally, the transaction branch processing module is further configured to: obtain a second setting instruction sent by the business client; record that the auto-commit function of the business database is in a closed state according to the second setting instruction; wherein the second setting instruction is sent by the business client when it determines that the number of database operation statements used to implement the transaction branch is greater than 1.

[0047] Optionally, the first creation response carries an identifier assigned by the transaction server to the transaction branch; the transaction branch processing module is further configured to: after receiving the first creation response sent by the transaction server indicating that the transaction branch has been successfully created, store the identifier of the transaction branch and the corresponding relationship of the dataset in the transaction log of the distributed transaction; receive the third commit instruction sent by the transaction server for the transaction branch, and clear the identifier of the transaction branch and the dataset recorded in the transaction log; wherein, the third commit instruction is sent by the transaction server after receiving the commit instruction for the distributed transaction sent by the business client.

[0048] Optionally, the first creation response carries an identifier assigned by the transaction server to the transaction branch; the transaction branch processing module is further configured to: after receiving the first creation response sent by the transaction server indicating that the transaction branch has been successfully created, store the identifier of the transaction branch and the corresponding relationship of the dataset in the transaction log of the distributed transaction; receive the third rollback instruction sent by the transaction server for the transaction branch, retrieve the dataset from the transaction log according to the identifier of the transaction branch, and roll back the transaction branch according to the dataset; wherein, the third rollback instruction is sent by the transaction server after receiving the rollback instruction for the distributed transaction sent by the business client.

[0049] On another front, a business client is provided for use in a distributed transaction processing system. This system includes multiple business servers, transaction servers, and a business database. Each business server includes a network proxy node and a business client. The business client includes:

[0050] The processing module is used to generate one or more database operation statements to implement the transaction branch to be executed by the business client in the distributed transaction.

[0051] The application programming interface module is used to generate one or more database operation instructions based on the one or more database operation statements. Each database operation instruction includes: at least one database operation statement and the context of the distributed transaction, the context of the distributed transaction including the identifier of the distributed transaction.

[0052] A database driver is used to send one or more database operation instructions to a first network proxy node, wherein the first network proxy node and the business client are deployed on the same business server.

[0053] Optionally, the application interface module is also used to: send a request to create the distributed transaction to the transaction server in response to a business request; and receive the identifier of the distributed transaction sent by the transaction server.

[0054] The business client also includes: a service invocation module, used to send a service invocation request to a second business client participating in the distributed transaction, the service invocation request carrying the identifier of the distributed transaction; and a processing module, used to determine the transaction branch to be executed by the business client in the distributed transaction based on the business request.

[0055] Optionally, the processing module is further configured to: receive the commit result of the transaction branch sent by the first network proxy node; receive the service call response sent by the second service client in response to the service call request; and send a commit instruction or a rollback instruction for the distributed transaction to the transaction server based on the commit result and the service call response; wherein the commit instruction for the distributed transaction is used to instruct the commit of each transaction branch included in the distributed transaction, and the commit instruction for the distributed transaction is used to instruct the rollback of each transaction branch included in the distributed transaction.

[0056] Optionally, the processing module is further configured to: receive a service call request sent by a second business client, the service call request carrying the context of the distributed transaction; and determine the transaction branch to be executed by the business client in the distributed transaction based on the service call request.

[0057] Optionally, the processing module is further configured to: determine that the number of database operation statements is equal to 1, instruct the database driver to send a first setting instruction to the first business database, the first setting instruction indicating that the auto-commit function is set to the enabled state.

[0058] Optionally, the processing module is further configured to: determine that the number of database operation statements is greater than 1, instruct the database driver to send a second setting instruction to the first business database, the second setting instruction indicating that the auto-commit function is set to the off state.

[0059] Optionally, the processing module is further configured to: receive the execution result of the database operation statements included in each database operation instruction; determine, based on the execution result, that all database operation statements included in each database operation instruction have been successfully executed; and instruct the database driver to send a second commit instruction for the transaction branch to the first business database.

[0060] Optionally, the business client further includes: receiving the execution result of the database operation statement included in each database operation instruction; determining, based on the execution result, that the database operation statement included in any database operation instruction has failed to execute, and instructing the database driver to send a second rollback instruction for the transaction branch to the first business database.

[0061] In another aspect, a network proxy node is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the distributed transaction processing method provided above by the network proxy node.

[0062] In another aspect, a business client is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the distributed transaction processing method provided above by the first business client.

[0063] In another aspect, a computer-readable storage medium is provided, which stores instructions that, when executed on a computer, cause the computer to perform the distributed transaction processing method provided above, which is executed by the network agent node.

[0064] In another aspect, a computer-readable storage medium is provided, which stores instructions that, when executed on a computer, cause the computer to perform the distributed transaction processing method provided above, which is executed by a first business client.

[0065] On the other hand, a distributed transaction processing system is provided, which includes: a transaction server, multiple business servers, and multiple business databases;

[0066] Each service server includes a network proxy node as described above, and a service client as described above.

[0067] In summary, this application provides a method, apparatus, and system for processing distributed transactions. The solution provided in this application allows the database operation instructions sent by the business client to the business database to carry the context of the distributed transaction. This enables the network proxy node to create and process transaction branches based on the context of the distributed transaction and the database operation statements. Since transaction branches can be created and processed through the network proxy node, there is no need for the business client to deploy interfaces for creating and processing transaction branches (such as try, confirm, and cancel interfaces), thereby effectively reducing the development cost for the business client to apply to the distributed transaction processing system. Attached Figure Description

[0068] Figure 1 This is a schematic diagram of the structure of a distributed transaction processing system provided in an embodiment of this application;

[0069] Figure 2This is a schematic diagram of another distributed transaction processing system provided in an embodiment of this application;

[0070] Figure 3 This is a flowchart of a distributed transaction processing method provided in an embodiment of this application;

[0071] Figure 4 This is a flowchart of another distributed transaction processing method provided in an embodiment of this application;

[0072] Figure 5 This is a flowchart illustrating a method for a network proxy node to intercept data packets, as provided in an embodiment of this application.

[0073] Figure 6 This is a schematic diagram of the structure of another distributed transaction processing system provided in the embodiments of this application;

[0074] Figure 7 This is a schematic diagram of the structure of another distributed transaction processing system provided in the embodiments of this application. Detailed Implementation

[0075] The following describes in detail, with reference to the accompanying drawings, the distributed transaction processing method, apparatus, and system provided in the embodiments of this application.

[0076] Figure 1 This is a schematic diagram of the structure of a distributed transaction processing system provided in an embodiment of this application, such as... Figure 1 As shown, the system may include: multiple business servers 01, transaction servers 02, and multiple business databases 03. Each business database 03 corresponds to one business server 01, and each business database 03 is used to store the business data of its corresponding business server 01. Furthermore, each business database 03 is deployed on a database server.

[0077] In this embodiment of the application, the distributed transaction processing system can adopt a service mesh architecture to realize communication between business servers 01, thereby ensuring that the services running in business clients 011 within each business server 01 can be reliably invoked. For example... Figure 1 As shown, each business server 01 in this system can deploy not only business clients 011, but also network proxy nodes 012. The network proxy nodes 012 in each business server 01 can form a service mesh, which can realize communication between business clients 011 in different business servers 01, communication between business clients 011 and transaction server 02, and communication between business clients 011 and business database 03.

[0078] Optionally, each business server 01 may run one or more virtual machines, and the business client 011 and network proxy node 012 may be deployed in the same virtual machine or in different virtual machines. Alternatively, each business server 01 may run one or more containers, and the business client 011 and network proxy node 012 may be deployed in the same container or in different containers.

[0079] Each of the business server 01, the transaction server 02, and the database server that deploys the business database 03 can be a physical server, a physical server cluster consisting of several physical servers, or a cloud computing center.

[0080] Optionally, any two servers among the multiple business servers 01, the transaction server 02, and the database server deploying the business database 03 can be independent physical servers. That is, the transaction server 02, each business client 011, and each business database 03 are physically isolated, thereby ensuring the operational performance of the transaction server 02, each business client 011, and each business database 03.

[0081] Alternatively, at least two of the multiple business servers 01, the transaction server 02, and the database server deploying the business database 03 can be deployed on the same physical server. For example, multiple business servers 01 can be deployed on the same physical server.

[0082] In this distributed transaction processing system, multiple business servers 01 can participate in implementing the same distributed transaction (also known as a global transaction). Each business server 01 can implement a transaction branch within this distributed transaction (which can also be called its local transaction). The transaction server 02 is responsible for coordinating the entire distributed transaction process, such as initiating the distributed transaction, creating transaction branches, committing or rolling back the distributed transaction, and performing timeout checks.

[0083] Optional, Figure 2 This is a schematic diagram of another distributed transaction processing system provided in an embodiment of this application, such as... Figure 2 As shown, the system may include a first business server 01a for implementing distributed transactions, and at least one second business server 01b. Figure 2Only one second business server 01b is schematically shown. The first business server 01a can be the business server used to initiate the distributed transaction, and therefore can also be called the master business server. Each second business server 01b, as one of the participants in the distributed transaction, can also be called a slave business server. Furthermore, refer to... Figure 2 It can be seen that the business data of the first business client 011a in the first business server 01a can be stored in the first business database 03a, and the business data of the second business client 011b in the second business server 01b can be stored in the second business database 03b.

[0084] In this embodiment, each business server 01 can implement a transaction branch by performing one or more operations on the business data in its corresponding business database 03. This transaction branch can be a branch of a distributed transaction, or it can be a branch of a non-distributed transaction, meaning it may not participate in the distributed transaction. Specifically, for each operation performed on the business data in the business database 03, the business client 011 in the business server 01 needs to generate a database operation statement and execute it in the business database 03. Only after the business database 03 receives a commit instruction from the business client 011 will it persistently update its business data based on the execution result of the database operation statement, i.e., perform the commit operation.

[0085] Therefore, if a transaction branch contains only one operation on business database 03, then business client 011 on business server 01 only needs to generate and execute one database operation statement to implement the transaction branch. Once the database operation statement is executed, the transaction branch can be committed. If a transaction branch contains multiple operations on the business database, then business client 011 on business server 01 needs to generate and execute multiple database operation statements to implement the transaction branch. Only after all multiple database operation statements are executed can the transaction branch be committed.

[0086] Based on this, in each business server 01 provided in this embodiment, if the number of database operation statements used to implement its pending transaction branch is equal to 1, the business client 011 can set the auto-commit function of its corresponding business database 03 to the enabled state, that is, the business database 03 can automatically commit the transaction branch. If the business client 011 determines that the number of database operation statements used to implement its pending transaction branch is greater than 1, the business client 011 can set the auto-commit function of its corresponding business database 03 to the disabled state, that is, the business database 03 can only commit the transaction branch after receiving the commit instruction sent by the business client 011.

[0087] Figure 3This is a flowchart illustrating a distributed transaction processing method provided in an embodiment of this application. This method can be applied to, for example... Figure 1 or Figure 2 The system shown is described. Embodiments of this application apply this method to systems such as... Figure 2 The system shown is illustrated using an example where the transaction branch to be executed by the first business client contains only one database operation. (Reference) Figure 3 The method may include:

[0088] Step 101: The first business client sends a request to the transaction server to create a distributed transaction.

[0089] After receiving a business request, if the first business client determines that the service requested by the business request needs to be implemented jointly by the first business client and at least one second business client, it can respond to the business request by sending a distributed transaction creation request to the transaction server.

[0090] For example, suppose the first business client is a business client of Bank A, and the business request is a transfer request to transfer funds from a first account in Bank A to a second account in Bank B. Since the transfer service requested by this request requires the joint participation of both the business clients of Bank A and Bank B, the business client of Bank A can respond to this business request by sending a distributed transaction creation request to the transaction server.

[0091] Step 102: The transaction server sends the identifier of the distributed transaction to the first business client.

[0092] After receiving a request to create a distributed transaction, the transaction server can assign an identifier (ID) to the distributed transaction and send the identifier to the first business client.

[0093] Optional, such as Figure 2As shown, the first business client 011a can deploy an application programming interface (API) module 0111, which includes a Begin Transaction API. The first business client 011a can call this Begin Transaction API to send a distributed transaction creation request R1 to the transaction server 02 to obtain the ID of the distributed transaction, and then construct the context of the distributed transaction. The input parameters of the Begin Transaction API can include the address of the transaction server 02, and the return value can include the ID of the distributed transaction. If the ID allocation fails due to factors such as a failure of the transaction server 02, the return value can be -1. The address of the transaction server 02 is stored locally on the first business client 011a, and the address of the transaction server 02 can include the Internet protocol (IP) address and port number of the transaction server. The data type of the input parameters of the Begin Transaction API can be string, and the data type of the return value can be long integer.

[0094] refer to Figure 2 It can also be seen that the first business client 011a also includes a communication module 0112. The distributed transaction creation request R1 sent by the API module 0111 can be sent to the first network proxy node 012a through the communication module 0112, and then the first network proxy node 012a will transmit it to the transaction server 02. Correspondingly, the distributed transaction ID returned by the transaction server 02 can also be transmitted by the first network proxy node 012a to the communication module 0112 of the first business client 011a, and then the communication module 0112 will transmit it to the API module 0111.

[0095] Step 103: The first business client generates a database operation statement to implement the transaction branch to be executed in the distributed transaction.

[0096] After receiving the distributed transaction ID, the first business client can determine the transaction branch to be executed within the distributed transaction based on the business request, and generate a database operation statement to implement that transaction branch. The first business database corresponding to the first business client can be a relational database, and the database operation statement can be a Structured Query Language (SQL) statement.

[0097] refer to Figure 2 It can also be seen that the first business client 011a also includes a processing module 0115, which can generate a database operation statement for implementing the transaction branch to be executed in the distributed transaction.

[0098] For example, suppose the business request is to transfer 1000 yuan from a first account in Bank A to a second account in Bank B. Then, the business client of Bank A can determine that its transaction branch to be executed is: deduct 1000 yuan from the balance of the first account. Accordingly, the business client of Bank A can generate a database operation statement to instruct the balance of the first account to be reduced by 1000.

[0099] Step 104: The first service client sends the first setting instruction to the first service database.

[0100] Since the number of database operation statements used to implement the transaction branch is equal to 1, the first business client can determine that the transaction branch can be committed after the database operation statement is executed. Therefore, it can send a first setting instruction to the first business database, which is used to instruct the automatic commit function of the first business database to be enabled.

[0101] Example, reference Figure 2 The first business client 011a also includes a database driver 0113. When the processing module 0115 detects that the number of database operation statements is equal to 1, it instructs the database driver 0113 to send a first setting command to the first business database 03 through the communication module 0112.

[0102] Step 105: The first network proxy node obtains the first setting instruction and records that the automatic submission function of the first business database is enabled.

[0103] Since the first setting instruction sent by the first service client to the first service database needs to be forwarded through the first network proxy node, the first network proxy node can obtain the first setting instruction and record that the auto-submission function of the first service database is enabled based on the first setting instruction. Furthermore, the first network proxy node can forward the first setting instruction to the first service database after completing the status recording.

[0104] By recording the status of the auto-commit function of the first business database, the first network proxy node can ensure that it can accurately determine whether the auto-commit function is enabled when creating a transaction branch later. Furthermore, the first network proxy node can determine whether the number of database operation statements used to implement the transaction branch is greater than one based on the status of the auto-commit function, and can use different methods to acquire the lock information of the transaction branch and create the transaction branch based on the number of database operation statements.

[0105] For example, the first network proxy node may record the status flag of the first business database. After receiving the first setting instruction, the first network proxy node may set the status flag to true to indicate that the automatic submission function of the first business database is enabled.

[0106] In the embodiments of this application, such as Figure 2 As shown, the first network proxy node 012a may include a connection management module 0121, a parsing module 0122, and a pass-through module 0123. The connection management module 0121 can intercept each data packet sent by the first service client 011a and detect whether the recipient of each data packet is the first service database 03a. If the recipient of the data packet is the first service database 03a, the connection management module 0121 can send the data packet to the parsing module 0122, which can parse the data packet. If the recipient of the data packet is not the first service database 03a, the connection management module 0121 can send the data packet to the pass-through module 0123, which can directly pass-through the data packet. Pass-through means directly transmitting the data packet to the destination address without parsing the content of the data packet or making any changes to its content.

[0107] by Figure 2 For example, suppose the first network proxy node 012a receives a distributed transaction creation request R1 sent by the first business client 011a. Since the recipient of the distributed transaction creation request R1 is the transaction server 02, and not the first business database 03a, the transparent transmission module 0123 of the first network proxy node 012a can directly transmit the distributed transaction creation request R1 to the transaction server 02.

[0108] Step 106: The first business client generates a database operation instruction based on the database operation statement and the context of the distributed transaction.

[0109] In this embodiment, the first service client can combine the context of a distributed transaction with the database operation statement to generate a database operation instruction. The context of the distributed transaction includes the identifier of the distributed transaction. It may also include the address of the transaction server, which is pre-stored in the first service client.

[0110] Because the database operation command carries the context of a distributed transaction, the first network proxy node can create and process transaction branches based on this command. Since the first business client does not need to create and process transaction branches, the impact on its original business logic is minimal, effectively reducing the development cost of applying the first business client to the distributed transaction processing system.

[0111] Optionally, the first business client can add the context of the distributed transaction as a hint to the database operation statement according to the syntax format corresponding to the database type of the first business database, thereby obtaining a database operation instruction. For example, refer to... Figure 2 The API module 0111 of the first business client 011a also includes an operation instruction creation API. The first business client 011a can generate database operation instructions L1 by calling this operation instruction creation API. The input parameters of this operation instruction creation API can include: a database operation statement, a database type, and a distributed transaction context. The data types of the database operation statement and the database type can both be string, while the data type of the distributed transaction context can be long. The return value of the operation instruction creation API is the database operation instruction carrying the distributed transaction context. If the operation instruction creation API fails to execute, the return value is empty. The data type of the return value can be string.

[0112] Furthermore, in order to facilitate the first network agent node in recognizing the context of distributed transactions in the database operation instruction, the first business client can also add a distributed transaction keyword to the database operation instruction. This distributed transaction keyword can be used to indicate that the database operation instruction contains a distributed transaction context.

[0113] For example, suppose the distributed transaction key is AA, the distributed transaction identifier is ID1, the transaction server's IP address is xxxx, and the database operation statement used to instruct the balance of the first account "yy" to be reduced by 1000 is an SQL statement:

[0114] UPDATE table1 SET a1=a1-1000 WHERE b1='yy';

[0115] Then, after the first business client combines the SQL statement and the context of the distributed transaction through the operation instruction creation API, the generated database operation instruction can be:

[0116] / *AA; ID: ID1; IP: xxxx* / UPDATE table1 SET a1=a1-1000 WHERE b1='yy'.

[0117] Step 107: The first service client sends the database operation instruction to the first service database.

[0118] After the first business client generates the database operation instruction, it can send the database operation instruction to the first business database.

[0119] Optional, see reference Figure 2 The database driver 0113 in the first service client 011a can send the database operation command L1 generated by the API module 0111 to the first service database 03a. Since the first network proxy node 012a can intercept the data packets sent by the first service client 011a, therefore... Figure 2 As shown, the first network proxy node 012a can obtain the database operation instruction L1 sent by the first service client 011a. The database operation instruction L1 can be used by the first network proxy node that obtained the database operation instruction to create and process the transaction branch.

[0120] Step 108: The first business client sends a service call request to the second business client.

[0121] Since this distributed transaction also requires the participation of a second business client within a second business server, the first business client needs to send a service call request to this second business client. This service call request can carry the context of the distributed transaction. Specifically, this service call request can be a remote procedure call (RPC) request.

[0122] Example, reference Figure 2The first service client 011a also includes a service invocation module 0114, which can send a service invocation request Q1 to the second service client 011b. This service invocation request Q1 can be transparently transmitted to the second service client 011b through the first network proxy node 012a and the second network proxy node 012b. Upon intercepting the service invocation request Q1, the first network proxy node 012a can identify that the recipient of the service invocation request Q1 is not the first service database 03a; therefore, the first network proxy node 012a can directly forward the data packet to the second service client 011b.

[0123] Suppose that the first business client 011a receives a business request to transfer 1,000 yuan from the first account of Bank A to the second account of Bank B. Then the business client of Bank A can send a service call request to the business client of Bank B to instruct that the balance of the second account be increased by 1,000 yuan.

[0124] Step 109: The first network proxy node obtains the database operation instruction and retrieves the dataset targeted by the database operation statement from the first business database.

[0125] Since the recipient of the database operation instruction is the first business database, the first network proxy node can obtain the database operation instruction and retrieve the dataset targeted by the database operation statement from the first business database. Optionally, the first network proxy node can parse the database operation statement from the database operation instruction, then create and run the dataset retrieval statement, thereby retrieving the dataset targeted by the database operation statement from the first business database.

[0126] For example, such as Figure 2 As shown, the first network proxy node 012a also includes a transaction branch processing module 0124 and a database driver 0125. The parsing module 0122 can parse database operation statements (e.g., SQL statements) and the context of distributed transactions from database operation instructions, and send the database operation statements and the context of distributed transactions to the transaction branch processing module 0124. The transaction branch processing module 0124 can create a dataset retrieval statement. For example, the dataset retrieval statement created by the transaction branch processing module 0124 can be: `Select for update`. Then, the transaction branch processing module 0124 can run the dataset retrieval statement `Select for update` through the database driver 0125, thereby obtaining the dataset targeted by the database operation statement.

[0127] It should be noted that, in this embodiment, after receiving the database operation instruction sent by the first service client, the first network proxy node can first detect whether the database operation instruction carries the context of a distributed transaction. If the database operation instruction carries the context of the distributed transaction, it can obtain the dataset targeted by the database operation statement and continue to execute subsequent operations.

[0128] If the database operation instruction does not carry the context of a distributed transaction, the first network proxy node can determine that the database operation statement in the instruction is not used to implement a transaction branch in a distributed transaction. Therefore, it can directly transmit the database operation instruction to the first business database without obtaining the dataset or performing any subsequent operations.

[0129] Step 110: The first network proxy node obtains the lock information of the dataset.

[0130] Since the first network proxy node has already determined that the auto-commit function of the first business database is enabled according to the first setting instruction in step 105 above, it can be determined that the database operation statement in the database operation instruction can independently implement a transaction branch. Therefore, the first network proxy node can obtain the lock information of the dataset targeted by the database operation statement; the lock information of this dataset is the lock information of the transaction branch. For example, refer to... Figure 2 The transaction branch processing module 0124 in the first network proxy node 012a can obtain the lock information of the dataset targeted by the database operation statement.

[0131] The dataset targeted by the database operation statement can refer to the collection of data that the statement operates on. The lock information for this dataset can be used to uniquely identify the dataset targeted by the database operation statement in the first business database. For example, the lock information for the dataset may include the table name of the table containing the dataset and the primary key of the row containing the dataset.

[0132] Step 111: The first network proxy node sends a transaction branch creation request to the transaction server.

[0133] Once the first network proxy node obtains the lock information for the dataset, i.e., the lock information for the transaction branch, it can send a transaction branch creation request to the transaction server. This request can include the lock information for the dataset and the identifier of the distributed transaction. For example, refer to... Figure 2 The transaction branch processing module 0124 in the first network proxy node 012a can send a transaction branch creation request S1 to the transaction server 02.

[0134] It should be noted that this scenario involves the first business database having its auto-commit function enabled, and the transaction branch to be executed by the first business client participating in a distributed transaction. Since the first network proxy node needs to execute database operation statements in the first business database, as well as retrieve the dataset, acquire its lock information, and request the creation of a transaction branch, and can only commit the transaction branch after all of these operations are successfully completed, the first network proxy node needs to send a second setting instruction to the first business database before requesting the creation of the distributed transaction branch from the transaction server. This second setting instruction instructs the first business database to disable its auto-commit function. This ensures that the first business database will not automatically commit the transaction branch after the database operation statements are executed, but will only commit the transaction branch under the instruction of the first network proxy node after the first network proxy node confirms its successful creation. This second setting instruction can be sent by the transaction branch processing module 0124 to the first business database 03a via the database driver 0125.

[0135] Step 112: The transaction server sends a creation response to the first network proxy node.

[0136] After receiving the request to create the transaction branch, the transaction server can determine whether the transaction branch can be created based on the lock information of the dataset.

[0137] If the transaction server detects that the lock information of the dataset in the creation request is different from the lock information of other transaction branches it stores, it can determine that the dataset targeted by the database operation statement used to implement the transaction branch is not locked, and therefore can determine that the transaction branch can be created. The transaction server can then assign an identifier to the transaction branch and send a first creation response to the first network proxy node, indicating that the transaction branch has been successfully created. This first creation response carries the identifier of the transaction branch. Furthermore, the transaction server can also store the lock information of the dataset in the creation request, i.e., lock the dataset targeted by the database operation statement.

[0138] If the transaction server detects that the lock information of the dataset in the creation request is the same as the lock information of another transaction branch it stores, it can determine that the dataset targeted by the database operation statement used to implement that transaction branch has been locked, and therefore it can be determined that the transaction branch cannot be created. The transaction server can then send a second creation response to the first network proxy node to indicate that the creation of the transaction branch has failed.

[0139] Step 113: The first network proxy node checks whether the transaction branch has been created successfully.

[0140] After receiving the creation response from the transaction server, the first network proxy node can detect whether the transaction branch was created successfully based on the creation response. If the creation response received by the first network proxy node is a second creation response indicating that the creation of the transaction branch failed, the first network proxy node can execute step 114; if the creation response received by the first network proxy node is a second creation response indicating that the creation of the transaction branch was successful, the first network proxy node can execute step 115. For example, the transaction branch processing module 0124 in the first network proxy node 011a can detect whether the transaction branch was created successfully based on the received creation response.

[0141] Step 114: The first network agent node sends the first rollback instruction for the transaction branch to the first business database.

[0142] If the first network proxy node receives the second creation response from the transaction server, it can determine that the creation of the transaction branch has failed, and can then send a first rollback instruction for that transaction branch to the first business database. The first business database can respond to this first rollback instruction and perform a rollback operation. For example, the first business database can respond to this first rollback instruction and restore its auto-commit function to the enabled state.

[0143] For example, the transaction branch processing module 0124 in the first network agent node 011a can send a first rollback instruction for the transaction branch to the first business database 03a through the database driver 0125.

[0144] Step 115: The first network proxy node executes the database operation statement in the first business data.

[0145] If the first network proxy node receives the first creation response sent by the transaction server, it can determine that the transaction branch has been successfully created, and then the database operation statement can be executed in the first business data.

[0146] For example, refer to Figure 2 The transaction branch processing module 0124 in the first network agent node 012a can execute SQL statements in the first business data 03a through the database driver 0125.

[0147] Step 116: The first network proxy node stores the identifier of the transaction branch and the corresponding relationship of the dataset in the transaction log of the distributed transaction.

[0148] After the first network proxy node completes the database operation statement, it can also record the identifier of the transaction branch and the corresponding dataset targeted by the database operation statement in the transaction log of the distributed transaction. This allows for rollback operations based on the dataset recorded in the transaction log when the transaction branch needs to be rolled back later. The transaction log can be a log table created in the first business database to record relevant data for distributed transactions. For example, the transaction branch processing module 0124 in the first network proxy node 011a can store the identifier of the transaction branch and the dataset in the transaction log of the distributed transaction.

[0149] It should be noted that steps 115 and 116 above can also be executed after step 109 and before step 111. That is, the first network proxy node can also execute the database operation statement first, and then request the creation of the transaction branch. Correspondingly, in step 114 above, when the first business database performs the rollback operation, it also needs to roll back its business data to the state before the execution of the database operation statement. Therefore, by executing the database operation statement only after confirming the successful creation of the transaction branch, the problem of the previously executed database operation statement becoming invalid if the transaction branch creation fails after execution can be avoided. In other words, in the scenario where the transaction branch creation fails, the database operation statement is not executed, thus avoiding wasting the computing resources of the first business server.

[0150] Step 117: The first network proxy node sends a first commit instruction for the transaction branch to the first business database.

[0151] After confirming the successful creation of a transaction branch and recording its identifier and corresponding dataset in the distributed transaction log, the first network proxy node can send a first commit instruction for that transaction branch to the first business database. This first commit instruction instructs the first business database to commit the transaction branch. For example, the transaction branch processing module 0124 in the first network proxy node 011a can send the first commit instruction for that transaction branch to the first business database 03a via the database driver 0125.

[0152] Step 118: The first network proxy node sends the commit result of the transaction branch to the first business client.

[0153] After the first network proxy node sends the first commit instruction for the transaction branch to the first business database, it can also receive a commit response returned by the first business database. If the first business database successfully commits the transaction branch, the commit response indicates that the transaction branch has been successfully committed. Accordingly, the first network proxy node can send a commit result to the first business client indicating that the transaction branch has been successfully committed. If the first business database fails to commit the transaction branch due to a fault or other factors, the commit response indicates that the transaction branch has failed. Accordingly, the first network proxy node can send a commit result to the first business client indicating that the transaction branch has failed. For example, the transaction branch processing module 0124 in the first network proxy node 011a can send the commit result of the transaction branch to the first business client 011a.

[0154] It should be noted that after sending the first commit instruction, the first network proxy node can also delete its cached lock information. Furthermore, if the first network proxy node determines that the transaction branch commit has failed, it can also send a fourth rollback instruction for that transaction branch to the first business database and a notification message carrying the identifier of that transaction branch to the transaction server. The fourth rollback instruction can be used to instruct the first business database to perform a rollback operation, and the notification message can be used to instruct the transaction server to delete the lock information for that transaction branch, i.e., instruct the transaction server to release the lock for that transaction branch.

[0155] The first network proxy node completes the first phase of the distributed transaction after sending the first rollback instruction to the first business database or sending the commit result of the transaction branch to the first business client. This first phase can also be called the request phase or the voting phase. Since the creation and processing of the transaction branch can be handled by the network proxy node during the first phase of the distributed transaction, and the business client only needs to call the transaction initiation API and the operation instruction creation API, the impact of these API calls on the original business logic of the business client is minimal. Therefore, the cost of adapting the business client to the distributed transaction processing architecture can be effectively reduced.

[0156] Step 119: The second service client sends a service call response to the first service client.

[0157] In this embodiment of the application, after receiving a service call request carrying a distributed transaction context sent by the first service client, the second service client can determine the transaction branch to be executed by the second service client based on the service call request, and then generate database operation statements for implementing the transaction branch.

[0158] For example, suppose the second business client is a business client of Bank B, and the service call request received by the business client of Bank B is used to instruct that the balance of the second account be increased by 1000. Then the business client of Bank B can generate a database operation statement to instruct that the balance of the second account be increased by 1000.

[0159] refer to Figure 2 It can be seen that the second business client 011b also deploys an API module 0111, a communication module 0112, a database driver 0113, a service call module 0114, and a processing module 0115. The processing module 0115 of the second business client 011b can generate a database operation instruction L2 by calling the API module 0111, and send the database operation instruction L2 to the second business database 03b through the database driver 0113. For example... Figure 2 As shown, the connection management module 0121 in the second network proxy node 012b can obtain the database operation instruction L2, and the parsing module 0122 can parse the database operation instruction L2. Then, the transaction branch processing module 0124 can send a transaction branch creation request S2 to the transaction server 01 based on the parsed database operation instruction L2 to create and process the transaction branch. After processing the transaction branch, the transaction branch processing module 0124 of the second network proxy node 012b can return the transaction branch commit result to the second business client 011b.

[0160] If the processing module 0115 of the second business client 011b determines that the transaction branch was successfully committed based on the commit result, it can send a service call response to the first business client 011a to indicate that the service call was successful. If the processing module 0115 of the second business client 011b determines that the transaction branch was unsuccessful based on the commit result, it can send a service call response to the first business client 011a to indicate that the service call failed. This service call response can be transparently transmitted to the first business client 011a through the second network proxy node 012b and the first network proxy node 012a.

[0161] That is, after step 108 above, the second service client 011b can execute the methods shown in steps 103, 104, and 106 to 108 above, and the second network proxy node 012b can execute the methods shown in steps 105 and 109 to 118 above. The operations performed by the second service client 011b and the second network proxy node 012b can be referred to the relevant descriptions in steps 103 to 118 above, and will not be repeated here.

[0162] It should be noted that after receiving the service call request sent by the first service client 011a, if the processing module 0115 of the second service client 011b determines that running its own service is sufficient to implement the transaction branch to be executed, then it does not need to call the services of other service clients, i.e., it does not need to execute the method shown in step 108 above. If the processing module 0115 of the second service client 011b determines that it is necessary to call the service of the third service client in the third service server, it can instruct the service call module 0114 to execute the method shown in step 108 above. Correspondingly, the third service client and the third network proxy node in the third service server also need to execute the methods shown in steps 103 to 118 above. That is, in addition to the first and second service servers, the third service server is also one of the participants in this distributed transaction.

[0163] It should also be noted that the first business client can send the service call request to the second business client only after confirming that its transaction branch has been successfully committed. That is, step 108 can also be executed after step 118. Accordingly, the distributed transaction context carried in the service call request sent by the first business client to the second business client can also include: the identifier of the transaction branch executed by the first network proxy node. The identifier of the transaction branch can be sent by the first network proxy node to the first business client after receiving the first creation response.

[0164] If the distributed transaction context carried in the service call request received by the second business client also includes the identifier of the transaction branch executed by the first network proxy node, then the distributed transaction context carried in the database operation instruction generated by the second business client will also include the identifier of the transaction branch executed by the first network proxy node. Therefore, the transaction branch creation request sent by the second network proxy node to the transaction server can carry both the identifier of the distributed transaction and the identifier of the transaction branch executed by the first network proxy node. Upon receiving the transaction branch creation request, the transaction server can determine that the first business client has called the service of the second business client. In other words, the transaction server can clarify the service call details between various business clients based on the transaction branch identifier carried in the transaction branch creation request.

[0165] It should also be noted that the first business client can generate database operation statements only after confirming the successful service call from the second business client. That is, steps 108 and 109 can be executed before step 103. Alternatively, step 108 can be executed synchronously with step 103, meaning the first and second business servers can process transaction branches simultaneously, thus ensuring the efficiency of distributed transaction processing.

[0166] In scenarios where the first business client completes its transaction branch before sending a service call request, if the first business client determines that its transaction branch creation or commit has failed, it can preemptively determine that the distributed transaction has failed. Therefore, the first business client does not need to send a service call request to the second business client, meaning it does not need to execute step 108. This avoids wasting the computing resources of the second business server.

[0167] Similarly, in a scenario where the first business client calls the service of the second business client first, and then processes its transaction branch, if the first business client determines that the service call of the second business client has failed, it can also determine in advance that the distributed transaction has failed. Therefore, the first business client does not need to execute steps 103, 104, 106, and 107 as described above. This avoids wasting the computing resources of the first business server.

[0168] Step 120: Based on the submission result and the service call response, the first business client sends a commit instruction or rollback instruction for the distributed transaction to the transaction server.

[0169] After receiving the commit result of the transaction branch sent by the first network proxy node and the service call response sent by the second business client, if the first business client determines that the transaction branch in the first business server has been successfully committed and the service call of the second business client has been successfully made, it can be determined that all transaction branches used to implement the distributed transaction have been successfully committed. Therefore, a commit instruction for the distributed transaction can be sent to the transaction server. This commit instruction is used to instruct the commit of all transaction branches included in the distributed transaction.

[0170] If the first business client determines that the transaction branch in the first business server has failed to commit, or the service call of the second business client has failed, it can send a rollback instruction to the transaction server for the distributed transaction. This rollback instruction instructs the rollback of all transaction branches included in the distributed transaction. Both the commit and rollback instructions for the distributed transaction carry the context of that distributed transaction.

[0171] It should be noted that, in this embodiment, the first business client can invoke the services of multiple second business clients. Correspondingly, the first business client can receive service call responses from these multiple second business clients. Therefore, the first business client can only determine that all transaction branches used to implement the distributed transaction have been successfully committed and send a commit instruction for the distributed transaction after confirming that the transaction branch in the first business server has been successfully committed and that the service calls of each second business client have been successfully executed. Similarly, if the first business client determines that the transaction branch in the first business server has failed to commit, or that the service call of any second business client has failed, it can send a rollback instruction for the distributed transaction.

[0172] For example, such as Figure 2 As shown, the API module 0111 in the first business client 011a may also include a commit / rollback transaction API. The processing module 0115 of the first business client 011a can send a commit instruction R2 for the distributed transaction to the transaction server 02 by calling the CommitTransaction API, or it can send a rollback instruction R2 for the distributed transaction to the transaction server 02 by calling the RollbackTransaction API. (Reference) Figure 2 It can be seen that the commit or rollback instruction R2 for the distributed transaction can be transmitted to the transaction server 02 by the pass-through module 0123 of the first network agent node 012a.

[0173] The input parameters for each API in both the commit and rollback transaction APIs can include the address of the transaction server and the identifier of the distributed transaction. The commit API returns 0 if the commit was successful and -1 if it failed. Similarly, the rollback API returns 0 if the rollback was successful and -1 if it failed. The return value of each API in both the commit and rollback transaction APIs can be of integer type (int).

[0174] It should also be noted that if the first business client can determine that the distributed transaction has failed based on the received commit results or partial service call responses, it can directly send a rollback instruction for the distributed transaction to the transaction server without waiting for all commit results and service call responses to be received before sending the rollback instruction. This can effectively improve the processing efficiency of distributed transactions.

[0175] Step 121: The transaction server sends a third commit instruction or a third rollback instruction for the transaction branch to each network proxy node in the business server participating in the distributed transaction.

[0176] After receiving a commit or rollback command from the first business client for the distributed transaction, the transaction server can first determine the various business servers participating in the distributed transaction, as well as the transaction branch executed by each business server. Then, it can send a third commit or third rollback command for the transaction branch executed by each business server to the network proxy node within that business server. Both the third commit and third rollback commands can carry the identifier of the transaction branch executed by that business server.

[0177] Example, reference Figure 2 Assume that the business servers participating in the distributed transaction include a first business server 01a and a second business server 01b, and that the first business server 01a executes transaction branch 1 of the distributed transaction, while the second business server 01b executes transaction branch 2. Then, after receiving the commit instruction for the distributed transaction from the first business client 011a, transaction server 02 can send a third commit instruction Z1 for transaction branch 1 to the first network proxy node 012a, and a third commit instruction Z2 for transaction branch 2 to the second network proxy node 012b. If the second business server 01b also calls a business client in the third business server to execute transaction branch 3, then transaction server 02 also needs to send a third commit instruction for transaction branch 3 to the network proxy node 012b in the third business server.

[0178] Step 122: The first network proxy node processes the received instructions.

[0179] If the first network proxy node receives a third commit instruction for the transaction branch sent by the transaction server, it can clean up the transaction branch identifier and the corresponding dataset recorded in the transaction log of the distributed transaction according to the transaction branch identifier carried in the third commit instruction.

[0180] If the first network proxy node receives a third rollback instruction for a specific transaction branch from the transaction server, it can retrieve the corresponding dataset from the distributed transaction log based on the transaction branch identifier carried in the instruction. The first network proxy node can then create a dataset rollback statement based on this dataset and execute it in the first business database, thereby rolling back the transaction branch. In other words, by executing the dataset rollback statement, the first network proxy node can restore the business data in the first business database to its state before the transaction branch was executed.

[0181] For example, if the database operation statement used to implement this transaction branch is an update statement, then the dataset rollback statement created by the first network agent node can also be an update statement. If the database operation statement used to implement this transaction branch is an insert statement, then the dataset rollback statement created by the first network agent node can be a delete statement. If the database operation statement used to implement this transaction branch is a delete statement, then the dataset rollback statement created by the first network agent node can be an insert statement.

[0182] It should be noted that after the second network proxy node receives the third commit instruction or the third rollback instruction sent by the transaction server, it can also process the received instruction using the method shown in step 122 above. This embodiment of the application will not elaborate further on this. For example, refer to... Figure 2 Each network proxy node's transaction branch processing module 0124 can be used to process received instructions. After processing the third commit instruction or third rollback instruction sent by the transaction server, each network proxy node can complete the second phase of the distributed transaction. This second phase can also be called the commit phase or execution phase.

[0183] As described above, in the second phase of distributed transaction operations, the commit or rollback of transaction branches can be implemented by the network proxy node, while the business client only needs to call the commit / rollback transaction API. The call to this API has low intrusion into the business, that is, it has little impact on the original business logic of the business client. Therefore, it can effectively reduce the cost of business clients adapting to the distributed transaction processing architecture to achieve distributed transformation.

[0184] It should also be noted that if a network proxy node has already performed a rollback operation before step 122 above due to a failure to create or commit a transaction branch, then in step 122 above, the network proxy node does not need to process the third rollback instruction again.

[0185] Alternatively, each network proxy node can send the commit result of the transaction branch to the transaction server after step 117 above. The transaction server can then determine whether the transaction branch in each business server has been executed successfully based on the commit result. Correspondingly, in step 121 above, the transaction server can send the third rollback instruction only to the network proxy nodes in the business servers where the transaction branch has been executed successfully, without having to send the third rollback instruction to the network proxy nodes in the business servers where the transaction branch has failed to execute.

[0186] In summary, this application provides a method for processing distributed transactions. In this method, the database operation instructions sent by the business client to the business database can carry the context of the distributed transaction, enabling the network proxy node to create and process transaction branches based on the context of the distributed transaction and the database operation statements. Since transaction branches can be created and processed through the network proxy node, the business client does not need to deploy interfaces for creating and processing transaction branches (e.g., try, confirm, and cancel interfaces), thereby effectively reducing the development cost for the business client to apply to the distributed transaction processing system.

[0187] Furthermore, compared to traditional TCC technology, the solution provided in this application allows for the creation and processing of transaction branches to be handled by network proxy nodes during the implementation of distributed transactions. The business client only needs to call the transaction initiation API, operation instruction creation API, and transaction commit / rollback API. These API calls have low intrusiveness to the business logic, meaning they have minimal impact on the client's existing business logic. Therefore, this effectively reduces the cost for business clients adapting to a distributed transaction processing architecture within a Platform as a Service (PaaS) platform, thus improving the efficiency of distributed transformation. Moreover, the transaction initiation API, operation instruction creation API, and transaction commit / rollback API can all be provided by the PaaS platform. Because these APIs are relatively simple, they can support multiple programming languages. This ensures that business clients developed using different programming languages ​​can deploy these APIs during distributed transformation, enabling the implementation of a cross-programming language distributed transaction processing system at a lower development cost.

[0188] Furthermore, since each business client in this distributed transaction processing system interacts with the business database using a database protocol, and the network proxy node can create and process transaction branches using database operation instructions carrying the context of the distributed transaction, even if the various business clients in the distributed transaction processing system are developed using different programming languages, it will not affect the creation and processing of transaction branches by the network proxy node. That is, based on the solution provided in this application embodiment, the network proxy node only needs to support the database protocol to adapt to business clients developed using different programming languages. Therefore, the solution in this application embodiment can achieve data consistency in distributed transactions for cross-programming language distributed transaction processing systems at a lower cost.

[0189] Figure 4 This is a flowchart of another distributed transaction processing method provided in an embodiment of this application. This method can be applied to, for example... Figure 1 or Figure 2 The system shown is described. Embodiments of this application apply this method to systems such as... Figure 2 The system shown is illustrated using an example where the transaction branch to be executed by the first business client contains multiple database operations. (Reference) Figure 4 The method may include:

[0190] Step 201: The first business client sends a request to the transaction server to create a distributed transaction.

[0191] The implementation process of step 201 can be referred to Figure 3 The relevant description of step 101 in the illustrated embodiment will not be repeated here.

[0192] Step 202: The transaction server sends the identifier allocated for the distributed transaction to the first business client.

[0193] The implementation process of step 202 can be referred to Figure 3 The relevant description of step 102 in the illustrated embodiment will not be repeated here.

[0194] Step 203: The first business client generates multiple database operation statements to implement the transaction branches to be executed in the distributed transaction.

[0195] The implementation process of step 203 can be referred to Figure 3 The relevant description of step 103 in the illustrated embodiment will not be repeated here.

[0196] Step 204: The first business client sends a second setting command to the first business database.

[0197] Since the number of database operation statements used to implement this transaction branch is greater than one, the first business client can determine that the transaction branch can only be committed after all these multiple database operation statements have been executed. Therefore, it can send a second setting instruction to the first business database, which instructs the automatic commit function of the first business database to be disabled. For example, refer to... Figure 2 When the processing module 0115 of the first business client 011a detects that the number of database operation statements is greater than 1, it instructs the database driver 0113 to send a second setting instruction to the first business database 03a.

[0198] Step 205: The first network proxy node obtains the second setting instruction and records that the automatic submission function of the first business database is in the off state.

[0199] Since the second setting instruction sent from the first business client to the first business database needs to be forwarded through the first network proxy node, the first network proxy node can obtain the second setting instruction and record that the auto-commit function of the first business database is disabled based on the second setting instruction. Furthermore, after completing the status recording, the first network proxy node can forward the second setting instruction to the first business database. The fact that the first network proxy node records the auto-commit function of the first business database as disabled indicates that the number of database operation statements used to implement the transaction branch is greater than one. Therefore, upon receiving the database operation instruction, the first network proxy node can determine how to acquire the lock information for the transaction branch and create the transaction branch.

[0200] For example, the first network proxy node may record the status flag of the first business database. After receiving the second setting instruction, the first network proxy node may set the status flag to false to indicate that the auto-commit function of the first business database is off. For example, the transaction branch processing module 0124 in the first network proxy node 012a may record the status flag of the first business database.

[0201] Step 206: The first business client generates multiple database operation instructions based on the multiple database operation statements and the context of the distributed transaction.

[0202] In this embodiment, for each database operation statement used to implement the transaction branch, the first business client can combine the context of the distributed transaction with the database operation statement to generate a database operation instruction. Since the number of database operation statements used to implement the transaction branch is greater than one in this embodiment, the first business client can generate multiple database operation instructions based on these multiple database operation statements. Each database operation instruction includes at least one database operation statement and the context of the distributed transaction. In this embodiment, "at least one" refers to one or more, and "multiple" refers to two or more. For example, each database operation instruction may include one database operation statement. The process of generating each database operation instruction can be referred to... Figure 3 The relevant description of step 106 in the illustrated embodiment will not be repeated here.

[0203] Step 207: The first business client sends multiple database operation instructions to the first business database.

[0204] After the first business client generates the multiple database operation instructions, it can send the multiple database operation instructions to the first business database in sequence.

[0205] For example, refer to Figure 2The database driver 0113 in the first network agent node 012a can send multiple database operation commands to the first business database 03a.

[0206] Step 208: The first business client sends a service call request to the second business client.

[0207] The implementation process of step 208 can be referred to Figure 3 The relevant description of step 108 in the illustrated embodiment will not be repeated here.

[0208] Step 209: The first network proxy node obtains the multiple database operation instructions and retrieves the dataset targeted by each database operation statement from the first business database.

[0209] For each database operation instruction obtained, the first network proxy node can parse the database operation statement from the instruction and then retrieve the dataset corresponding to that database operation statement from the first business database. The process of retrieving the dataset corresponding to each database operation statement can be found in [reference needed]. Figure 3 The relevant description of step 109 in the illustrated embodiment will not be repeated here.

[0210] Step 210: The first network proxy node obtains the lock information of the dataset targeted by each database operation statement.

[0211] The lock information for each dataset targeted by a database operation statement may include the table name of the data table containing the dataset and the primary key of the row containing the dataset. For example, the transaction branch processing module 0124 in the first network proxy node 012a can obtain the lock information for the dataset targeted by each database operation statement.

[0212] Step 211: The first network proxy node stores the dataset targeted by each database operation statement and the lock information of the dataset targeted by each database operation statement.

[0213] In this embodiment, if the first network proxy node determines that the auto-commit function of the first business database is disabled, it can determine that the number of database operation statements used to implement the transaction branch is greater than one. Therefore, the first network proxy node can determine that the transaction branch can only be created based on the obtained lock information after all the database operation statements used to implement the transaction branch have been successfully executed. Thus, the first network proxy node needs to store the dataset targeted by each database operation statement and the lock information of that dataset. Furthermore, to facilitate the subsequent creation or rollback of transaction branches, the first network proxy node can store the identifier of the distributed transaction, the dataset targeted by the multiple database operation statements used to implement the transaction branch, and the lock information of that dataset. That is, the first network proxy node can merge and store the datasets targeted by multiple database operation statements used to implement the same transaction branch, and can merge and store the lock information of the datasets targeted by the multiple database operation statements. For example, the transaction branch processing module 0124 in the first network proxy node 012a can store the dataset targeted by each database operation statement and the lock information of the dataset targeted by each database operation statement.

[0214] For example, assuming the identifier of the distributed transaction is ID1, in step 203 above, the database operation statements generated by the first business client to implement the transaction branch to be executed include Y1, Y2, and Y3. The datasets targeted by these three database operation statements are D1, D2, and D3, respectively, and the lock information for these three datasets is S1, S2, and S3, respectively. Then, the first network proxy node can store the correspondence between the identifier ID1 of the distributed transaction, the set of datasets D1, D2, and D3, and the set of lock information S1, S2, and S3.

[0215] Step 212: The first network proxy node executes each database operation statement in the first business database.

[0216] For example, after storing the dataset targeted by each database operation statement and the lock information of the dataset targeted by each database operation statement, the transaction branch processing module 0124 in the first network agent node 012a can execute the database operation statement in each database operation instruction in the first business data 03a through the database driver 0125.

[0217] Step 213: The first network proxy node sends the execution results of each database operation statement to the first business client.

[0218] After each database operation statement is executed, the first network proxy node sends the execution result to the first business client. This result indicates whether the database operation statement was executed successfully or failed. For example, the transaction branch processing module 0124 in the first network proxy node 012a can send the execution result of each database operation statement to the first business client 011a.

[0219] Step 214: The first business client checks whether each database operation statement has been executed successfully.

[0220] The first business client can detect whether each database operation statement used to implement the transaction branch has been executed successfully based on the execution result sent by the first network proxy node. If any database operation statement fails to execute, the first business client can execute step 215; if each database operation statement executes successfully, the first business client can execute step 218. For example, the processing module 0115 in the first business client 011a can detect whether each database operation statement has been executed successfully.

[0221] Step 215: The first business client sends a second rollback instruction for the transaction branch to the first business database.

[0222] If the first business client detects that any database operation statement has failed to execute, it can determine that the transaction branch has not been executed successfully, and therefore can send a second rollback instruction for that transaction branch to the first business database. For example, the processing module 0115 in the first business client 011a can instruct the database driver 0113 to send the second rollback instruction when it detects that any database operation statement has failed to execute.

[0223] Step 216: The first network proxy node deletes the stored dataset and lock information.

[0224] If the first network proxy node receives a second rollback instruction for the transaction branch sent by the first service client, it can determine that the transaction branch has failed. Therefore, it can delete the dataset targeted by each database operation statement and the lock information of that dataset, thus preventing the dataset and lock information from occupying excessive storage space. For example, the transaction branch processing module 0124 in the first network proxy node 012a can delete the dataset targeted by each database operation statement and the lock information of that dataset.

[0225] Step 217: The first network proxy node sends the second rollback instruction to the first business database.

[0226] After receiving the second rollback instruction, the first network proxy node can forward it to the first business database. Upon receiving the second rollback instruction, the first business database can roll back the transaction branch. For example, the transaction branch processing module 0124 in the first network proxy node 012a can send the second rollback instruction to the first business database 03a via the database driver 0125.

[0227] Step 218: The first business client sends a second commit instruction for the transaction branch to the first business database.

[0228] If the first business client detects that multiple database operation statements used to implement the transaction branch have been executed successfully, it can determine that the transaction branch has been executed successfully, and therefore can send a second commit instruction for the transaction branch to the first business database. For example, the processing module 0115 of the first business client 011a can instruct the database driver 0113 to send the second commit instruction when it detects that multiple database operation statements used to implement the transaction branch have been executed successfully.

[0229] Step 219: The first network proxy node obtains the lock information of the dataset targeted by each database operation statement stored in the database.

[0230] If the first network proxy node receives a second commit instruction for the transaction branch sent by the first service client, it can obtain the lock information of the dataset targeted by each database operation statement stored in step 211 above. The lock information of the datasets targeted by the multiple database operation statements obtained by the first network proxy node constitutes the lock information of the transaction branch. For example, the transaction branch processing module 0124 in the first network proxy node 012a can obtain the lock information of the dataset targeted by each stored database operation statement.

[0231] It should be noted that if the database operation statement in the database operation instruction received by the first network proxy node does not modify the data in the first business database, for example, when the database operation statement is a query statement, then the first network proxy node will not acquire and store the lock information of the dataset targeted by the database operation statement. Therefore, after receiving the second submit instruction, if the first network proxy node has not acquired the lock information of the dataset it has pre-stored, that is, the first network proxy node has not stored any lock information of the dataset before receiving the second submit instruction, then the first network proxy node can directly forward the second submit instruction without performing any subsequent operations.

[0232] Step 220: The first network proxy node sends a transaction branch creation request to the transaction server.

[0233] After obtaining the lock information for the transaction branch, the first network proxy node can send a transaction branch creation request to the transaction server. This request can include the lock information for the dataset and the identifier of the distributed transaction. For example, the transaction branch processing module 0124 in the first network proxy node 012a can send a transaction branch creation request to the transaction server 02.

[0234] After the first network proxy node sends a transaction branch creation request, the transaction server can determine whether the transaction branch can be created based on the lock information carried in the creation request. Since the lock information for the transaction branch carried in the creation request includes lock information from multiple datasets, the transaction server can determine that the transaction branch can be created if the lock information for each dataset is different from the lock information of other transaction branches it stores. If the transaction server detects that the lock information for any dataset is the same as the lock information of other transaction branches it stores, it can determine that the transaction branch cannot be created.

[0235] After step 220, the distributed transaction processing system can continue to execute the above. Figure 3 The methods shown in steps 112 to 122 of the illustrated embodiment will not be described again here.

[0236] In summary, this application provides a method for processing distributed transactions. In this method, the network proxy node can accurately determine whether the number of database operation statements used to implement the transaction branch is greater than one based on the status of the business database's auto-commit function. Furthermore, the network proxy node can acquire lock information and create transaction branches using different methods depending on the number of database operation statements, thereby effectively improving the flexibility of transaction branch creation.

[0237] In the distributed transaction processing system provided in this application embodiment, the network proxy node in each business server can intercept data packets sent by business clients on that business server and detect whether the recipient of the data packet sent by the business client is a business database. If the recipient of the data packet is a business database, the network proxy node can obtain the data packet and parse it. If the recipient of the data packet is not a business database, the network proxy node can directly forward the data packet.

[0238] To effectively intercept data packets sent from the business client to the business database, refer to Figure 5 Each network proxy node in the business server can also perform the following operations:

[0239] Step 301: Intercept data packets sent by the business client.

[0240] Step 302: Check whether the data packet is a new connection request.

[0241] For each data packet sent by the business client, the network proxy node can detect whether the data packet is a new connection request. If the data packet is a new connection request, the network proxy node can proceed to step 303; if the data packet is not a new connection request, the network proxy node can proceed to step 306.

[0242] Step 303: Create a new connection.

[0243] If the data packet sent by the service client is a new connection request, the network proxy node can establish a new connection with the party requested in the new connection request. For example, the network proxy node can create a socket connection with that party. Then, the network proxy node can proceed to step 304.

[0244] Step 304: Check whether the connection is a connection to the business database.

[0245] After establishing a connection with the connected party, the network proxy node can continue to check whether the connection is with the business database. If the connection is with the business database, step 305 can be executed. If the connection is not with the business database, step 301 can be executed, i.e., the data packets sent by the business client can continue to be intercepted. For example, if the connection is with the transaction server, the network proxy node can continue to execute step 301.

[0246] Optionally, the network proxy node can detect whether the connection is to the business database based on the connection protocol between the business client and the connection party.

[0247] Step 305: Mark the connection.

[0248] If the network proxy node detects that the connection is to the business database, it can mark the connection. For example, the network proxy node can add a detection flag to the connection's attribute description field to mark the connection. By marking the connection to the business database, it is easier to quickly detect whether the recipient of data packets sent by the business client is the business database. Afterwards, the network proxy node can continue to execute step 301, that is, continue to intercept data packets sent by the business client.

[0249] Step 306: Detect whether the data packet belongs to the marked connection.

[0250] In step 302 above, if the network proxy node detects that the data packet is not a new connection request, it can continue to check whether the data packet belongs to a marked connection, that is, continue to check whether the data packet is a data packet sent to the business database. For example, the network proxy node can check whether a detection tag has been added to the attribute description field of the connection to which the data packet belongs. If the detection tag has been added, it can be determined that the data packet belongs to the marked connection; if the detection tag has not been added, it can be determined that the data packet does not belong to the marked connection.

[0251] If the data packet belongs to the marked connection, the network proxy node can determine that the data packet is to be sent to the business database, and therefore can execute step 307; if the data packet does not belong to the marked connection, the network proxy node can determine that the data packet is not to be sent to the business database, and therefore can execute step 308.

[0252] Example, reference Figure 2 Each network proxy node may include a connection management module 0121, and the above steps 301 to 306 may be implemented by the connection management module 0121.

[0253] Step 307: Obtain and parse the data packet.

[0254] If a network proxy node detects that the data packet belongs to a tagged connection, it can retrieve and parse the packet. For example, the network proxy node can parse the packet based on a database protocol. (See reference) Figure 2 Each network proxy node may include a parsing module 0122, which can parse the data packet.

[0255] Optionally, the network proxy node can first detect whether the data packet is a setting instruction for setting the auto-commit status of the business database. If the data packet is such a setting instruction, the network proxy node can execute the method shown in step 105 or step 205 above. If the data packet is not such a setting instruction, the network proxy node can continue to detect whether the data packet is a commit instruction or rollback instruction for a transaction branch.

[0256] If the data packet is a commit instruction for a transaction branch, the network proxy node can execute the methods shown in steps 218 and 219 above; if the data packet is a rollback instruction for a transaction branch, the network proxy node can execute the method shown in step 216 above. If the data packet is neither a commit instruction nor a rollback instruction for a transaction branch, the network proxy node can continue to detect whether the data packet is a database operation instruction carrying the context of a distributed transaction.

[0257] If the data packet does not carry the context of a distributed transaction, the network proxy node can directly forward the data packet to the business database; if the data packet is a database operation instruction carrying the context of a distributed transaction, the network proxy node can execute the method shown in step 109 or step 209 above.

[0258] In this embodiment, since the network proxy node only needs to parse the data packets sent by the business client to the business database, and the business clients all interact with the business database based on the database protocol, the network proxy node only needs to support the database protocol to be compatible with business clients developed in different programming languages. That is, the solution provided in this embodiment can be applied to a cross-programming language distributed transaction processing system.

[0259] Step 308: Transmit the data packet.

[0260] If a network proxy node detects that the data packet does not belong to a marked connection, it can directly forward the data packet. For example, if the data packet is destined for a transaction server or other business server, the network proxy node can directly forward the data packet. (Reference) Figure 2 Each network proxy node may include a pass-through module 0123, which can pass through the data packet.

[0261] In summary, the method for intercepting data packets by a network proxy node provided in this application embodiment can effectively improve the efficiency of detecting whether the recipient of data packets sent by a business client is the business database, since the network proxy node can mark the connection when establishing a new connection with the business database. Furthermore, since the network proxy node can create and process transaction branches based on the data packets sent by the business client to the business database, it only needs to parse the data packets sent by the business client to the business database, while data packets sent to other recipients can be directly passed through. This avoids increasing the number of data packets parsed by the network proxy node and improves the efficiency of data packet parsing.

[0262] It should be noted that the order of steps in the distributed transaction processing method provided in this application embodiment can be appropriately adjusted, and steps can be added or removed as needed. For example, step 106 can be executed before step 105, and step 206 can be executed before step 205; step 108 can be executed before step 107, and step 208 can be executed before step 207. Alternatively, steps 115 and 116 can be executed before step 111. Or, step 119 can also be executed before step 118. Furthermore, step 108 can be executed after step 109, and step 208 can also be executed after step 209; for example, step 108 can be executed after step 118, and step 208 can be executed after step 218. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0263] In summary, this application provides a method for processing distributed transactions. In this method, the database operation instructions sent by the business client to the business database can carry the context of the distributed transaction, enabling the network proxy node to create and process transaction branches based on the context of the distributed transaction and the database operation statements. Since transaction branches can be created and processed through the network proxy node, the business client does not need to deploy interfaces for creating and processing transaction branches (e.g., try, confirm, and cancel interfaces), thereby effectively reducing the development cost for the business client to apply to the distributed transaction processing system.

[0264] Furthermore, compared to traditional TCC technology, the solution provided in this application allows for the creation and processing of transaction branches to be handled by network proxy nodes during the implementation of distributed transactions. Business clients only need to call the transaction initiation API, operation instruction creation API, and transaction commit / rollback API. These API calls have low intrusiveness to the business logic, meaning they have minimal impact on the client's existing business logic. Therefore, this effectively reduces the cost for business clients adapting to the distributed transaction processing architecture within the Platform as a Service (PaaS) platform, thus improving the efficiency of distributed transformation. Moreover, the transaction initiation API, operation instruction creation API, and transaction commit / rollback API can all be provided by the PaaS platform. Because these APIs are relatively simple, they support multiple programming languages. This ensures that business clients developed using different programming languages ​​can deploy these APIs during distributed transformation, enabling the implementation of a cross-programming language distributed transaction processing system at a lower development cost.

[0265] Furthermore, since each business client in this distributed transaction processing system interacts with the business database using a database protocol, and the network proxy node can create and process transaction branches using database operation instructions carrying the context of the distributed transaction, even if the various business clients in the distributed transaction processing system are developed using different programming languages, it will not affect the creation and processing of transaction branches by the network proxy node. That is, based on the solution provided in this application embodiment, the network proxy node only needs to support the database protocol to adapt to business clients developed using different programming languages. Therefore, the solution in this application embodiment can achieve data consistency in distributed transactions for cross-programming language distributed transaction processing systems at a lower cost.

[0266] This application provides a network proxy node that can be deployed on the business server of a distributed transaction processing system, for example, on... Figure 1 or Figure 2 In the business server 01 of the distributed transaction processing system shown. (Reference) Figure 1 and Figure 2 It can be seen that the distributed transaction processing system also includes a transaction server 02 and multiple business databases 03, and the business server 01 also deploys a business client 011. For example... Figure 2 As shown, the network proxy node includes: a connection management module 0121, a parsing module 0122, a pass-through module 0123, a transaction branch processing module 0124, and a database driver 0125.

[0267] The connection management module 0121 is used to receive one or more database operation instructions sent by the business client and send the one or more database operation instructions to the parsing module 0122.

[0268] The parsing module 0122 is used to acquire and parse each database operation instruction sent by the service client. Each database operation instruction includes a database operation statement and a distributed transaction context. The database operation statement included in the one or more database operation instructions is used to implement a transaction branch of the distributed transaction, and the distributed transaction context includes the identifier of the distributed transaction. The parsing module 0122 is also used to send the parsed database operation statement and the distributed transaction context to the transaction branch processing module 0124. The functional implementation of the parsing module 0122 can be referred to the relevant descriptions of steps 109 and 209 in the above method embodiments.

[0269] The transaction branch processing module 0124 is used to: execute the database operation statement in the business database; and send a transaction branch creation request to the transaction server, the transaction branch creation request including the identifier of the distributed transaction. The functional implementation of the transaction branch processing module 0124 can be referred to the relevant descriptions of steps 111 and 220 in the above method embodiments.

[0270] Optionally, the transaction branch processing module 0124 is further configured to: obtain lock information of a dataset, which is the target of the database operation statement included in the one or more database operation instructions, and the lock information of the dataset is used to identify the dataset in the business database; correspondingly, the transaction branch creation request also includes the lock information of the dataset.

[0271] Optionally, the transaction branch processing module 0124 can be used to: determine that the auto-commit function of the business database is enabled, and after receiving a first creation response from the transaction server indicating that the transaction branch has been successfully created, execute the database operation statements included in each database operation instruction in the business database. The functional implementation of the transaction branch processing module 0124 can also refer to the relevant description of step 115 in the above method embodiments.

[0272] The transaction branch processing module 0124 can also be used to: after receiving the first creation response sent by the transaction server indicating that the transaction branch has been successfully created, send a first commit instruction for the transaction branch to the business database.

[0273] Optionally, the transaction branch processing module 0124 can also be used to: after receiving a second creation response from the transaction server indicating that the creation of the transaction branch has failed, send a first rollback instruction for the transaction branch to the business database. The functional implementation of the transaction branch processing module 0124 can also refer to the relevant descriptions of steps 112 to 114 and step 117 in the above method embodiments.

[0274] Optionally, the transaction branch processing module 0124 can also be used to determine that the auto-commit function of the business database is in a disabled state, send the execution result of the database operation statement included in each database operation instruction to the business client; and after obtaining the second commit instruction for the transaction branch sent by the business client, obtain the lock information of the dataset.

[0275] If the number of database operation statements used to implement the transaction branch is greater than one, the automatic commit function of the business database is set to the off state by the business client; the second commit instruction is sent by the business client after determining, based on the execution result, that each database operation statement used to implement the transaction branch has been executed successfully. The functional implementation of the transaction branch processing module 0124 can also refer to the relevant descriptions of steps 210 to 213 and step 219 in the above method embodiments.

[0276] Optionally, the transaction branch processing module 0124 can also be used to, after sending the execution result of the database operation statement included in each database operation instruction to the business client, obtain the second rollback instruction sent by the business client for the transaction branch, delete the lock information of the dataset, and send the second rollback instruction to the business database; wherein, the second rollback instruction is sent by the business client after determining that any of the database operation statements used to implement the transaction branch has failed. Both the second commit instruction and the second rollback instruction can be sent to the transaction branch processing module 0124 through the connection management module 0121 and the parsing module 0122. The functional implementation of the transaction branch processing module 0124 can also refer to the relevant descriptions of steps 216 and 217 in the above method embodiments.

[0277] Optionally, the transaction branch processing module 0124 can be used to: obtain a first setting instruction sent by the business client, and record that the automatic commit function of the business database is enabled according to the first setting instruction; wherein, the first setting instruction is sent by the business client when it determines that the number of database operation statements used to implement the transaction branch is equal to 1.

[0278] Optionally, the transaction branch processing module 0124 can be used to: obtain a second setting instruction sent by the business client, and record that the auto-commit function of the business database is in a disabled state according to the second setting instruction; the second setting instruction is sent by the business client when it determines that the number of database operation statements used to implement the transaction branch is greater than 1. The functional implementation of the transaction branch processing module 0124 can also refer to the relevant descriptions of steps 105 and 205 in the above method embodiments.

[0279] Optionally, the first creation response carries an identifier assigned by the transaction server to the transaction branch; the transaction branch processing module 0124 can also be used for:

[0280] Upon receiving the first creation response, the system stores the identifier of the transaction branch and the corresponding dataset in the transaction log of the distributed transaction; it then receives the third commit instruction for the transaction branch from the transaction server, clearing the identifier of the transaction branch and the dataset recorded in the transaction log. Alternatively, it receives the third rollback instruction for the transaction branch from the transaction server, retrieves the dataset from the transaction log based on the identifier of the transaction branch, and rolls back the transaction branch based on the dataset.

[0281] Specifically, the third commit instruction is sent by the transaction server after receiving the commit instruction for the distributed transaction from the business client, and the third rollback instruction is sent by the transaction server after receiving the rollback instruction for the distributed transaction from the business client. The functionality of the transaction branch processing module 0124 can also be referenced to the relevant descriptions of steps 116 and 122 in the above method embodiments.

[0282] Optionally, the transaction branch processing module 0124 can also be used for:

[0283] After sending the first commit instruction for the transaction branch to the business database, the lock information of the dataset is deleted. If the transaction branch is determined to have been successfully committed, a commit result indicating successful commit is sent to the business client; if the transaction branch is determined to have failed, a commit result indicating failure is sent to the business client, a fourth rollback instruction for the transaction branch is sent to the business database, and a notification message carrying the identifier of the transaction branch is sent to the transaction server, which instructs the transaction server to delete the lock information of the transaction branch. The functionality of the transaction branch processing module 0124 can also be referred to the relevant description of step 118 in the above method embodiment.

[0284] Optionally, the connection management module 0121 can be used to: if it is detected that the recipient of a data packet sent by the service client is the service database, then send the data packet to the parsing module 0122; if it is detected that the recipient of a data packet sent by the service client is not the service database, then send the data packet to the pass-through module 0123. The functional implementation of the connection management module 0121 can be referred to the relevant descriptions of steps 301 to 306 in the above method embodiments.

[0285] The parsing module 0122 is used to parse the data packet. The functionality of the parsing module 0122 can be found in the description of step 307 in the above method embodiment.

[0286] The pass-through module 0123 is used to forward the data packet to the receiver, that is, to pass through the data packet. The function implementation of the pass-through module 0123 can be referred to the relevant description of step 308 in the above method embodiment.

[0287] In summary, this application provides a network proxy node that can create and process transaction branches based on the context of the distributed transaction carried in the database operation instructions and the database operation statements. Because the network proxy node can create and process transaction branches, business clients do not need to deploy interfaces for creating and processing transaction branches (e.g., try, confirm, and cancel interfaces), thereby effectively reducing the development cost for business clients applying to distributed transaction processing systems.

[0288] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of each module in the network proxy node described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0289] This application provides a business client that can be deployed on the business server of a distributed transaction processing system, for example, on... Figure 1 or Figure 2 The distributed transaction processing system shown is represented by business server 01. (Reference) Figure 1 and Figure 2 It can be seen that the distributed transaction processing system also includes a transaction server 02 and multiple business databases 03, and a network proxy node is also deployed in the business server 01. Figure 2 As shown, the service client may include: API module 0111, communication module 0112, database driver 0113, service call module 0114, and processing module 0115. The following description uses the first service client 011a in the first service server 01a, and the first service server 01a also includes a first network proxy node 012a, as an example.

[0290] The processing module 0115 is used to generate one or more database operation statements to implement the transaction branch to be executed by the first business client in the distributed transaction. The functional implementation of the processing module 0115 can be referred to the relevant descriptions of steps 103 and 203 in the above method embodiments.

[0291] The API module 0111 is used to generate one or more database operation instructions based on the one or more database operation statements and the context of the distributed transaction. Each database operation instruction includes at least one database operation statement and the context of the distributed transaction, which includes the identifier of the distributed transaction. The functionality of the API module 0111 can be found in the descriptions of steps 106 and 206 in the above method embodiments.

[0292] The database driver 0113 is used to send one or more database operation instructions to the first business database. These one or more database operation instructions are used by the first network agent node that receives the one or more database operation instructions to create and process the transaction branch. The functionality of the database driver 0113 can be referred to the relevant descriptions of steps 107 and 207 in the above method embodiments.

[0293] Optionally, the API module 0111 is also used to respond to a business request by sending a request to the transaction server to create the distributed transaction; and to receive the identifier of the distributed transaction sent by the transaction server. The functionality of the API module 0111 can also be referred to the relevant descriptions of steps 101, 102, 201, and 202 in the above method embodiments.

[0294] The service invocation module 0114 is used to send a service invocation request to the second business client participating in the distributed transaction. The service invocation request carries the identifier of the distributed transaction. The functionality of the service invocation module 0114 can be referred to the relevant descriptions of steps 108 and 208 in the above method embodiments.

[0295] Optionally, the processing module 0115 is also used to determine the transaction branch to be executed by the first business client in the distributed transaction based on the business request.

[0296] The processing module 0115 is also used to receive the commit result of the transaction branch sent by the first network proxy node, and to receive the service call response sent by the second business client in response to the service call request.

[0297] The processing module 0115 can also be used to instruct the API module 0111 to send a commit instruction or a rollback instruction for the distributed transaction to the transaction server based on the commit result and the service call response. The commit instruction for the distributed transaction instructs the commit of each transaction branch included in the distributed transaction, and the commit instruction for the distributed transaction instructs the rollback of each transaction branch included in the distributed transaction. The functionality of the processing module 0115 can also be found in the descriptions of steps 118 to 120 in the above method embodiments.

[0298] Optionally, the processing module 0115 can also be used to: receive a service call request sent by a second business client, the service call request carrying the context of the distributed transaction; and determine the transaction branch to be executed by the first business client in the distributed transaction based on the service call request.

[0299] Optionally, the processing module 0115 can also be used for:

[0300] The number of database operation statements used to implement the transaction branch is determined to be equal to 1. The database driver 0113 is instructed to send a first setting instruction to the first business database. The first setting instruction is used to indicate that the auto-commit function is set to the enabled state.

[0301] Alternatively, if the number of database operation statements used to implement the transaction branch is greater than 1, the database driver 0113 is instructed to send a second setting instruction to the first business database. This second setting instruction is used to indicate that the auto-commit function is set to the off state. The function implementation of the processing module 0115 can also refer to the relevant descriptions of steps 104 and 204 in the above method embodiments.

[0302] Optionally, the processing module 0115 can also be used for:

[0303] After instructing database driver 0113 to send a second setting instruction to the first business database to indicate that the auto-commit function is set to the off state, the system receives the execution result of the database operation statement included in each database operation instruction sent by the first network agent node.

[0304] Based on the execution result, it is determined that each database operation statement used to implement the transaction branch has been executed successfully, and the database driver 0113 is instructed to send a second commit instruction for the transaction branch to the first business database.

[0305] Alternatively, based on the execution result, if it is determined that any of the database operation statements used to implement the transaction branch has failed, the database driver 0113 is instructed to send a second rollback instruction for the transaction branch to the first business database. The functionality of the processing module 0115 can also be described with reference to steps 213 to 215 and the related description of step 218 in the above method embodiments.

[0306] It should be noted that all requests or instructions sent by the API module 0111 and the database driver 0113 in this business client are sent through the communication module 0112.

[0307] In summary, this application provides a business client that can carry a distributed transaction context in the database operation instructions sent to the business database. This allows network proxy nodes to create and process transaction branches based on the distributed transaction context and the database operation statements. Since transaction branches can be created and processed through network proxy nodes, the business client does not need to deploy interfaces for creating and processing transaction branches (e.g., try, confirm, and cancel interfaces), thus effectively reducing the development cost of applying the business client to a distributed transaction processing system.

[0308] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of each module in the business client described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0309] It should be understood that the network proxy node and service client provided in the embodiments of this application can also be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The distributed transaction processing method provided in the above method embodiments can also be implemented in software. When the distributed transaction processing method provided in the above method embodiments is implemented in software, each module in the network proxy node and service client can also be a software module.

[0310] The architecture of the distributed transaction processing system provided in the embodiments of this application will be described below, such as... Figure 6 As shown, the distributed transaction processing system can be a server cluster, which includes at least one server 1000, and the servers 1000 establish communication channels with each other through a communication network.

[0311] Each server 1000 includes a bus 1001, a processor 1002, a communication interface 1003, and a memory 1004. The processor 1002, the memory 1004, and the communication interface 1003 communicate with each other via the bus 1001.

[0312] The processor 1002 can be composed of one or more general-purpose processors, such as a central processing unit (CPU), or a combination of a CPU and hardware chips. The hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The PLDs can be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof.

[0313] Memory 1004 may include volatile memory, such as random access memory (RAM). Memory 1004 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). Memory 1004 may also include combinations of the above types.

[0314] The memory 1004 stores executable code. The processor 1002 can read the executable code in the memory 1004 to implement functions, and can also communicate with other servers through the communication interface 1003.

[0315] In this embodiment, the processor 1002 in each server 1000 can implement one or more of the following functions: the function of at least one business client 011, the function of at least one network proxy node 012, the function of a transaction server 02, and the function of at least one business database 03. That is, the processor 1002 in each server 1000 can implement the function of only one of the business client 011, network proxy node 012, transaction server 02, and business database 03, or it can implement the function of multiple nodes. Correspondingly, the memory 1004 stores modules for implementing the functions of the processor 1002.

[0316] In this embodiment of the application, the processors 1001 in the multiple servers 1000 can work in coordination to execute the distributed transaction processing method provided in this embodiment of the application.

[0317] Optional, such as Figure 7 As shown, the distributed transaction processing system may include multiple business servers 2000, one transaction server 3000, and multiple database servers 4000. Figure 7 The diagram only schematically shows two business servers 2000 and two database servers 4000.

[0318] Each business server 2000 includes a bus 2001, a processor 2002, a communication interface 2003, and a memory 2004. The processor 2002, memory 2004, and communication interface 2003 communicate via the bus 2001. The transaction server 3000 includes a bus 3001, a processor 3002, a communication interface 3003, and a memory 3004. The processor 3002, memory 3004, and communication interface 3003 communicate via the bus 3001. Each database server 4000 includes a bus 4001, a processor 4002, a communication interface 4003, and a memory 4004. The processor 4002, memory 4004, and communication interface 4003 communicate via the bus 4001. The types of processors 2002, 3002, and 4002 can be found in the description of processor 1002, and will not be repeated here. The types of memory 2004, memory 3004 and memory 4004 mentioned above can be found in the relevant description of memory 1004, and will not be repeated here.

[0319] In this embodiment of the application, the processor 2002 in each service server 2000 can implement the functions of a service client 011 and a network proxy node 012 by running a computer program in the memory 2004. Accordingly, as... Figure 7 As shown, the memory 2004 in each business server 2000 stores various modules of the business client 011 (e.g., API module 0111, communication module 0112, database driver 0113, and service call module 0114), as well as various modules of the network proxy node 012 (e.g., connection management module 0121, parsing module 0122, pass-through module 0123, transaction branch processing module 0124, and database driver 0125).

[0320] The processor 3002 in the transaction server 3000 can implement the functions of the transaction server 02 in the above embodiment by running the computer program in the memory 3004. The processor 4002 in each database server 4000 can implement the functions of the business database 03 in the above embodiment by running the computer program in the memory 4004.

[0321] In summary, this application provides a distributed transaction processing system. Each business server in this system includes a business client and a network proxy node, which can intercept data packets sent by the business client. The database operation instructions sent by the business client to the business database can carry the context of the distributed transaction, enabling the network proxy node to create and process transaction branches based on this context and the database operation statement. Since transaction branches can be created and processed through the network proxy node, there is no need for the business client to deploy an interface for creating and processing transaction branches, thereby effectively reducing the development cost of applying the business client to the distributed transaction processing system.

[0322] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps performed by the network proxy node as described in the above method embodiments.

[0323] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps performed by the service client as described in the above method embodiments.

[0324] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the steps executed by the network proxy node in the above method embodiments.

[0325] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the steps executed by the business client in the above method embodiments.

[0326] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive (SSD).

[0327] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for processing a distributed transaction, the method comprising: The application is applied to a distributed transaction processing system, the distributed transaction processing system comprising a plurality of business servers, a transaction server and a business database, each business server comprising a network proxy node and a business client, the network proxy nodes in the plurality of business servers forming a service mesh, the service mesh being configured to enable communication between the business clients in different business servers, communication between the business clients and the transaction server, and communication between the business clients and the business database; The method comprises: The network proxy node obtains one or more database operation instructions sent by the business client to the business database, each database operation instruction comprising a database operation statement and a context of the distributed transaction, the database operation statements included in the one or more database operation instructions being configured to implement a transaction branch of the distributed transaction, and the context of the distributed transaction comprising an identifier of the distributed transaction; The network proxy node executes the database operation statement included in each database operation instruction in the business database; The network proxy node sends a transaction branch creation request to the transaction server, the transaction branch creation request comprising the identifier of the distributed transaction.

2. The method of claim 1, wherein, The method further comprises: The network proxy node obtains lock information of a data set, the data set being targeted by the database operation statement included in the one or more database operation instructions, and the lock information of the data set being configured to identify the data set in the business database; The transaction branch creation request further comprises the lock information of the data set.

3. The method of claim 1, wherein, The network proxy node executes the database operation statement included in each database operation instruction in the business database, comprising: The network proxy node confirms that an auto-commit function of the business database is in an open state; The network proxy node executes the database operation statement included in each database operation instruction in the business database after receiving a first creation response sent by the transaction server and indicating that the transaction branch creation is successful; The method further comprises that the network proxy node sends a first commit instruction for the transaction branch to the business database in response to the first creation response.

4. The method of claim 1, wherein, The method further comprises: The network proxy node receives a second creation response sent by the transaction server and indicating that the transaction branch creation fails; The network proxy node sends a first rollback instruction for the transaction branch to the business database in response to the second creation response.

5. The method of claim 2, wherein, The method further comprises: The network proxy node confirms that the auto-commit function of the business database is in a closed state; The network proxy node sends an execution result of the database operation statement included in each database operation instruction to the business client; The network proxy node obtains lock information of a data set, comprising: The network proxy node obtains the lock information of the data set after obtaining a second commit instruction for the transaction branch sent by the business client; The second commit instruction is sent by the business client after determining that each database operation instruction includes a database operation statement that is successfully executed according to the execution result.

6. The method of claim 5, wherein, After the network proxy node sends the execution result of the database operation statement included in each database operation instruction to the business client, the method further includes: The network proxy node acquires the second rollback instruction sent by the business client for the transaction branch, and deletes the lock information of the data set; The network proxy node sends the second rollback instruction to the business database; The second rollback instruction is sent by the business client after determining that any database operation instruction includes a database operation statement that is unsuccessfully executed.

7. The method according to claim 3 or 5 or 6, characterized in that, The method further includes: The network proxy node acquires the first setting instruction sent by the business client; The network proxy node records the automatic commit function of the business database as an open state according to the first setting instruction; The first setting instruction is sent by the business client after determining that the number of database operation statements used to implement the transaction branch is equal to 1.

8. The method according to claim 3 or 5 or 6, characterized in that, The method further includes: The network proxy node acquires the second setting instruction sent by the business client; The network proxy node records the automatic commit function of the business database as a closed state according to the second setting instruction; The second setting instruction is sent by the business client after determining that the number of database operation statements used to implement the transaction branch is greater than 1.

9. The method of claim 3, wherein, The first creation response carries an identifier allocated by the transaction server for the transaction branch; the method further includes: After receiving the first creation response sent by the transaction server and used to indicate that the transaction branch is successfully created, the network proxy node stores the identifier of the transaction branch and the corresponding relationship of the data set in the transaction log of the distributed transaction, the data set being a data set to which the database operation statement included in the one or more database operation instructions is directed; The network proxy node receives the third commit instruction sent by the transaction server for the transaction branch, and cleans up the identifier of the transaction branch and the data set recorded in the transaction log; The third commit instruction is sent by the transaction server after receiving the commit instruction sent by the business client for the distributed transaction.

10. The method of claim 3, wherein, The first creation response carries an identifier allocated by the transaction server for the transaction branch; the method further includes: After receiving the first creation response sent by the transaction server and used to indicate that the transaction branch is successfully created, the network proxy node stores the identifier of the transaction branch and the corresponding relationship of the data set in the transaction log of the distributed transaction, the data set being a data set to which the database operation statement included in the one or more database operation instructions is directed; The network proxy node receives the third rollback instruction sent by the transaction server for the transaction branch, acquires the data set from the transaction log according to the identifier of the transaction branch, and rolls back the transaction branch according to the data set; The third rollback instruction is sent by the transaction server after receiving a rollback instruction for the distributed transaction sent by the business client.

11. A method of processing a distributed transaction, the method comprising: The distributed transaction processing system includes a plurality of business servers, a transaction server, and a business database. Each business server includes a network proxy node and a business client. The network proxy nodes in the plurality of business servers form a service mesh, which is used to implement communication between business clients in different business servers, communication between the business clients and the transaction server, and communication between the business clients and the business database. The method includes: The first business client generates one or more database operation statements for implementing a transaction branch to be executed by the first business client in the distributed transaction according to the transaction branch; The first business client generates one or more database operation instructions according to the one or more database operation statements. Each database operation instruction includes at least one database operation statement and a context of the distributed transaction, which includes an identifier of the distributed transaction. The first business client sends the one or more database operation instructions to the business database through a first network proxy node, wherein the first network proxy node and the first business client are deployed on the same business server.

12. The method of claim 11, wherein, The method further includes: The first business client sends a creation request for the distributed transaction to the transaction server in response to a business request; The first business client receives an identifier of the distributed transaction sent by the transaction server; The first business client sends a service invocation request to a second business client participating in the distributed transaction, and the service invocation request carries the identifier of the distributed transaction; The first business client determines a transaction branch to be executed by the first business client in the distributed transaction according to the business request.

13. The method of claim 12, wherein, The method further includes: The first business client receives a commit result of the transaction branch sent by the first network proxy node; The first business client receives a service invocation response sent by the second business client in response to the service invocation request; The first business client sends a commit instruction or a rollback instruction for the distributed transaction to the transaction server according to the commit result and the service invocation response; The commit instruction for the distributed transaction is used to instruct to commit each transaction branch included in the distributed transaction, and the rollback instruction for the distributed transaction is used to instruct to rollback each transaction branch included in the distributed transaction.

14. The method of claim 11, wherein, The method further includes: The first business client receives a service invocation request sent by a second business client, and the service invocation request carries a context of the distributed transaction; The first business client determines a transaction branch to be executed by the first business client in the distributed transaction according to the service invocation request.

15. The method according to any one of claims 11 to 14, characterized in that, The method further includes: The first business client determines that the number of the database operation statements is equal to 1, and sends a first setting instruction to the first business database, the first setting instruction indicating that the automatic commit function is set to an open state.

16. The method according to any one of claims 11 to 14, characterized in that, The method further comprises: The first business client determines that the number of the database operation statements is greater than 1, and sends a second setting instruction to the first business database, the second setting instruction indicating that the automatic commit function is set to a closed state.

17. The method of claim 16, wherein, The method further comprises: The first business client receives an execution result of the database operation statement included in each database operation instruction; The first business client determines that the database operation statement included in each database operation instruction is successfully executed according to the execution result, and sends a second commit instruction for the transaction branch to the first business database.

18. The method of claim 16, wherein, The method further comprises: The first business client receives an execution result of the database operation statement included in each database operation instruction; The first business client determines that the database operation statement included in any database operation instruction fails to execute according to the execution result, and sends a second rollback instruction for the transaction branch to the first business database.

19. A network proxy node, characterized by The method is applied to a distributed transaction processing system, the distributed transaction processing system comprising a plurality of business servers, a transaction server and a business database, each business server comprising a network proxy node and a business client, network proxy nodes in the plurality of business servers forming a service mesh, the service mesh being used to realize communication between business clients in different business servers, communication between the business client and the transaction server and communication between the business client and the business database; The network proxy node comprises: The parsing module is configured to obtain one or more database operation instructions sent by the business client to the business database, each database operation instruction comprising a database operation statement and a context of the distributed transaction, the database operation statements included in the one or more database operation instructions being used to implement a transaction branch of the distributed transaction, and the context of the distributed transaction comprising an identifier of the distributed transaction. The transaction branch processing module is configured to execute the database operation statement included in each database operation instruction in the business database, and send a transaction branch creation request to the transaction server, the transaction branch creation request comprising the identifier of the distributed transaction.

20. The network broker node of claim 19, wherein, The transaction branch processing module is further configured to: Obtain lock information of a data set, the data set being targeted by the database operation statements included in the one or more database operation instructions, and the lock information of the data set being used to identify the data set in the business database. The transaction branch creation request further comprises the lock information of the data set.

21. The network broker node of claim 19 or 20, wherein, The transaction branch processing module is configured to: Confirm that the automatic commit function of the business database is in an open state; After receiving a first creation response sent by the transaction server and indicating that the transaction branch creation is successful, execute the database operation statement included in each database operation instruction in the business database; The transaction branch processing module is further configured to, in response to the first creation response, send a first commit instruction for the transaction branch to the business database.

22. The network broker node of claim 19 or 20, wherein, The transaction branch processing module is further configured to: receive a second creation response sent by the transaction server and indicating that the transaction branch creation fails; in response to the second creation response, send a first rollback instruction for the transaction branch to the business database.

23. The network broker node of claim 20, wherein, The transaction branch processing module is further configured to: confirm that the auto-commit function of the business database is in a closed state; send an execution result of a database operation statement included in each database operation instruction to the business client; after obtaining a second commit instruction for the transaction branch sent by the business client, obtain lock information of the data set; The second commit instruction is sent by the business client after determining that each database operation statement included in each database operation instruction is successfully executed according to the execution result.

24. A service client, characterized by The distributed transaction processing system includes a plurality of business servers, a transaction server, and a business database. Each business server includes a network proxy node and a business client. The network proxy nodes in the plurality of business servers form a service mesh. The service mesh is used to implement communication between business clients in different business servers, communication between the business clients and the transaction server, and communication between the business clients and the business database. The business client includes: A processing module is configured to generate one or more database operation statements for implementing a transaction branch to be executed by the business client in the distributed transaction according to the transaction branch. An application program interface module is configured to generate one or more database operation instructions according to the one or more database operation statements. Each database operation instruction includes at least one database operation statement and a context of the distributed transaction. The context of the distributed transaction includes an identifier of the distributed transaction. A database driver is configured to send the one or more database operation instructions to the business database through a first network proxy node. The first network proxy node and the business client are deployed in the same business server.

25. The service client of claim 24, wherein, The application program interface module is further configured to: in response to a business request, send a creation request of the distributed transaction to the transaction server; receive an identifier of the distributed transaction sent by the transaction server. The business client further includes: A service calling module is configured to send a service calling request to a second business client participating in the distributed transaction. The service calling request carries the identifier of the distributed transaction. The processing module is further configured to determine the transaction branch to be executed by the business client in the distributed transaction according to the business request.

26. The service client of claim 25, wherein, The processing module is further configured to: receive a commit result of the transaction branch sent by the first network proxy node; receive a service calling response sent by the second business client in response to the service calling request; According to the commit result and the service call response, a commit instruction or a rollback instruction for the distributed transaction is sent to the transaction server; The commit instruction for the distributed transaction is used to instruct to commit each transaction branch included in the distributed transaction, and the rollback instruction for the distributed transaction is used to instruct to rollback each transaction branch included in the distributed transaction.

27. The service client of claim 24, wherein, The processing module is further configured to: receive a service call request sent by a second service client, the service call request carrying a context of the distributed transaction; determine a transaction branch to be executed by the service client in the distributed transaction according to the service call request.

28. A network proxy node, characterized by The network proxy node comprises a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor implements the processing method of the distributed transaction according to any one of claims 1 to 10 when executing the computer program.

29. A service client, characterized by The service client comprises a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor implements the processing method of the distributed transaction according to any one of claims 11 to 18 when executing the computer program.

30. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, and when the instructions run on the computer, the computer executes the processing method of the distributed transaction according to any one of claims 1 to 10.

31. A computer readable storage medium, characterized in that, The computer readable storage medium stores instructions, and when the instructions run on the computer, the computer executes the processing method of the distributed transaction according to any one of claims 11 to 18.

32. A distributed transaction processing system, characterized by The distributed transaction processing system comprises a plurality of service servers, a transaction server, and a plurality of service databases; Each of the service servers comprises the network proxy node according to any one of claims 19 to 23 and 28, and the service client according to any one of claims 24 to 27 and 29.

Images