Decentralization and non-intrusive method and system for distributed transactions based on TCC model

Abstract

The invention relates to the field of distributed transactions, and discloses a distributed transaction decentralization and non-intrusion method and system based on a TCC model, and the method comprises the steps: developing a distributed transaction framework, enabling the transaction framework to be embedded in a client system, enabling the transaction framework to provide a TccNode interface, providing a Try, Confirm and Cancel method, and carrying out the abstract processing of the method, and obtaining an AbstraactTccNode; the transaction framework is packaged and provided for the client for reference access, and the client modifies corresponding configuration of the transaction framework according to service requirements; inheriting the AbstraactTccNode to compile all transaction participation nodes, and rewriting the method according to the demand of each node; starting the client system, immediately initializing the transaction framework embedded in the client system, starting a transaction coordinator in the transaction framework, and loading the configuration content of the transaction framework; the transaction framework constructs a transaction execution chain according to the configuration content, and various operations of the transaction execution chain are coordinated and processed in sequence through the transaction coordinator.

Description

Technical Field

[0001] The present invention relates to the field of distributed transaction technology, and in particular to a decentralized, non-intrusive method and system for distributed transactions based on a TCC model. Background Art

[0002] In cross-border payment scenarios, it is usually necessary to interact with multiple systems, such as calling the account system to move accounts, calling the marketing system to redeem coupons, calling the exchange system to trade exchange rates, and so on. Interacting with so many systems will lead to data consistency issues, such as payment calls to accounts and marketing, which are successful, but calls to the exchange system fail, which will cause inconsistencies. At this time, the account balance in the account system has been deducted, the coupon redemption in the marketing system has been successful, but the exchange has not been traded in the exchange system. The correct answer should be that the account balance is deducted successfully, the coupon is redeemed successfully, and the exchange is traded successfully. If there is no correct means to ensure consistency between systems, once it occurs, it will have a very big impact.

[0003] In order to solve this inconsistency problem, there are some commonly used distributed transaction frameworks. Among them, since the distributed transaction coordinator is usually deployed independently in a centralized manner, once the transaction coordinator fails, all ongoing transactions will be interrupted, resulting in data inconsistency and even system unavailability. For example, Alibaba's open source Seata is based on the AT mode of relational databases that support local ACID transactions. Hmily's standard TCC-style distributed transaction framework, etc. However, these distributed transaction frameworks are not suitable for current business scenarios. First of all, Seata's AT mode requires global locks to be acquired every time a transaction is processed, which has low performance, and the framework is too heavy and has many problems. Hmily's TCC mode code intrusion is high, and it needs to invade each transaction participant, that is, each application in the payment link needs to be connected and transformed according to the requirements of the framework. At the same time, troubleshooting transaction problems is very complicated. Both the transaction initiator and the participant need to communicate with the transaction coordinator. The complex communication interaction logic greatly increases the difficulty of troubleshooting. What's more, the maintenance difficulty is also relatively high. The distributed transaction framework needs to be maintained and upgraded, and all transaction initiators and participants need to be adjusted together. Summary of the invention

[0004] The purpose of the present invention is to solve the shortcomings of the above-mentioned prior art. Based on the current situation, an embedded distributed transaction coordinator is developed, and a distributed transaction framework of the TCC mode without code intrusion is developed. The framework only requires the transaction initiator to access and transform the corresponding node to write the Try, Confirm, and Cancel methods. All business participants do not need to be aware of it. Due to the use of the TCC method, the performance is also very high. A decentralized, non-intrusive method and system for distributed transactions based on the TCC model is provided.

[0005] Among them, the decentralized and non-intrusive method of distributed transactions based on the TCC model includes the following steps:

[0006] S1: Develop a distributed transaction framework, which is embedded in the client system. The transaction framework provides a TccNode interface, which provides Try, Confirm, and Cancel methods. The transaction framework abstracts the Try, Confirm, and Cancel methods to obtain AbstractTccNode.

[0007] S2: Packaging the transaction framework and providing it to the client for reference access, and the client modifies the corresponding configuration of the transaction framework according to business requirements;

[0008] S3: Inherit the AbstractTccNode to write all transaction participating nodes, and rewrite the Try, Confirm, and Cancel methods according to the requirements of each node;

