Distributed transaction processing method and apparatus, electronic device, and storage medium

Abstract

The application relates to the technical field of artificial intelligence, and provides a distributed transaction processing method and device, electronic equipment and a storage medium. The method comprises the following steps: analyzing a resource package of each account of each branch transaction to obtain an analysis result; merging a plurality of analysis results of a plurality of accounts of each branch transaction to obtain a transaction type of the corresponding branch transaction; classifying and sorting a plurality of transaction types of a plurality of branch transactions to obtain a target sorting result; submitting each branch transaction from the head of the target sorting result to obtain a decision result of the corresponding branch transaction; and processing each transaction according to the decision result of each branch transaction. According to the application, after the submission of the branch transaction fails, the branch transaction is resubmitted or rolled back according to the decision result of each branch transaction, so that the processing efficiency of the branch transaction is improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, specifically to a distributed transaction processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the financial sector, data in payment account systems is committed using distributed transactions. Existing distributed transaction processing solutions include the TCC (Try-Confirm-Cancel) model and two-phase commit.

[0003] However, when the TCC mode handles distributed transactions, both the master and slave business services need to be modified, resulting in high development costs. When the two-phase commit mode handles distributed transactions, if the transaction coordinator crashes, all executors may need to wait for the coordinator, which can cause blocking and lead to low efficiency in distributed transaction processing.

[0004] Therefore, it is necessary to propose a method that can quickly handle distributed transactions. Summary of the Invention

[0005] In view of the above, it is necessary to propose a distributed transaction processing method, device, electronic device and storage medium, which, based on the decision result of each branch transaction, resubmits or rolls back the branch transaction after the submission of the branch transaction fails, thereby improving the processing efficiency of branch transactions.

[0006] A first aspect of this application provides a distributed transaction processing method, the method comprising:

[0007] In response to a received distributed transaction processing request, business data for each transaction is obtained, wherein the business data includes resource packages of at least one account of at least one branch transaction;

[0008] Analyze the resource packages of each account in each branch transaction to obtain the analysis results for each account;

[0009] The analysis results of multiple accounts for each branch transaction are merged, and the transaction type of the corresponding branch transaction is obtained based on the merged result.

[0010] Classify and sort multiple transaction types across multiple branches to obtain the target sorting result;

[0011] Starting from the head of the target sorting result, submit each branch transaction to obtain the decision result of the corresponding branch transaction;

[0012] Each transaction is processed based on the decision result of each branch transaction.

[0013] Optionally, processing each transaction based on the decision result of each branch transaction includes one or more of the following operations:

[0014] If the decision result of any branch transaction is a commit failure, obtain the transaction type of that branch transaction;

[0015] If the transaction type of any of the branch transactions is a preset first type, the corresponding branch transaction is rolled back;

[0016] If the transaction type of any branch transaction is a preset second type, roll back the branch transaction of the preset first type corresponding to any branch transaction;

[0017] If any branch transaction has a preset third type of transaction, determine whether there is a preset second type of branch transaction in the sorting result. If there is a preset second type of branch transaction in the sorting result, resubmit the corresponding branch transaction; if there is no preset second type of branch transaction in the sorting result, resubmit or roll back the corresponding transaction.

[0018] If any branch transaction is of the preset fourth type, all accounts in the corresponding branch transaction are frozen.

[0019] Optionally, after freezing all accounts in the corresponding branch transaction, the method further includes:

[0020] Identify the reasons why a branch transaction failed to commit;

[0021] Retrieve the frozen recharge amount of the target account from the commit failure reasons of each branch transaction;

[0022] From the available balance of the target account, the recharge amount is transferred to the frozen balance of the frozen target account through a preset interface, and the branch transaction corresponding to the frozen account is resubmitted.

[0023] Optionally, the analysis of the resource package for each account in each branch transaction to obtain the analysis results for each account includes:

[0024] Unzip the account package for each account to obtain the corresponding account operation types and account change details;

[0025] Based on the account operation type and the account change details, obtain the indicator results for each first preset indicator for each account;

[0026] The results of multiple indicators of multiple first preset indicators for each account are determined as the analysis results for each account.

[0027] Optionally, merging multiple analysis results for multiple accounts in each branch transaction and obtaining the transaction type of the corresponding branch transaction based on the merged result includes:

[0028] Based on the data source from which the account was obtained, multiple accounts in the same branch transaction are categorized.

[0029] The indicator results of multiple first preset indicators from the same data source are merged to obtain the indicator results of each second preset indicator of the corresponding branch transaction.

[0030] Based on the results of multiple second preset indicators, obtain the transaction type of each sub-branch transaction of the corresponding branch transaction;

[0031] The transaction types of multiple sub-branch transactions of the same branch transaction are used as the transaction types of the corresponding branch transaction.

[0032] Optionally, the step of classifying and sorting multiple transaction types of multiple branch transactions to obtain the target sorting result includes:

[0033] The multiple branch transactions are classified according to transaction type, wherein the transaction type includes a preset first type, a preset second type, a preset third type, and a preset fourth type;

[0034] Sort multiple branch transactions of the same transaction type according to a preset first sorting rule to obtain the sorting result of the corresponding transaction type;

[0035] Count the number of branch transactions in the predefined second type of sorting results for the same transaction type;

[0036] If the quantity is not 1, one branch transaction of the preset second type is retained in the sorting, and the transaction type of the remaining branch transactions of the preset second type in the sorting result is converted to the preset fourth type to obtain a new sorting result of the preset second type and a new sorting result of the preset fourth type.

[0037] The sorting results of the first preset type, the new sorting results of the second preset type, the sorting results of the third preset type, and the new sorting results of the fourth preset type of the same transaction type are sorted according to the second preset sorting rule to obtain the target sorting result.

[0038] Optionally, the step of obtaining the business data for each transaction in response to a received distributed transaction processing request includes:

[0039] Parse the message of the distributed transaction processing request to obtain the message information carried by the message;

[0040] Obtain the name of each transaction from the message information;

[0041] Based on the name of each transaction, obtain the interface for at least one branch transaction associated with each transaction;

[0042] Call the API of each branch transaction to obtain the business data of each account;

[0043] The business data of each account is encapsulated to obtain the resource package for each account;

[0044] The multiple resource packages of multiple accounts of the at least one branch transaction are identified as the business data for each transaction.

[0045] A second aspect of this application provides a distributed transaction processing apparatus, the apparatus comprising:

[0046] The acquisition module is used to acquire business data for each transaction in response to a received distributed transaction processing request, wherein the business data includes resource packages of at least one account of at least one branch transaction;

[0047] The analysis module is used to analyze the resource packages of each account in each branch transaction and obtain the analysis results for each account.

[0048] The merging module is used to merge multiple analysis results from multiple accounts in each branch transaction, and obtain the transaction type of the corresponding branch transaction based on the merging result;

[0049] The sorting module is used to classify and sort multiple transaction types of multiple branch transactions to obtain the target sorting result;

[0050] The submission module is used to submit each branch transaction starting from the head of the target sorting result, and obtain the decision result of the corresponding branch transaction;

[0051] The processing module is used to process each transaction based on the decision result of each branch transaction.

[0052] A third aspect of this application provides an electronic device including a processor and a memory, wherein the processor is configured to implement the distributed transaction processing method by executing a computer program stored in the memory.

[0053] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the distributed transaction processing method described above.

[0054] In summary, the distributed transaction processing method, apparatus, electronic device, and storage medium described in this application can promote the construction of smart cities and be applied in fields such as smart buildings, smart security, smart communities, smart living, and the Internet of Things. By analyzing the resource packages of each account in each branch transaction, the transaction type of the corresponding branch transaction is obtained based on the analysis results. In the process of obtaining the transaction type, multiple first preset indicators of multiple accounts from the same data source in the same branch transaction are merged to determine the transaction type of each sub-branch transaction of the same branch transaction. Since a task tree is created for the same data source, branch transactions are submitted through the same task tree, avoiding the slow submission of branch tasks caused by traversing different task trees for each branch transaction, thus improving the success rate and processing efficiency of branch transaction submission. By classifying and sorting multiple transaction types of multiple branch transactions, and submitting each branch transaction starting from the head of the target sorting result queue, the decision result of the corresponding branch transaction is obtained. Submitting each branch transaction sequentially starting from the head of the target sorting result queue avoids the phenomenon of data being updated in the account of the branch transaction during the branch transaction processing, thus improving the security of account data. Based on the decision result of each branch transaction, each transaction is processed. If the submission of a branch transaction fails, there is no need to directly stop the processing of the branch transaction and resubmit or roll back the branch transaction, which improves the processing efficiency of branch transactions. Attached Figure Description

[0055] Figure 1 This is a flowchart of the distributed transaction processing method provided in Embodiment 1 of this application.

[0056] Figure 2 This is a structural diagram of the distributed transaction processing device provided in Embodiment 2 of this application.

[0057] Figure 3 This is a schematic diagram of the structure of the electronic device provided in Embodiment 3 of this application. Detailed Implementation

[0058] To better understand the above-mentioned objectives, features, and advantages of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0059] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0060] Example 1

[0061] Figure 1 This is a flowchart of the distributed transaction processing method provided in Embodiment 1 of this application.

[0062] In this embodiment, the distributed transaction processing method can be applied to electronic devices. For electronic devices that need to perform distributed transaction processing, the distributed transaction processing function provided by the method of this application can be directly integrated into the electronic device, or it can be run in the electronic device in the form of a software development kit (SDK).

[0063] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0064] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, as well as machine learning and deep learning.

[0065] like Figure 1 As shown, the distributed transaction processing method specifically includes the following steps. Depending on different needs, the order of the steps in this flowchart can be changed, and some steps can be omitted.

[0066] 101. In response to a received distributed transaction processing request, obtain business data for each transaction, wherein the business data includes resource packages of at least one account of at least one branch transaction.

[0067] In this embodiment, for the financial field, when conducting account transactions, distributed transactions are used to submit each transaction. Each transaction contains at least one branch transaction, and each branch transaction contains at least one account. The business data of at least one account in each branch transaction may come from different data sources, and the data source can be a database that stores business data.

[0068] In this embodiment, the distributed transaction processing request is used to request the processing of multiple distributed tasks. When the electronic device receives the distributed processing request, it parses the distributed processing request to obtain the business data of each transaction. The business data includes: account details of the requesting account, account change details, basic account information, account data source, etc.

[0069] In an optional embodiment, the step of obtaining the business data for each transaction in response to a received distributed transaction processing request includes:

[0070] Parse the message of the distributed transaction processing request to obtain the message information carried by the message;

[0071] Obtain the name of each transaction from the message information;

[0072] Based on the name of each transaction, obtain the interface for at least one branch transaction associated with each transaction;

[0073] Call the API of each branch transaction to obtain the business data of each account;

[0074] The business data of each account is encapsulated to obtain the resource package for each account;

[0075] The multiple resource packages of multiple accounts of the at least one branch transaction are identified as the business data for each transaction.

[0076] In this embodiment, each transaction has a corresponding name. Based on the name, the interface of all branch transactions associated with that name can be obtained. The business data of each account can be obtained through the interface, and the business data of each account is encapsulated in the form of an npm package.

[0077] In this embodiment, npm is a package hosting platform under Node.js (runtime environment) used to host data packages. By encapsulating the business data of each account into a resource package in the form of an npm package and storing the encapsulated resource package to the corresponding data source, the security of the business data of each account is improved, thereby ensuring the security of the business data of each transaction.

[0078] 102. Analyze the resource packages of each account in each branch transaction to obtain the analysis results for each account.

[0079] In this embodiment, each account's resource package includes account operation type, account change details table, account change net value, account change details table, and account resource net change direction, etc.

[0080] In an optional embodiment, the analysis of the resource package for each account in each branch transaction to obtain the analysis results for each account includes:

[0081] Unzip the account package for each account to obtain the corresponding account operation types and account change details;

[0082] Based on the account operation type and the account change details, obtain the indicator results for each first preset indicator for each account;

[0083] The results of multiple indicators of multiple first preset indicators for each account are determined as the analysis results for each account.

[0084] In this embodiment, account operation types include outflow operations, inflow operations, and freeze operations.

[0085] In this embodiment, a first preset indicator can be set in advance, wherein the first preset indicator includes the ability to ensure the success of positive account resource retention and the ability to ensure the success of negative account resource retention. The ability to ensure the success of positive account resource retention refers to the account resources in the account performing an inflow operation, and the ability to ensure the success of negative account resource retention refers to the account resources in the account performing an outflow operation.

[0086] For example, if account A transfers M yuan to account B, then account A pays out M yuan, and the indicator result for account A's positive resource protection success capability is negative, while the indicator result for account A's negative resource protection success capability is positive; if account B receives M yuan, the indicator result for account B's positive resource protection success capability is positive, while the indicator result for account B's negative resource protection success capability is negative.

[0087] 103. Merge the multiple analysis results of multiple accounts for each branch transaction, and obtain the transaction type of the corresponding branch transaction based on the merge result.

[0088] In this embodiment, the transaction type of the branch transaction can be preset. Specifically, the transaction types of the branch transaction include a preset first type (transaction type: A), a preset second type (transaction type: B), a preset third type (transaction type: C), and a preset fourth type (transaction type: D).

[0089] For example, referring to Table 1, transaction type A refers to whether the branch transaction has a forward success guarantee capability and a reverse success guarantee capability, and the branch transaction is not reserved; transaction type B refers to whether the branch transaction has a forward success guarantee capability and a reverse success guarantee capability, and the branch transaction is not reserved; transaction type C refers to whether the branch transaction has a forward success guarantee capability and a reverse success guarantee capability, and the branch transaction is not reserved; and transaction type D refers to whether the branch transaction has a forward success guarantee capability and a reverse success guarantee capability, and the branch transaction is reserved.

[0090]

[0091] Table 1

[0092] In an optional embodiment, merging multiple analysis results for multiple accounts of each branch transaction and obtaining the transaction type of the corresponding branch transaction based on the merged result includes:

[0093] Based on the data source from which the account was obtained, multiple accounts in the same branch transaction are categorized.

[0094] The indicator results of multiple first preset indicators from the same data source are merged to obtain the indicator results of each second preset indicator of the corresponding branch transaction.

[0095] Based on the results of multiple second preset indicators, obtain the transaction type of each sub-branch transaction of the corresponding branch transaction;

[0096] The transaction types of multiple sub-branch transactions of the same branch transaction are used as the transaction types of the corresponding branch transaction.

[0097] For example, see Table 2:

[0098]

[0099] Table 2

[0100] The business data of accounts 031, 051, and 071 in branch transaction 1 comes from data source M. Specifically, the first preset indicator for account 031 is: the indicator value for the forward success guarantee of account resources is "yes," and the indicator value for the reverse success guarantee of account resources is "no." The first preset indicator for account 051 is: the indicator value for the forward success guarantee of account resources is "no," and the indicator value for the reverse success guarantee of account resources is "yes." The first preset indicator for account 071 is: the indicator value for the forward success guarantee of account resources is "yes," and the indicator value for the reverse success guarantee of account resources is "yes." The results of the multiple first preset indicators for accounts 031, 051, and 071 are merged to obtain the second preset indicator for branch transaction 1: the indicator value for the forward success guarantee of branch transaction is "no," and the indicator value for the reverse success guarantee of branch transaction is "no." Therefore, the first transaction type of branch transaction 1 is determined to be B.

[0101] For example, the business data of account 091 in branch transaction 1 comes from data source N. Using the same process as above, the second transaction type of branch transaction 1 is obtained as C.

[0102] In this embodiment, by merging multiple first preset indicators of multiple accounts from the same data source in the same branch transaction, the transaction type of each sub-branch transaction of the same branch transaction is determined, and the transactions contained in each transaction type originate from the same data source.