[0009] S4: starting the client system, the transaction framework embedded in the client system is immediately initialized and the transaction coordinator therein is started, and the configuration content of the transaction framework is loaded;

[0010] S5: The transaction framework constructs a transaction execution chain according to the configuration content, and coordinates and processes various operations of the transaction execution chain transactions in sequence through the transaction coordinator.

[0011] Further, in step S1, developing a distributed transaction framework further includes:

[0012] S11: Encapsulate the Try, Confirm, and Cancel methods through the AbstractTccNode, then convert the parameter types of the Try, Confirm, and Cancel methods, add transaction data to the database before and after the method is executed, and print the transaction execution log;

[0013] S12: creating an execution method for exposing a transaction to the outside, the client system calling the execution method for exposing the transaction to the outside to create the transaction execution chain and perform transaction processing;

[0014] S13: Create a transaction retry job processor to expose it to the client system, and the client system configures the corresponding execution scheduling time according to business requirements.

[0015] Furthermore, in step S2, the written transaction framework is packaged and provided to the client system for reference access, which specifically includes:

[0016] A Bootstrap starter is written in the core of the transaction framework, the written transaction framework is packaged into a jar, the client system introduces the corresponding version of the starter jar package, and when the client system is started, the transaction coordinator of the transaction framework is started using the extension points provided by Spring Boot.

[0017] Furthermore, in step S2, the client modifies the corresponding configuration of the transaction framework according to business requirements, further comprising:

[0018] The configuration items of the transaction framework include tcc, tcc.recovery and tcc.alarm, where:

[0019] The tcc configuration item is the application name, and the default configuration is spring.application.name;

[0020] The tcc.recovery configuration item is configured in the transaction coordinator and the transaction retry job processor, including task retry delay, maximum retry times, retry paging size, TRYING state branch transaction Cancel times, whether to execute the two-stage Confirm and Cancel serially, the delay time for releasing the transaction lock, and whether to reversely execute the two-stage Confirm and Cancel. The retry, rollback and commit properties of transaction execution are determined by configuring the tcc.recovery configuration item;

[0021] The tcc.alarm configuration item is configured in the transaction alarm thread scheduler, including the alarm platform and the alarm token, and the failed transactions are monitored by configuring the tcc.alarm configuration item.

[0022] Furthermore, in step S4, the client system is started, the transaction framework embedded in the client system is immediately initialized and the transaction coordinator therein is started, and the configuration content of the transaction framework is loaded, which further includes:

[0023] S41: Starting the client system, the transaction framework senses that the client project is being started through the extension point provided by Spring Boot, and then immediately initializes and starts the transaction coordinator;

[0024] S42: Load the configuration of the transaction coordinator. If the client has configured, obtain the content of the client configuration to load the configuration; if the client has not configured, use the default value;

[0025] S43: Start the transaction retry job processor to periodically retry transactions that fail to execute the second phase Confirm and Cancel of the transaction, and at the same time, start the transaction alarm thread scheduler to detect transactions that fail to execute and have not been processed for a long time;

[0026] S44: Register the transaction participating node in the transaction factory for the transaction coordinator to obtain and execute.

[0027] Furthermore, in step S5, the operations of sequentially coordinating and processing the transaction execution chain transactions by the transaction coordinator further include:

[0028] The main transaction enters the Try phase, updates the main transaction status to TRYING, executes each node branch transaction in the transaction execution chain, captures exceptions for the transaction execution chain, updates the main transaction status to TRY_FAILED if an exception occurs, and calls Cancel of the entire transaction execution chain to roll back. If successful, updates the main transaction status to TRY_SUCCESS, that is, the main transaction is executed successfully, and calls Confirm of the entire transaction execution chain to commit.

[0029] Furthermore, after the main transaction enters the Try phase, each node branch transaction in the transaction execution chain is executed, and the exception capture of the transaction execution chain specifically includes:

[0030] S51: Execute the Try method of each node in the transaction execution chain. Before execution, the node creates a transaction participant record and stores it in the database. The branch transaction enters the Try phase and the status is updated to TRING. If the execution is successful, the branch transaction status is updated to TRY_SUCCESS, that is, the branch transaction is successfully executed. If an exception is thrown, it is regarded as the current transaction node execution failure, and enters the rollback process;

[0031] S52: If the current transaction node is executed successfully, the execution enters the Confirm process and executes the Confirm method of the transaction node. If the execution is successful, the branch transaction status is changed from TRY_SUCCESS to CONFIRM_SUCCESS, that is, the branch transaction is submitted successfully;

[0032] S53: If the current transaction node fails to execute, the execution enters the Cancel process and executes the Cancel method of the transaction node. If the execution succeeds, the branch transaction status is changed from TRY_SUCCESS or TRYING to CANCEL_SUCCESS, that is, the branch transaction is rolled back successfully.

[0033] Preferably, in step S52 and step S53, after the branch transaction node is successfully committed or rolled back, the branch transaction data is cleaned up; if the branch transaction node fails to commit or roll back, the next compensation is waited for.

[0034] On the other hand, the decentralized, non-intrusive system based on TCC model distributed transactions includes:

[0035] A transaction framework development module is used to develop a distributed transaction framework. The transaction framework is embedded in the client system. The transaction framework provides a TccNode interface. The TccNode interface provides Try, Confirm, and Cancel methods. The transaction framework abstracts the Try, Confirm, and Cancel methods to obtain AbstractTccNode.

[0036] A transaction framework access module, used to package the transaction framework and provide it to the client for reference access, and the client modifies the corresponding configuration of the transaction framework according to business requirements;

[0037] The transaction participating node writing module is used to inherit the AbstractTccNode to write all transaction participating nodes and rewrite the Try, Confirm, and Cancel methods according to the requirements of each node;

[0038] A client startup module, used to start the client system, initialize the transaction framework embedded in the client system immediately and start the transaction coordinator therein, and load the configuration content of the transaction framework;

[0039] The transaction execution module is used to provide the transaction framework to build a transaction execution chain according to the configuration content, and coordinate and process various operations of the transaction execution chain in sequence through the transaction coordinator.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] (1) The present invention is based on a lightweight and usable design. The transaction framework adopts an embedded mode, in which the transaction coordinator will start and run together with the client (i.e., the transaction initiator) to achieve high availability of the transaction coordinator. In addition, the transaction participants do not need to introduce the transaction framework and corresponding transformation to access the transaction. Therefore, when the transaction framework needs to be upgraded, only the transaction initiator needs to be upgraded;

[0042] (2) The present invention uses the TCC transaction model to provide standard Try, Confirm, and Cancel methods, eliminating the impact of distributed transactions on the transaction systems of each participant. The transaction participants do not need to be aware of the transformation. The transaction initiator only needs to rewrite these methods for each participant node according to the business logic of the transaction. The performance is also guaranteed in the long payment link, avoiding the performance degradation caused by the use of the transaction framework.

[0043] (3) The present invention generates a unique transaction ID for the main transaction and each branch transaction in the transaction coordinator, and prints a rich log for the flow of each transaction, thereby reducing the difficulty of troubleshooting. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings are used to provide further understanding of the present invention and constitute a part of the specification. They are used to explain the present invention together with the embodiments of the present invention and do not constitute a limitation of the present invention.

[0045] In the attached picture:

[0046] Figure 1 This is a flow chart of a decentralized, non-intrusive method for distributed transactions based on the TCC model of the present invention;

[0047] Figure 2 This is a schematic diagram of the principle of a transaction coordinator of the present invention;

[0048] Figure 3 This is a business logic diagram of an account calling, marketing, and currency exchange system of the present invention;

[0049] Figure 4 A schematic diagram of a transaction execution process of the present invention;

[0050] Figure 5 A flowchart of a transaction coordinator for implementing a cash withdrawal transaction service of the present invention;