[0103] In this embodiment, a task tree is created in advance based on the branch transactions. Since a task tree is created for the same data source, and the branch transactions are submitted through the same task tree, the slow submission of branch tasks caused by traversing different task trees for each branch transaction is avoided, thereby improving the success rate and processing efficiency of branch transaction submission.

[0104] 104. Classify and sort multiple transaction types of multiple branch transactions to obtain the target sorting result.

[0105] In this embodiment, each branch transaction may contain multiple sub-branch transactions, each sub-branch transaction corresponds to a transaction type, and the target sorting result of each transaction includes the branch transaction and / or the sub-branch transactions of the branch transaction.

[0106] In an optional embodiment, classifying and sorting multiple transaction types of multiple branch transactions to obtain a target sorting result includes:

[0107] The multiple branch transactions are classified according to transaction type, wherein the transaction type includes a preset first type, a preset second type, a preset third type, and a preset fourth type;

[0108] Sort multiple branch transactions of the same transaction type according to a preset first sorting rule to obtain the sorting result of the corresponding transaction type;

[0109] Count the number of branch transactions in the predefined second type of sorting results for the same transaction type;

[0110] If the quantity is not 1, one branch transaction of the preset second type is retained in the sorting, and the transaction type of the remaining branch transactions of the preset second type in the sorting result is converted to the preset fourth type to obtain a new sorting result of the preset second type and a new sorting result of the preset fourth type.

[0111] The sorting results of the first preset type, the new sorting results of the second preset type, the sorting results of the third preset type, and the new sorting results of the fourth preset type of the same transaction type are sorted according to the second preset sorting rule to obtain the target sorting result.

[0112] In this embodiment, if the target sequence result contains multiple branch transactions of transaction type B, the rollback of the branch transactions cannot be achieved. When multiple preset second types with multiple branch transactions are counted, the transaction type of the remaining branch transactions of the preset second type in the sorting result is converted to a preset fourth type through reservation conversion. Specifically, the first preset indicator branch transaction of the preset second type is converted from non-reserved to reserved, that is, the preset second type branch transactions are converted to the preset fourth type.

[0113] In this embodiment, by converting multiple preset second-type branch transactions in the target sorting result into preset fourth-type transactions, it is ensured that the target sorting result contains a unique preset second-type transaction. This avoids the phenomenon that the previous preset first-type branch transaction cannot be rolled back due to the existence of multiple preset second-type branch transactions, thereby improving the efficiency and accuracy of transaction processing.

[0114] Furthermore, the method also includes:

[0115] If the quantity is 1, the sorting results of multiple transactions are sorted according to the preset second sorting rule to obtain the target sorting result.

[0116] In this embodiment, a first sorting rule can be preset. For example, the first sorting rule can sort accounts according to the order of their account numbers.

[0117] In this embodiment, a second sorting rule can be preset. For example, the second sorting rule is to sort according to the rule of transaction type A-transaction type B-transaction type C-transaction type D to obtain the target sorting result.

[0118] 105. Starting from the head of the target sorting result, submit each branch transaction to obtain the decision result of the corresponding branch transaction.

[0119] In this embodiment, the decision result includes successful branch transaction commit and failed branch transaction commit.

[0120] In this embodiment, by sorting the branch transactions of each transaction according to the rule of transaction type A-transaction type B-transaction type C-transaction type D, and submitting each branch transaction sequentially starting from the head of the target sorting result, the phenomenon of data being updated in the account of the branch transaction is avoided during the processing of the branch transaction, thereby improving the security of account data.

[0121] 106. Process each transaction based on the decision result of each branch transaction.

[0122] In this embodiment, if each branch transaction is successfully committed, the processed branch transaction data is written to a table and the corresponding account is updated.

[0123] In this embodiment, if each branch transaction fails to commit, different strategies are used to process the branch transaction according to the transaction type of the failed branch transaction.

[0124] In an optional embodiment, processing each transaction based on the decision result of each branch transaction includes one or more of the following operations:

[0125] If the decision result of any branch transaction is a commit failure, obtain the transaction type of that branch transaction;

[0126] If the transaction type of any of the branch transactions is a preset first type, the corresponding branch transaction is rolled back;

[0127] If the transaction type of any branch transaction is a preset second type, roll back the branch transaction of the preset first type corresponding to any branch transaction;

[0128] If any branch transaction has a preset third type of transaction, determine whether there is a preset second type of branch transaction in the sorting result. If there is a preset second type of branch transaction in the sorting result, resubmit the corresponding branch transaction; if there is no preset second type of branch transaction in the sorting result, resubmit or roll back the corresponding transaction.

[0129] If any branch transaction is of the preset fourth type, all accounts in the corresponding branch transaction are frozen.

[0130] In this embodiment, if the transaction type of the branch transaction that fails to commit is transaction type A, the branch transaction corresponding to transaction type A can be rolled back instead of ending directly, which improves the efficiency of distributed transaction processing.

[0131] In this embodiment, if the transaction type of the failed branch transaction is B, since the target sequence result contains a branch transaction of transaction type B, the branch transaction of transaction type A corresponding to the branch transaction of transaction type B is determined by the task tree stored in the database in advance, and the branch transaction is rolled back.