[0051] Figure 6 A business logic diagram of a cash withdrawal transaction according to the present invention; DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0053] Those skilled in the art will appreciate that, unless otherwise stated, the singular forms "a", "an", "said" and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0054] In the cross-border payment scenario, the business logic of the customer's cash withdrawal transaction, the transaction system will need to operate the order amount, exchange currency, and move the account. At this time, a distributed transaction framework is needed to ensure the consistency of these operations. Commonly used distributed transaction frameworks, such as Alibaba's open source Seata, are based on the relational database AT mode that supports local ACID transactions; Hmily's standard TCC-style distributed transaction framework, etc. However, these distributed transaction frameworks are not suitable for current business scenarios. First of all, Seata's AT mode requires obtaining a global lock every time a transaction is processed, and the performance is not high. The framework is too heavy and has many problems. Hmily's TCC mode has a high code intrusion and needs to invade each transaction participant, that is, each application in the payment link needs to be connected and transformed according to the framework requirements.

[0055] Based on the current situation, the present invention has developed an embedded distributed transaction coordinator and a distributed transaction framework of the TCC mode without code intrusion. The framework only requires the transaction initiator to access and transform the corresponding node to write the Try, Confirm, and Cancel methods. All business participants do not need to be aware of it. Due to the use of the TCC method, the performance is also very high.

[0056] The specific implementation of the present invention is described below with reference to the accompanying drawings and embodiments.

[0057] Example 1

[0058] like Figure 1 As shown, this embodiment provides a decentralized, non-intrusive method for distributed transactions based on the TCC model, including the following steps:

[0059] S1: Develop a distributed transaction framework, which is embedded in the client system. The transaction framework provides a TccNode interface, which provides Try, Confirm, and Cancel methods. The transaction framework abstracts the Try, Confirm, and Cancel methods to obtain AbstractTccNode.

[0060] S2: Packaging the transaction framework and providing it to the client for reference access, and the client modifies the corresponding configuration of the transaction framework according to business requirements;

[0061] S3: Inherit the AbstractTccNode to write all transaction participating nodes, and rewrite the Try, Confirm, and Cancel methods according to the requirements of each node;

[0062] S4: starting the client system, the transaction framework embedded in the client system is immediately initialized and the transaction coordinator therein is started, and the configuration content of the transaction framework is loaded;

[0063] S5: The transaction framework constructs a transaction execution chain according to the configuration content, and coordinates and processes various operations of the transaction execution chain transactions in sequence through the transaction coordinator.

[0064] Wherein, in step S1, developing a distributed transaction framework further includes:

[0065] S11: Encapsulate the Try, Confirm, and Cancel methods through the AbstractTccNode, then convert the parameter types of the Try, Confirm, and Cancel methods, add transaction data to the database before and after the method is executed, and print the transaction execution log;

[0066] S12: creating an execution method for exposing a transaction to the outside, the client system calling the execution method for exposing the transaction to the outside to create the transaction execution chain and perform transaction processing;

[0067] S13: Create a transaction retry job processor to expose it to the client system. The client system configures the corresponding execution scheduling time according to business requirements, such as once every 30 seconds, once every 1 minute, etc.

[0068] Among them, the AbstractTccNode encapsulates Try, Confirm, and Cancel. When these methods need to be called, the encapsulated proxy method will be entered first. The proxy method will store the transaction data, and uniformly capture the exceptions of the transaction execution, and print the detailed log of the transaction execution. The output transaction execution log will have a detailed log corresponding to each transaction, and there will be detailed log descriptions for successful and failed execution.

[0069] In the transaction framework, the transaction coordinator is a coordination processor for each transaction operation, builds a transaction execution chain, and drives transaction submission, rollback, and retry. The principle of the transaction coordinator is as follows: Figure 2 shown.

[0070] In step S2, the written transaction framework is packaged and provided to the client system for reference access, which specifically includes:

[0071] A Bootstrap starter is written in the core of the transaction framework, the written transaction framework is packaged into a jar, the client system introduces the corresponding version of the starter jar package, and when the client system is started, the transaction coordinator of the transaction framework is started using the extension points provided by Spring Boot.

[0072] Specifically, in this embodiment, we write a package (xxx-spring-boot-starter) that the distributed transaction framework supports for Spring Boot, relies on modules such as the framework core, provides database annotations, and performs aspect processing on the annotations to initialize the database connection.

[0073] Then, write the Bootstrap starter in the framework core to provide framework configuration initialization and transaction recovery bypass. When the client starts, use the extension points provided by Spring Boot to start the framework transaction coordinator.