[0132] In this embodiment, if the transaction type of the failed branch transaction is C, it is determined whether there is a branch transaction of type B in the target sequence result. If there is, the branch transaction is resubmitted; if not, the branch transaction is rolled back or resubmitted.

[0133] For example, if account A receives 20 yuan, it needs to first withdraw 20 yuan and then receive 20 yuan. If withdrawing 20 yuan from account A fails, and there is a branch transaction of type B, it means that the branch transaction cannot guarantee success in either the forward or reverse direction. In this case, the withdrawal of 20 yuan from account A should be resubmitted. If withdrawing 20 yuan from account A fails, and there is no branch transaction of type B, it means that the branch transaction cannot guarantee success in the forward direction, but can guarantee success in the reverse direction. In this case, the withdrawal of 20 yuan from account A should be resubmitted or rolled back. This ensures the safety of account funds and does not stop the processing of branch transactions, thereby improving the processing efficiency of branch transactions.

[0134] Furthermore, after freezing all accounts in the corresponding branch transaction, the method further includes:

[0135] Identify the reasons why a branch transaction failed to commit;

[0136] Retrieve the frozen recharge amount of the target account from the commit failure reasons of each branch transaction;

[0137] From the available balance of the target account, the recharge amount is transferred to the frozen balance of the frozen target account through a preset interface, and the branch transaction corresponding to the frozen account is resubmitted.

[0138] In this embodiment, if the transaction type of the failed branch transaction is D, it means that the branch transaction was successfully forwarded, that is, the funds were not successfully deposited. This may be because the recharge account may have insufficient balance. The recharge account needs to be frozen, and the branch transaction is resubmitted after ensuring that the balance in the recharge account meets the recharge conditions. There is no need to stop the processing of the branch transaction directly, thereby improving the processing efficiency of the branch transaction.

[0139] In summary, the distributed transaction processing method described in this embodiment analyzes the resource packages of each account in each branch transaction, obtains the transaction type of the corresponding branch transaction based on the analysis results, and determines the transaction type of each sub-branch transaction of the same branch transaction by merging multiple first preset indicators of multiple accounts from the same data source of the same branch transaction. Since a task tree is created for the same data source, and branch transactions are submitted through the same task tree, the slow submission of branch tasks caused by traversing different task trees for each branch transaction is avoided, thus improving the success rate and processing efficiency of branch transaction submission. Multiple transaction types of multiple branch transactions are classified and sorted, and each branch transaction is submitted starting from the head of the target sorting result queue to obtain the decision result of the corresponding branch transaction. Each branch transaction is submitted sequentially starting from the head of the target sorting result queue, avoiding the phenomenon of data being updated in the account of the branch transaction during the branch transaction processing, thus improving the security of account data. Based on the decision result of each branch transaction, each transaction is processed. If the submission of a branch transaction fails, it is not necessary to directly stop the processing of that branch transaction and resubmit or roll back the branch transaction, thus improving the processing efficiency of branch transactions.

[0140] Example 2

[0141] Figure 2 This is a structural diagram of the distributed transaction processing device provided in Embodiment 2 of this application.

[0142] In some embodiments, the distributed transaction processing device 20 may include multiple functional modules composed of program code segments. The program code of each program segment in the distributed transaction processing device 20 may be stored in the memory of an electronic device and executed by the at least one processor to perform (see details). Figure 1 (Description) The functionality of distributed transaction processing.

[0143] In this embodiment, the distributed transaction processing device 20 can be divided into multiple functional modules according to the functions it performs. These functional modules may include: an acquisition module 201, an analysis module 202, a merging module 203, a sorting module 204, a submission module 205, and a processing module 206. As used in this application, a module refers to a series of computer-readable instruction segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0144] The acquisition module 201 is used to acquire business data for each transaction in response to a received distributed transaction processing request, wherein the business data includes resource packages of at least one account of at least one branch transaction.

[0145] Analysis module 202 is used to analyze the resource packages of each account in each branch transaction and obtain the analysis results for each account.

[0146] The merging module 203 is used to merge multiple analysis results of multiple accounts in each branch transaction and obtain the transaction type of the corresponding branch transaction based on the merging result.

[0147] The sorting module 204 is used to classify and sort multiple transaction types of multiple branch transactions to obtain the target sorting result.

[0148] The submission module 205 is used to submit each branch transaction starting from the head of the target sorting result and obtain the decision result of the corresponding branch transaction.

[0149] The processing module 206 is used to process each transaction based on the decision result of each branch transaction.

[0150] In an optional embodiment, the acquisition module 201 is configured to: parse the message of the distributed transaction processing request to obtain the message information carried by the message; obtain the name of each transaction from the message information; obtain the interface of at least one branch transaction associated with each transaction based on the name of each transaction; call the interface of each branch transaction to obtain the business data of each account; encapsulate the business data of each account to obtain the resource package of each account; and determine the multiple resource packages of multiple accounts of the at least one branch transaction as the business data of each transaction.

[0151] In an optional embodiment, the analysis module 202 is configured to: decompress the account package of each account, obtain the account operation type and account change details table of the corresponding account; obtain the indicator result of each first preset indicator of each account according to the account operation type and the account change details; and determine the multiple indicator results of multiple first preset indicators of each account as the analysis result of each account.