[0074] At the same time, we introduce the corresponding version of the starter jar package to the client system. When the client system starts, because it relies on the framework starter jar package, before the application starts the Spring Bean initialization, the transaction framework coordinator will also start, load the framework configuration, start the transaction compensation bypass, initialize the transaction database connection, etc. When the transaction initiator system is started, the transaction coordinator embedded in the system is also initialized and started, and the transaction can be processed when the request comes in.

[0075] The transaction framework of this embodiment uses an embedded, decentralized design. When accessing the transaction framework, the transaction initiator only needs to perform access modification. When the transaction framework needs to be upgraded, the transaction initiator only needs to update the latest jar package and then perform corresponding modifications.

[0076] Furthermore, in step S2, the client modifies the corresponding configuration of the transaction framework according to business requirements, further comprising:

[0077] The configuration items of the transaction framework include tcc, tcc.recovery and tcc.alarm, where:

[0078] The tcc configuration item is the application name, and the default configuration is spring.application.name;

[0079] The tcc.recovery configuration item is configured in the transaction coordinator and the transaction retry job processor, including task retry delay, maximum retry times, retry paging size, TRYING state branch transaction Cancel times, whether to execute the two-stage Confirm and Cancel serially, the delay time for releasing the transaction lock, and whether to reversely execute the two-stage Confirm and Cancel. The retry, rollback and commit properties of transaction execution are determined by configuring the tcc.recovery configuration item;

[0080] Configure the tcc.alarm configuration item in the transaction alarm thread scheduler, including the alarm platform and alarm token, and monitor the failed transactions by configuring the tcc.alarm configuration item. The specific configuration items are as follows:

[0081] tcc:

[0083]

[0084] #tcc.recovery:

[0085]

[0086] #tcc.alarm:

[0087] name type Required default value illustrate platform String no DING Alarm platform, currently only supports DingTalk access-token String yes none DingTalk alarm token

[0088] Furthermore, in step S3, all transaction participating nodes are written by inheriting the AbstractTccNode, and the Try, Confirm, and Cancel methods are rewritten according to the requirements of each node. Figure 3 As shown, assuming that payment needs to process marketing, currency exchange, and accounts, there will be 3 transaction nodes: Marketing node: Try: lock coupons, Confirm: use coupons, Cancel: release coupons; currency exchange node: Try: currency exchange order, Confirm: empty processing, Cancel: reverse closing; Account node: Try: fund freezing, Confirm: fund unbinding, Cancel: fund unfreezing.

[0089] Among them, it will be written based on the cross-border payment link, and the payment system will call the account, marketing, and foreign exchange systems.

[0090] 1. Write a payment transaction node, Try method: save the payment document, and the payment status is pending; Confirm method: update the payment document status to success; Cancel method: update the payment document status to failure.

[0091] 2. Write an account transaction node, the Try method: freeze the corresponding amount of payment; the Confirm method: unfreeze and spend the corresponding amount; the Cancel method: unfreeze the corresponding amount.

[0092] 3. Write a marketing transaction node, the Try method: lock the coupon used for this payment; the Confirm method: cancel the corresponding coupon; the Cancel method: release the corresponding coupon.

[0093] 4. Write a currency exchange transaction node, Try method: specify the exchange rate to exchange currency; Confirm method: no operation; Cancel method: perform reverse exchange and close the position.

[0094] Furthermore, in step S4, the client system is started, the transaction framework embedded in the client system is immediately initialized and the transaction coordinator therein is started, and the configuration content of the transaction framework is loaded, which further includes:

[0095] S41: Starting the client system, the transaction framework senses that the client project is being started through the extension point provided by Spring Boot, and then immediately initializes and starts the transaction coordinator;

[0096] S42: Load the configuration of the transaction coordinator. If the client has configured, obtain the content of the client configuration to load the configuration; if the client has not configured, use the default value;

[0097] S43: Start the transaction retry job processor to periodically retry transactions that fail to execute the second phase Confirm and Cancel of the transaction, and at the same time, start the transaction alarm thread scheduler to detect transactions that fail to execute and have not been processed for a long time;

[0098] S44: Register the transaction participating node in the transaction factory for the transaction coordinator to obtain and execute.