[0152] In an optional embodiment, the merging module 203 is configured to: classify multiple accounts of the same branch transaction according to the data source of the acquired accounts; merge the indicator results of multiple first preset indicators from the same data source to obtain the indicator result of each second preset indicator of the corresponding branch transaction; obtain the transaction type of each sub-branch transaction of the corresponding branch transaction based on the multiple indicator results of the multiple second preset indicators; and use the transaction types of the multiple sub-branch transactions of the same branch transaction as the transaction type of the corresponding branch transaction.

[0153] In an optional embodiment, the sorting module 204 is configured to: classify the plurality of branch transactions according to transaction type, wherein the transaction type includes a preset first type, a preset second type, a preset third type, and a preset fourth type; sort the plurality of branch transactions of the same transaction type according to a preset first sorting rule to obtain a sorting result for the corresponding transaction type; count the number of branch transactions in the sorting result of the preset second type of the same transaction type; if the number is not 1, retain 1 branch transaction of the preset second type in the sorting, and convert the transaction type of the remaining branch transactions of the preset second type in the sorting result to the preset fourth type to obtain a new sorting result of the preset second type and a new sorting result of the preset fourth type; sort the sorting result of the preset first type, the new sorting result of the preset second type, the sorting result of the preset third type, and the new sorting result of the preset fourth type of the same transaction type according to a preset second sorting rule to obtain a target sorting result.

[0154] Furthermore, if the quantity is 1, the sorting results of multiple transactions are sorted according to a preset second sorting rule to obtain the target sorting result.

[0155] In an optional embodiment, the processing module 206 is configured to: if the decision result of any branch transaction is a commit failure, obtain the transaction type of the arbitrary branch transaction; if the transaction type of the arbitrary branch transaction is a preset first type, roll back the corresponding branch transaction; if the transaction type of the arbitrary branch transaction is a preset second type, roll back the branch transaction of the preset first type corresponding to the arbitrary branch transaction; if the transaction type of the arbitrary branch transaction is a preset third type, determine whether there is a branch transaction of the preset second type in the sorting result; if there is a branch transaction of the preset second type in the sorting result, resubmit the corresponding branch transaction; if there is no branch transaction of the preset second type in the sorting result, resubmit or roll back the corresponding transaction; if the transaction type of the arbitrary branch transaction is a preset fourth type, freeze all accounts in the corresponding branch transaction.

[0156] Furthermore, after freezing all accounts in the corresponding branch transaction, the reasons for the failure of the branch transaction are identified; the recharge amount of the frozen target account is obtained from the reasons for the failure of each branch transaction; the recharge amount is transferred from the available balance of the target account to the frozen balance of the frozen target account through a preset interface, and the branch transaction corresponding to the frozen account is resubmitted.

[0157] In this embodiment, if the transaction type of the failed branch transaction is D, it means that the branch transaction was successfully forwarded, that is, the funds were not successfully deposited. This may be because the recharge account may have insufficient balance. The recharge account needs to be frozen, and the branch transaction is resubmitted after ensuring that the balance in the recharge account meets the recharge conditions. There is no need to stop the processing of the branch transaction directly, thereby improving the processing efficiency of the branch transaction.

[0158] In summary, the distributed transaction processing device described in this embodiment analyzes the resource packages of each account in each branch transaction, obtains the transaction type of the corresponding branch transaction based on the analysis results, and determines the transaction type of each sub-branch transaction of the same branch transaction by merging multiple first preset indicators of multiple accounts from the same data source of the same branch transaction. Since a task tree is created for the same data source, and branch transactions are submitted through the same task tree, the slow submission of branch tasks caused by traversing different task trees for each branch transaction is avoided, thus improving the success rate and processing efficiency of branch transaction submission. Multiple transaction types of multiple branch transactions are classified and sorted, and each branch transaction is submitted starting from the head of the target sorting result queue to obtain the decision result of the corresponding branch transaction. Submitting each branch transaction sequentially starting from the head of the target sorting result queue avoids the phenomenon of data being updated in the account of the branch transaction during the branch transaction processing, thus improving the security of account data. Based on the decision result of each branch transaction, each transaction is processed. If the submission of a branch transaction fails, it is not necessary to directly stop the processing of that branch transaction and resubmit or roll back the branch transaction, thus improving the processing efficiency of branch transactions.

[0159] Example 3

[0160] See Figure 3 The diagram shown is a structural schematic of an electronic device provided in Embodiment 3 of this application. In a preferred embodiment of this application, the electronic device 3 includes a memory 31, at least one processor 32, at least one communication bus 33, and a transceiver 34.

[0161] Those skilled in the art should understand that Figure 3 The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 3 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0162] In some embodiments, the electronic device 3 is an electronic device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 3 may also include client devices, including, but not limited to, any electronic product capable of human-computer interaction with a client via a keyboard, mouse, remote control, touchpad, or voice control device, such as personal computers, tablet computers, smartphones, and digital cameras.

[0163] It should be noted that the electronic device 3 is merely an example. Other existing or future electronic products that are suitable for this application should also be included within the scope of protection of this application and are incorporated herein by reference.

[0164] In some embodiments, the memory 31 is used to store program code and various data, such as the distributed transaction processing device 20 installed in the electronic device 3, and to achieve high-speed and automatic access to programs or data during the operation of the electronic device 3. The memory 31 includes read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0165] In some embodiments, the at least one processor 32 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits packaged with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The at least one processor 32 is the control unit of the electronic device 3, connecting various components of the entire electronic device 3 via various interfaces and lines. It executes programs or modules stored in the memory 31 and calls data stored in the memory 31 to perform various functions and process data of the electronic device 3.