[0099] When using transactions for processing, you can directly specify the transaction nodes that need to participate in the processing. The entire process does not require any modifications to the transaction participants, and all modifications are implemented in the transaction initiator system.

[0100] like Figure 4 As shown, in step S5, the operations of processing the transaction execution chain transaction in sequence by the transaction coordinator include:

[0101] After the client system is started, it will receive a payment request. Since the transaction framework is used, the transaction will be executed through the transaction executor to arrange the nodes and node order that need to participate in the transaction.

[0102] Then, the transaction framework will build a transaction execution chain based on the transaction nodes required by the client, and after successful construction, it will be passed to the transaction coordinator for execution.

[0103] After that, the main transaction enters the Try phase, updates the main transaction status to TRYING, executes each node branch transaction in the transaction execution chain, captures exceptions for the transaction execution chain, updates the main transaction status to TRY_FAILED if an exception occurs, and calls Cancel of the entire transaction execution chain to roll back. If successful, updates the main transaction status to TRY_SUCCESS, that is, the main transaction is executed successfully, and calls Confirm of the entire transaction execution chain to commit.

[0104] After the main transaction enters the Try phase, each node branch transaction in the transaction execution chain is executed, and the exception capture of the transaction execution chain specifically includes:

[0105] S51: First, the Try method of each node in the transaction execution chain is executed. Before execution, the node creates a transaction participant record and stores it in the database. The branch transaction enters the Try phase and the status is updated to TRING. If the execution is successful, the branch transaction status is updated to TRY_SUCCESS, that is, the branch transaction is successfully executed. If an exception is thrown, it is regarded as the current transaction node execution failure, and the rollback process is entered;

[0106] S52: If the current transaction node is executed successfully, the execution enters the Confirm process and executes the Confirm method of the transaction node. If the execution is successful, the branch transaction status is changed from TRY_SUCCESS to CONFIRM_SUCCESS, that is, the branch transaction is submitted successfully;

[0107] S53: If the current transaction node fails to execute, the execution enters the Cancel process and executes the Cancel method of the transaction node. If the execution succeeds, the branch transaction status is changed from TRY_SUCCESS or TRYING to CANCEL_SUCCESS, that is, the branch transaction is rolled back successfully.

[0108] Among them, Figure 4 As shown, in step S52 and step S53, after the branch transaction node is successfully committed or rolled back, the branch transaction data is cleaned up; if the branch transaction node fails to commit or roll back, the next compensation is waited for.

[0109] The present invention solves the problem of complex distributed transactions in cross-border payments, eliminates the impact of distributed transactions on the transaction systems of each participant, does not require transaction participants to perceive and transform, and ensures performance in long payment links, without significantly reducing performance due to the use of a transaction framework.

[0110] Example 2

[0111] The business logic of the customer's cash withdrawal transaction is as follows: Figure 6 As shown, the trading system executes operations of the order system, exchange rate system and account system respectively. The trading system needs to operate order quotas, exchange currencies and move accounts. At this time, it is necessary to ensure the consistency of these operations. The business implementation transaction coordinator process of this embodiment is as follows Figure 5 shown.

[0112] Among them, the order system: provides the functions of deduction and recharge of order amount; the currency exchange system: provides the function of currency exchange; the account system: operates customer accounts to provide account movement support.

[0113] Example 3

[0114] The self-developed TCC framework of this embodiment may have idempotence, empty rollback, and suspension problems during use. The suspension problem is more complicated. Since the coordinator is embedded and cannot correctly perceive whether each transaction participant is actually executed, the suspension problem will be more difficult to handle.

[0115] Suspension means that the Cancel operation in the second phase is executed before the Try operation in the first phase. This is very similar to an empty rollback, except that the Try operation of the transaction will eventually succeed. For example, when executing the Try operation, the network of other system services times out or packets are lost, resulting in a Try failure and a rollback. At this time, the service that may be called to roll back is still blocked, triggering an empty rollback. If this ends the entire transaction, the transaction may eventually succeed in the Try operation but not be rolled back.

[0116] Since the TCC framework of this embodiment cannot control Try from being executed, it can only compensate for Cancel several times, so that even if the final transaction Try is successfully executed, it can be rolled back. This embodiment is guaranteed by the following configuration:

[0117] max-trying-cancel-count:3

[0118] #TYRING state branch transaction Cancel times, if the specified times succeed, it is completed by default.

[0119] Example 4

[0120] This embodiment provides a decentralized, non-intrusive system based on TCC model distributed transactions, including:

[0121] A transaction framework development module is used to develop a distributed transaction framework. The transaction framework is embedded in the client system. The transaction framework provides a TccNode interface. The TccNode interface provides Try, Confirm, and Cancel methods. The transaction framework abstracts the Try, Confirm, and Cancel methods to obtain AbstractTccNode.

[0122] A transaction framework access module, used to package the transaction framework and provide it to the client for reference access, and the client modifies the corresponding configuration of the transaction framework according to business requirements;

[0123] The transaction participating node writing module is used to inherit the AbstractTccNode to write all transaction participating nodes and rewrite the Try, Confirm, and Cancel methods according to the requirements of each node;

[0124] A client startup module, used to start the client system, initialize the transaction framework embedded in the client system immediately and start the transaction coordinator therein, and load the configuration content of the transaction framework;

[0125] The transaction execution module is used to provide the transaction framework to build a transaction execution chain according to the configuration content, and coordinate and process various operations of the transaction execution chain in sequence through the transaction coordinator.

[0126] Obviously, those skilled in the art can make various changes and modifications to the invention without departing from the spirit and scope of the invention. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

[0127] Finally, it should be noted that the above are only preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A decentralized, non-intrusive method for distributed transactions based on the TCC model, characterized by: The steps include: S1: Develop a distributed transaction framework, which is embedded in the client system. The transaction framework provides a TccNode interface, which provides Try, Confirm, and Cancel methods. The transaction framework abstracts the Try, Confirm, and Cancel methods to obtain AbstractTccNode. S2: Packaging the transaction framework and providing it to the client for reference access, and the client modifies the corresponding configuration of the transaction framework according to business requirements; S3: Inherit the AbstractTccNode to write all transaction participating nodes, and rewrite the Try, Confirm, and Cancel methods according to the requirements of each node; S4: starting the client system, the transaction framework embedded in the client system is immediately initialized and the transaction coordinator therein is started, and the configuration content of the transaction framework is loaded; S5: The transaction framework constructs a transaction execution chain according to the configuration content, and coordinates and processes various operations of the transaction execution chain transactions in sequence through the transaction coordinator.

2. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 1, characterized in that: In step S1, developing a distributed transaction framework further includes: S11: Encapsulate the Try, Confirm, and Cancel methods through the AbstractTccNode, then convert the parameter types of the Try, Confirm, and Cancel methods, add transaction data to the database before and after the method is executed, and print the transaction execution log; S12: creating an execution method for exposing a transaction to the outside, the client system calling the execution method for exposing the transaction to the outside to create the transaction execution chain and perform transaction processing; S13: Create a transaction retry job processor to expose it to the client system, and the client system configures the corresponding execution scheduling time according to business requirements.

3. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 1, characterized in that: In step S2, the written transaction framework is packaged and provided to the client system for reference access, which specifically includes: A Bootstrap starter is written in the core of the transaction framework, the written transaction framework is packaged into a jar, the client system introduces the corresponding version of the starter jar package, and when the client system is started, the transaction coordinator of the transaction framework is started using the extension points provided by SpringBoot.

4. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 2, characterized in that: In step S2, the client further modifies the corresponding configuration of the transaction framework according to business requirements: The configuration items of the transaction framework include tcc, tcc.recovery and tcc.alarm, where: The tcc configuration item is the application name, and the default configuration is spring.application.name; The tcc.recovery configuration item is configured in the transaction coordinator and the transaction retry job processor, including task retry delay, maximum retry times, retry paging size, TRYING state branch transaction Cancel times, whether to execute the two-stage Confirm and Cancel serially, the delay time for releasing the transaction lock, and whether to reversely execute the two-stage Confirm and Cancel. The retry, rollback and commit properties of transaction execution are determined by configuring the tcc.recovery configuration item; The tcc.alarm configuration item is configured in the transaction alarm thread scheduler, including the alarm platform and the alarm token, and the failed transactions are monitored by configuring the tcc.alarm configuration item.

5. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 3 or 4, characterized in that: In step S4, the client system is started, the transaction framework embedded in the client system is immediately initialized and the transaction coordinator therein is started, and the configuration content of the transaction framework is loaded, further comprising: S41: Starting the client system, the transaction framework senses that the client project is being started through the extension point provided by Spring Boot, and then immediately initializes and starts the transaction coordinator; S42: Load the configuration of the transaction coordinator. If the client has configured, obtain the content of the client configuration to load the configuration; if the client has not configured, use the default value; S43: Start the transaction retry job processor to periodically retry transactions that fail to execute the second phase Confirm and Cancel of the transaction, and at the same time, start the transaction alarm thread scheduler to detect transactions that fail to execute and have not been processed for a long time; S44: Register the transaction participating node in the transaction factory for the transaction coordinator to obtain and execute.

6. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 1, characterized in that: In step S5, the operations of sequentially coordinating and processing the transaction execution chain transactions by the transaction coordinator further include: The main transaction enters the Try phase, updates the main transaction status to TRYING, executes each node branch transaction in the transaction execution chain, captures exceptions for the transaction execution chain, updates the main transaction status to TRY_FAILED if an exception occurs, and calls Cancel of the entire transaction execution chain to roll back. If successful, updates the main transaction status to TRY_SUCCESS, that is, the main transaction is executed successfully, and calls Confirm of the entire transaction execution chain to commit.

7. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 6, characterized in that: After the main transaction enters the Try phase, each node branch transaction in the transaction execution chain is executed, and the exception capture of the transaction execution chain specifically includes: S51: Execute the Try method of each node in the transaction execution chain. Before execution, the node creates a transaction participant record and stores it in the database. The branch transaction enters the Try phase and the status is updated to TRING. If the execution is successful, the branch transaction status is updated to TRY_SUCCESS, that is, the branch transaction is successfully executed. If an exception is thrown, it is regarded as the current transaction node execution failure, and enters the rollback process; S52: If the current transaction node is executed successfully, the execution enters the Confirm process and executes the Confirm method of the transaction node. If the execution is successful, the branch transaction status is changed from TRY_SUCCESS to CONFIRM_SUCCESS, that is, the branch transaction is submitted successfully; S53: If the current transaction node fails to execute, the execution enters the Cancel process and executes the Cancel method of the transaction node. If the execution succeeds, the branch transaction status is changed from TRY_SUCCESS or TRYING to CANCEL_SUCCESS, that is, the branch transaction is rolled back successfully.

8. The decentralized, non-intrusive method for distributed transactions based on the TCC model according to claim 7, characterized in that: In step S52 and step S53, after the branch transaction node is successfully committed or rolled back, the branch transaction data is cleaned up; if the branch transaction node fails to commit or roll back, the next compensation is waited for.

9. A decentralized, non-intrusive system based on TCC model distributed transactions, characterized by: include: A transaction framework development module is used to develop a distributed transaction framework. The transaction framework is embedded in the client system. The transaction framework provides a TccNode interface. The TccNode interface provides Try, Confirm, and Cancel methods. The transaction framework abstracts the Try, Confirm, and Cancel methods to obtain AbstractTccNode. A transaction framework access module, used to package the transaction framework and provide it to the client for reference access, and the client modifies the corresponding configuration of the transaction framework according to business requirements; The transaction participating node writing module is used to inherit the AbstractTccNode to write all transaction participating nodes and rewrite the Try, Confirm, and Cancel methods according to the requirements of each node; A client startup module, used to start the client system, initialize the transaction framework embedded in the client system immediately and start the transaction coordinator therein, and load the configuration content of the transaction framework; The transaction execution module is used to provide the transaction framework to build a transaction execution chain according to the configuration content, and coordinate and process various operations of the transaction execution chain in sequence through the transaction coordinator.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, a decentralized, non-intrusive method for distributed transactions based on a TCC model as described in any one of claims 1 to 8 is implemented.

11. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement a decentralized, non-intrusive method for distributed transactions based on a TCC model as described in any one of claims 1-8.

Images