[0166] In some embodiments, the at least one communication bus 33 is configured to enable communication between the memory 31 and the at least one processor 32, etc.

[0167] Although not shown, the electronic device 3 may also include a power supply (such as a battery) to power the various components. Optionally, the power supply may be logically connected to the at least one processor 32 via a power management device, thereby enabling functions such as charging, discharging, and power consumption management. The power supply may also include one or more DC or AC power supplies, recharging devices, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The electronic device 3 may also include various sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be described in detail here.

[0168] It should be understood that the embodiments described are for illustrative purposes only and are not limited to this structure in the scope of the patent application.

[0169] The integrated unit implemented as a software functional module described above can be stored in a computer-readable storage medium. This software functional module, stored in a storage medium, includes several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) or processor to execute portions of the methods described in the various embodiments of this application.

[0170] In a further embodiment, combined with Figure 2 The at least one processor 32 can execute the operating device of the electronic device 3 and various installed applications (such as the distributed transaction processing device 20), program code, etc., for example, the various modules mentioned above.

[0171] The memory 31 stores program code, and the at least one processor 32 can call the program code stored in the memory 31 to execute related functions. For example, Figure 2 The modules described herein are program codes stored in the memory 31 and executed by the at least one processor 32, thereby realizing the functions of the modules to achieve the purpose of distributed transaction processing.

[0172] For example, the program code can be divided into one or more modules / units, which are stored in the memory 31 and executed by the processor 32 to complete this application. The one or more modules / units can be a series of computer-readable instruction segments capable of performing a specific function, which describe the execution process of the program code in the electronic device 3. For example, the program code can be divided into an acquisition module 201, an analysis module 202, a merging module 203, a sorting module 204, a submission module 205, and a processing module 206.

[0173] In one embodiment of this application, the memory 31 stores a plurality of computer-readable instructions, which are executed by the at least one processor 32 to implement the function of distributed transaction processing.

[0174] Specifically, the specific implementation method of the above instructions by the at least one processor 32 can be referred to Figure 1 The descriptions of the relevant steps in the corresponding embodiments are not repeated here.

[0175] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0176] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0177] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0178] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other elements or, and the singular does not exclude the plural. Multiple elements or devices recited in this application may also be implemented by a single element or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A distributed transaction processing method, characterized in that, The method includes: In response to a received distributed transaction processing request, business data for each transaction is obtained, wherein the business data includes resource packages of at least one account of at least one branch transaction; The resource package of each account in each branch transaction is analyzed to obtain the analysis results of each account, wherein the analysis results of each account include the indicator results of multiple first preset indicators for each account; The analysis results of multiple accounts for each branch transaction are merged, and the transaction type of the corresponding branch transaction is obtained based on the merged result. The transaction type includes four preset types (first, second, third, and fourth) based on the branch transaction's forward success guarantee capability, reverse success guarantee capability, and whether resources are reserved. The process of merging the analysis results of multiple accounts for each branch transaction and obtaining the transaction type of the corresponding branch transaction includes: classifying multiple accounts of the same branch transaction according to the data source of the acquired accounts; merging the indicator results of multiple first preset indicators from the same data source to obtain the indicator result of each second preset indicator of the corresponding branch transaction; obtaining the transaction type of each sub-branch transaction of the corresponding branch transaction based on the multiple indicator results of the multiple second preset indicators; and using the transaction types of the multiple sub-branch transactions of the same branch transaction as the transaction type of the corresponding branch transaction. The first and second preset indicators both include the ability to ensure success in the forward direction of branch transactions, the ability to ensure success in the reverse direction of branch transactions, and whether branch transactions are reserved. The first preset type is no ability to ensure success in the forward direction of branch transactions, yes ability to ensure success in the reverse direction of branch transactions, and no reservation of branch transactions; the second preset type is no ability to ensure success in the forward direction of branch transactions, no ability to ensure success in the reverse direction of branch transactions, and no reservation of branch transactions; the third preset type is yes ability to ensure success in the forward direction of branch transactions, yes ability to ensure success in the reverse direction of branch transactions, and no reservation of branch transactions; the fourth preset type is yes ability to ensure success in the forward direction of branch transactions, no ability to ensure success in the reverse direction of branch transactions, and reservation of branch transactions. Create a corresponding task tree for each data source; Classify and sort multiple transaction types across multiple branches to obtain the target sorting result; Starting from the head of the target sorting result queue, each branch transaction is submitted through the task tree of the data source corresponding to each branch transaction to obtain the decision result of the corresponding branch transaction; Each transaction is processed based on the decision result of each branch transaction.

2. The distributed transaction processing method as described in claim 1, characterized in that, The process of processing each transaction based on the decision result of each branch transaction includes one or more of the following operations: If the decision result of any branch transaction is a commit failure, obtain the transaction type of that branch transaction; If the transaction type of any of the branch transactions is a preset first type, the corresponding branch transaction is rolled back; If the transaction type of any branch transaction is a preset second type, roll back the branch transaction of the preset first type corresponding to any branch transaction; If the transaction type of any branch transaction is a preset third type, determine whether there is a preset second type branch transaction in the sorting result. If there is a preset second type branch transaction in the sorting result, resubmit the corresponding branch transaction. If the pre-defined second type of branch transaction is not found in the sorting results, the corresponding transaction is recommitted or rolled back. If any branch transaction is of the preset fourth type, all accounts in the corresponding branch transaction are frozen.

3. The distributed transaction processing method as described in claim 2, characterized in that, After freezing all accounts in the corresponding branch transaction, the method further includes: Identify the reasons why a branch transaction failed to commit; Retrieve the frozen recharge amount of the target account from the commit failure reasons of each branch transaction; From the available balance of the target account, the recharge amount is transferred to the frozen balance of the frozen target account through a preset interface, and the branch transaction corresponding to the frozen account is resubmitted.

4. The distributed transaction processing method as described in claim 1, characterized in that, The analysis of the resource packages for each account in each branch transaction yields the analysis results for each account, including: Unzip the account package for each account to obtain the corresponding account operation types and account change details; Based on the account operation type and the account change details, obtain the indicator results for each first preset indicator for each account; The results of multiple indicators of multiple first preset indicators for each account are determined as the analysis results for each account.

5. The distributed transaction processing method as described in claim 1, characterized in that, The process of classifying and sorting multiple transaction types across multiple branches to obtain the target sorting result includes: Sort multiple branch transactions of the same transaction type according to a preset first sorting rule to obtain the sorting result of the corresponding transaction type; Count the number of branch transactions in the predefined second type of sorting results for the same transaction type; If the quantity is not 1, one branch transaction of the preset second type is retained in the sorting, and the transaction type of the remaining branch transactions of the preset second type in the sorting result is converted to the preset fourth type to obtain a new sorting result of the preset second type and a new sorting result of the preset fourth type. The sorting results of the first preset type, the new sorting results of the second preset type, the sorting results of the third preset type, and the new sorting results of the fourth preset type of the same transaction type are sorted according to the second preset sorting rule to obtain the target sorting result.

6. The distributed transaction processing method as described in claim 1, characterized in that, The step of responding to a received distributed transaction processing request and obtaining business data for each transaction includes: Parse the message of the distributed transaction processing request to obtain the message information carried by the message; Obtain the name of each transaction from the message information; Based on the name of each transaction, obtain the interface for at least one branch transaction associated with each transaction; Call the API of each branch transaction to obtain the business data of each account; The business data of each account is encapsulated to obtain the resource package for each account; The multiple resource packages of multiple accounts of the at least one branch transaction are identified as the business data for each transaction.

7. A distributed transaction processing device, characterized in that, The apparatus is used to implement the distributed transaction processing method as described in any one of claims 1 to 6, and the apparatus comprises: The acquisition module is used to acquire business data for each transaction in response to a received distributed transaction processing request, wherein the business data includes resource packages of at least one account of at least one branch transaction; The analysis module is used to analyze the resource package of each account in each branch transaction to obtain the analysis results of each account. The analysis results of each account include the indicator results of multiple first preset indicators for each account. The merging module is used to merge multiple analysis results from multiple accounts of each branch transaction, and obtain the transaction type of the corresponding branch transaction based on the merging result. The transaction type includes preset first, second, third, and fourth types, categorized according to the branch transaction's forward success guarantee capability, reverse success guarantee capability, and whether resources are reserved. The module also categorizes multiple accounts of the same branch transaction according to the data source of the acquired accounts, and creates a corresponding task tree for each data source. The merging of multiple analysis results from multiple accounts of each branch transaction and obtaining the transaction type of the corresponding branch transaction based on the merging result includes: categorizing multiple accounts of the same branch transaction according to the data source of the acquired accounts; merging the indicator results of multiple first preset indicators from the same data source to obtain the indicator results of each second preset indicator of the corresponding branch transaction; obtaining the transaction type of each sub-branch transaction of the corresponding branch transaction based on the multiple indicator results of the multiple second preset indicators; and using the transaction types of the multiple sub-branch transactions of the same branch transaction as the transaction type of the corresponding branch transaction. The first and second preset indicators both include the ability to ensure success in the forward direction of branch transactions, the ability to ensure success in the reverse direction of branch transactions, and whether branch transactions are reserved. The first preset type is no ability to ensure success in the forward direction of branch transactions, yes ability to ensure success in the reverse direction of branch transactions, and no reservation of branch transactions; the second preset type is no ability to ensure success in the forward direction of branch transactions, no ability to ensure success in the reverse direction of branch transactions, and no reservation of branch transactions; the third preset type is yes ability to ensure success in the forward direction of branch transactions, yes ability to ensure success in the reverse direction of branch transactions, and no reservation of branch transactions; the fourth preset type is yes ability to ensure success in the forward direction of branch transactions, no ability to ensure success in the reverse direction of branch transactions, and reservation of branch transactions. The sorting module is used to classify and sort multiple transaction types of multiple branch transactions to obtain the target sorting result; The submission module is used to submit each branch transaction from the head of the queue of the target sorting results through the task tree of the data source corresponding to each branch transaction, and obtain the decision result of the corresponding branch transaction. The processing module is used to process each transaction based on the decision result of each branch transaction.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory, wherein the processor is configured to implement the distributed transaction processing method as described in any one of claims 1 to 6 when executing a computer program stored in the memory.

9. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the distributed transaction processing method as described in any one of claims 1 to 6.

Images