Distributed transaction processing method

Abstract

The present disclosure proposes a method for processing distributed transactions, which relates to the field of data processing technology. The method includes: in response to receiving a transaction request, determining the target business process corresponding to the transaction type of the transaction request; based on multiple target tasks that need to be executed by the target business process, opening the main transaction of the distributed transaction for the transaction request, and registering the main transaction flow to the local database; wherein the main transaction includes multiple ordered sub-transactions, each sub-transaction corresponds to a target task; traversing the multiple ordered sub-transactions in sequence, and processing the currently traversed sub-transaction based on the judgment result of whether the currently traversed sub-transaction is a local transaction; in response to multiple sub-transactions being successfully processed, ending the main transaction, and updating the status of the main transaction flow in the local database to a completed state. In this way, the number of flow registrations can be reduced and performance can be improved. At the same time, the management of distributed transactions is implemented based on the local flow registration system, which has better performance.

Description

Technical Field

[0001] The present disclosure relates to the field of data processing technology, and in particular to a method for processing distributed transactions. Background Art

[0002] A distributed system is composed of a group of service nodes (or computer nodes) that communicate over a network and coordinate their work to complete a common task. Due to the geographical and logical dispersion of its services and data, transaction management is much more complex than for traditional monolithic applications. With the rise of microservices architecture, in actual financial application scenarios, multiple microservices work together to complete a task or business function, which requires the participation of distributed transactions. When faced with long business processes, SAGA (Sequentially Consistent Autonomous Global Transactions) can be used. SAGA is an event-driven distributed transaction model that can be widely used in distributed systems with microservices architectures. Its purpose is to ensure that operations between multiple services in a distributed system are sequentially consistent, thereby ensuring eventual consistency.

[0003] In related technologies, the processing method of distributed transactions requires independent processing of distributed transaction control processing and business code logic processing. Both transaction processes and business flow information need to be saved in the database at the same time, which reduces the performance of microservices and makes it difficult to meet the high-concurrency business scenario requirements of the core business systems of medium and large financial institutions. Summary of the Invention

[0004] The present disclosure aims to solve one of the technical problems in the related art at least to a certain extent.

[0005] One aspect of the present disclosure provides a distributed transaction processing method to reduce the number of transaction registrations and improve performance. Furthermore, distributed transaction management is implemented based on a local transaction registration system, resulting in better performance.

[0006] The first embodiment of the present disclosure provides a method for processing distributed transactions, including:

[0007] In response to receiving a transaction request, determining a target business process corresponding to a transaction type of the transaction request;

[0008] Based on the multiple target tasks required to be executed by the target business process, a main transaction of a distributed transaction is opened for the transaction request, and the main transaction flow is registered in a local database; wherein the main transaction includes multiple ordered sub-transactions, each sub-transaction corresponding to a target task;

[0009] Traversing the multiple ordered sub-transactions in sequence, and processing the currently traversed sub-transaction according to a determination result of whether the currently traversed sub-transaction is a local transaction;

[0010] In response to the multiple sub-transactions being successfully processed, the main transaction is terminated, and the status of the main transaction pipeline in the local database is updated to a completed status.

[0011] A second embodiment of the present disclosure provides a distributed transaction processing device, including:

[0012] a determination module, configured to, in response to receiving a transaction request, determine a target business process corresponding to a transaction type of the transaction request;

[0013] An opening registration module is used to open a main transaction of a distributed transaction for the transaction request based on multiple target tasks required to be executed by the target business process, and register the main transaction flow in a local database; wherein the main transaction includes multiple ordered sub-transactions, each sub-transaction corresponding to a target task;

[0014] a traversal processing module, configured to sequentially traverse the plurality of ordered sub-transactions and process the currently traversed sub-transaction according to a determination result of whether the currently traversed sub-transaction is a local transaction;

[0015] The end update module is configured to end the main transaction in response to the multiple sub-transactions being successfully processed, and update the status of the main transaction pipeline in the local database to a completed status.

[0016] The third embodiment of the present disclosure proposes an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the distributed transaction processing method proposed in the first embodiment of the present disclosure.

[0017] The fourth embodiment of the present disclosure proposes a non-temporary computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it implements the distributed transaction processing method proposed in the first embodiment of the present disclosure.

[0018] The fifth embodiment of the present disclosure proposes a computer program product. When the instructions in the computer program product are executed by a processor, the distributed transaction processing method proposed in the first embodiment of the present disclosure is executed.

[0019] The technical solutions provided by the above embodiments of the present disclosure bring at least the following beneficial effects:

[0020] When processing distributed transactions, distributed transaction control processing and business code logic processing can share the same flow table, that is, the service flow required by the business and the main transaction flow of the distributed transaction are combined into one. Only the main transaction flow needs to be logged in the local database, which can reduce the number of flow registrations and improve the performance of microservices to meet the high-concurrency business scenario requirements of the core business systems of medium and large financial institutions. Among them, by using aspect-oriented programming (Spring AOP) technology, the relevant operations of the local database flow table are inserted, which can achieve no changes to the business logic code and no intrusion into the business logic code. At the same time, the management of distributed transactions is implemented based on the local flow registration system. For example, registering the main transaction flow to the local database reduces the delay and complexity caused by network calls compared to the traditional external service or remote call service to implement transaction management, and has better performance.

[0021] Furthermore, distributed transaction processing logic is encapsulated within the SDK, eliminating the need to implement distributed transaction processing separately within the business logic code. This approach allows developers to orchestrate business processes directly through visual tools without having to deeply understand the complex implementation of SAGA. The SDK then automatically orchestrates distributed transactions. This eliminates the need for developers to write dedicated code, improving development efficiency and code quality while significantly reducing the difficulty of developing distributed microservices.

[0022] Additional aspects and advantages of the present disclosure will be given in part in the description below and in part will be obvious from the description below, or will be learned through practice of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The above and / or additional aspects and advantages of the present disclosure will become apparent and readily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0024] Figure 1 A flowchart of a distributed transaction processing method provided by an embodiment of the present disclosure;

[0025] Figure 2 A flowchart of another distributed transaction processing method provided by an embodiment of the present disclosure;

[0026] Figure 3 A flowchart of another distributed transaction processing method provided by an embodiment of the present disclosure;

[0027] Figure 4 A flowchart of another distributed transaction processing method provided by an embodiment of the present disclosure;

[0028] Figure 5 A schematic diagram of specific implementation steps of a distributed transaction processing method provided by an embodiment of the present disclosure;

[0029] Figure 6 A schematic diagram of the structure of a distributed transaction processing device provided by an embodiment of the present disclosure;

[0030] Figure 7 It is a schematic structural diagram of an electronic device shown in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0031] The following describes in detail embodiments of the present disclosure, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present disclosure, and should not be construed as limiting the present disclosure.

[0032] Currently, the implementation of SAGA transactions has the following two main problems:

[0033] First, microservice development is difficult. In actual engineering development, commercial products are only technically packaged through SDKs (Software Development Kits) and provided to application developers. Developers need to handle a large amount of distributed transaction-related logic in the business logic code, and need to implement business processes and handle distributed transaction processes based on the system design, which requires high developer capabilities. Investing a large number of highly skilled and professional technical personnel in the project not only increases project costs, but also increases the complexity of the system, making it difficult to ensure quality. Especially in financial application scenarios, system defects caused by transaction processing are one of the major challenges in building core business systems.

[0034] The second aspect is the performance issue. Performance is also one of the important challenges of distributed transaction processing. The existing distributed transaction processing methods generally require distributed transaction control processing and business code logic processing to be handled independently. Both transaction processes and business flow information need to be stored in the database at the same time. That is, distributed transaction control processing and business code logic processing need to use different flow tables in the database respectively, one of which is used to record transaction flow, and the other is used to record service flow. It should be noted that registering service flow and registering transaction flow are two completely independent actions, which are implemented based on two different local transactions. This will increase the processing time, resource overhead and database access pressure of distributed transactions, reduce the performance of microservices (such as throughput, response time, resource utilization, etc.), and make it difficult to meet the high-concurrency business scenario requirements of the core business systems of medium and large financial institutions.

[0035] In response to at least one problem existing in the prior art, one aspect of the present disclosure provides a method and apparatus for processing distributed transactions.

[0036] The following describes the distributed transaction processing method and apparatus according to the embodiment of the present disclosure with reference to the accompanying drawings. Before describing the embodiment of the present disclosure in detail, for ease of understanding, the following common technical terms are first introduced:

[0037] A distributed transaction refers to a transaction in which the transaction participants, the server supporting the transaction, the resource server, and the transaction manager are located on different nodes of different distributed systems.

[0038] A local transaction refers to an application accessing and possibly updating various data items in the database within its own business system.

[0039] A main transaction refers to a program execution unit that completes a certain business function.

[0040] A subtransaction is a program execution unit that completes a task, where a main transaction contains several subtransactions.

[0041] Transaction flow, including transaction or service call related serial number and input parameter information.

[0042] The main transaction flow includes but is not limited to: the status, creation time, and last update time of the main transaction.

[0043] For local transactions within a subtransaction, the subtransaction flow includes but is not limited to: the subtransaction call-related serial number, outgoing parameter information, and incoming parameter information.

[0044] For a subtransaction of the RPC (Remote Procedure Call) type in a subtransaction (ie, a subtransaction of a remote RPC call), the subtransaction sequence only includes the sequence number.

[0045] Figure 1 A flowchart of a distributed transaction processing method provided by an embodiment of the present disclosure.

[0046] The embodiment of the present disclosure uses the example of the distributed transaction processing method being configured in a distributed transaction processing device. The distributed transaction processing device can be applied to any electronic device with computing capabilities so that the electronic device can perform the distributed transaction processing function.

[0047] like Figure 1 As shown, the distributed transaction processing method includes the following steps S101 to S104:

[0048] Step S101 : in response to receiving a transaction request, determining a target business process corresponding to a transaction type of the transaction request.

[0049] In the disclosed embodiment, transaction requests include but are not limited to: transfer requests, payment requests, order requests, refund requests, query requests, authorization requests, etc.

[0050] In the disclosed embodiments, transaction types include but are not limited to: transfer transactions, payment transactions, loan approval transactions, recharge transactions, withdrawal transactions, frozen transactions, unfrozen transactions, order placement transactions, etc.

[0051] In an embodiment of the present disclosure, when a transaction request is received, the transaction type of the transaction request may be determined, and the business process corresponding to the transaction type (referred to as a target business process in the present disclosure) may be determined.

[0052] As an example, the correspondence between different transaction types and business processes can be pre-configured, so that in the present disclosure, the correspondence can be queried according to the transaction type of the transaction request to determine the target business process corresponding to the transaction type.

[0053] Step S102 : Based on the multiple target tasks that need to be executed by the target business process, a main transaction of the distributed transaction is opened for the transaction request, and the main transaction flow is registered in the local database.

[0054] In an embodiment of the present disclosure, multiple tasks required to be executed by a target business process (referred to as target tasks in the present disclosure) can be determined, and based on the multiple target tasks required to be executed by the target business process, a main transaction of a distributed transaction is opened for a transaction request, wherein the main transaction may include multiple ordered sub-transactions, each sub-transaction corresponding to a target task.

[0055] In an embodiment of the present disclosure, when a main transaction is started, a unique main transaction identifier (such as a main transaction ID (Identity)) can be generated for the main transaction, and based on the main transaction identifier, the main transaction flow can be registered in a local database.

[0056] In any embodiment of the present disclosure, Spring Aspect-Oriented Programming (Spring AOP) technology can be used to register the main transaction flow into the local database based on the main transaction identifier. In this way, relevant operations of inserting the flow table of the local database can be implemented without changing the business logic code, and without intruding the business logic code.

[0057] Step S103: traverse the multiple ordered sub-transactions in the main transaction in sequence, and process the currently traversed sub-transaction according to the result of determining whether the currently traversed sub-transaction is a local transaction.

[0058] In the embodiment of the present disclosure, multiple ordered sub-transactions in the main transaction can be traversed in sequence, and it can be determined whether the currently traversed sub-transaction is a local transaction to obtain a judgment result, so that the currently traversed sub-transaction can be processed based on the judgment result.

[0059] Step S104 , in response to multiple sub-transactions being successfully processed, the main transaction is terminated, and the status of the main transaction flow in the local database is updated to a completed status.

[0060] In the embodiment of the present disclosure, when multiple sub-transactions have been successfully processed, the main transaction can be ended, and the status of the main transaction flow in the local database is updated to a completed state (or a successful state).

[0061] In any embodiment of the present disclosure, the aspect-oriented programming (Spring AOP) technology may be used to update the status of the main transaction pipeline in the local database to a completed state based on the main transaction identifier.

[0062] The distributed transaction processing method of the disclosed embodiment combines the service flow required by the business with the main transaction flow of the distributed transaction when processing distributed transactions. Only the main transaction flow needs to be logged in the local database, which can reduce the number of flow registrations and improve performance. Furthermore, the management of distributed transactions is implemented based on a local flow registration system. For example, by registering the main transaction flow in the local database, compared to traditional methods of implementing transaction management through external services or remote service calls, this reduces the latency and complexity caused by network calls and provides better performance.

[0063] In order to clearly illustrate how the main transaction of a distributed transaction is opened for a transaction request based on multiple target tasks required to be executed by a target business process in the above embodiment, the present disclosure also proposes a method for processing distributed transactions.

[0064] Figure 2 A flowchart of another distributed transaction processing method provided by an embodiment of the present disclosure.

[0065] It should be noted that the distributed transaction processing method can be executed alone, or it can be executed in combination with any embodiment of the present disclosure or a possible implementation method in the embodiment, or it can be executed in combination with any technical solution in the related technology, and the embodiments of the present disclosure are not limited to this.

[0066] like Figure 2As shown, the distributed transaction processing method includes the following steps S201 to S206:

[0067] Step S201 : In response to receiving a transaction request, determining a target business process corresponding to a transaction type of the transaction request.

[0068] For explanation of step S201, please refer to the relevant description in any embodiment of the present disclosure, and will not be repeated here.

[0069] Step S202 : obtaining a plurality of target tasks required to be executed by the target business process and the corresponding execution order, as well as the forward API (Application Programming Interface) and reverse API defined for the target tasks.

[0070] The forward API is used to execute the forward operation (i.e., normal or expected operation) of the target task. This is the API called when each target task in the target business process moves forward. It is responsible for completing the business logic required for the target task, such as data processing and service calls. It should be noted that the successful execution or call of the forward API is a key step in advancing the target business process.

[0071] The reverse API is used to undo or rollback the forward operation of the target task, that is, to undo or rollback the business operations performed by the forward API. The purpose of the reverse API is to restore data and business status to the state before the forward API was executed. It is important to note that calling the reverse API becomes particularly important when the target business process needs to be interrupted due to errors, exceptions, user cancellation, or other reasons to ensure data consistency and the reliability of the target business process.

[0072] In any embodiment of the present disclosure, a parsing result obtained by parsing a business process definition file can be obtained, wherein the business process definition file is generated or produced in response to business modeling, and the parsing result includes execution tasks defined for multiple business processes, the execution order of execution tasks under each business process, and the forward API and reverse API defined for the execution tasks. In the present disclosure, the parsing result can be used to determine multiple target tasks required to be executed by the target business process (that is, the execution tasks defined for the target business process are taken as target tasks), the execution order of multiple target tasks, and the forward API and reverse API defined for the target tasks.

[0073] Step S203 : Based on the multiple target tasks and the corresponding execution order, forward API, and reverse API, a main transaction of the distributed transaction is opened for the transaction request.

[0074] The main transaction includes multiple ordered sub-transactions, each sub-transaction corresponds to a target task, and the order of sub-transactions is determined according to the execution order of the corresponding target tasks.

[0075] In an embodiment of the present disclosure, a main transaction of a distributed transaction may be opened for a transaction request based on multiple target tasks, the execution order of the multiple target tasks, and the forward APIs and reverse APIs of the multiple target tasks.

[0076] Step S204: register the main transaction flow into the local database.

[0077] Step S205 , traverse the multiple ordered sub-transactions in the main transaction in sequence, and process the currently traversed sub-transaction according to the result of determining whether the currently traversed sub-transaction is a local transaction.

[0078] Step S206 , in response to multiple sub-transactions being successfully processed, the main transaction is terminated, and the status of the main transaction flow in the local database is updated to a completed status.

[0079] For explanations of steps S204 to S206 , reference may be made to the relevant descriptions in any embodiment of the present disclosure, and no further details will be given here.

[0080] The distributed transaction processing method of the embodiment of the present disclosure is based on multiple target tasks, the execution order of multiple target tasks, and the forward APIs and reverse APIs of multiple target tasks. It opens the main transaction of the distributed transaction for the transaction request, which can improve the accuracy and reliability of distributed transaction processing.

[0081] In order to clearly illustrate how any embodiment of the present disclosure processes a currently traversed sub-transaction based on whether the currently traversed sub-transaction is a local transaction, the present disclosure also proposes a distributed transaction processing method.

[0082] Figure 3 A flowchart of another distributed transaction processing method provided by an embodiment of the present disclosure.

[0083] It should be noted that the distributed transaction processing method can be executed alone, or it can be executed in combination with any embodiment of the present disclosure or a possible implementation method in the embodiment, or it can be executed in combination with any technical solution in the related technology, and the embodiments of the present disclosure are not limited to this.

[0084] like Figure 3 As shown, the distributed transaction processing method includes the following steps S301 to S306:

[0085] Step S301 : In response to receiving a transaction request, determining a target business process corresponding to a transaction type of the transaction request.

[0086] Step S302 : Based on the multiple target tasks that need to be executed by the target business process, a main transaction of the distributed transaction is opened for the transaction request, and the main transaction flow is registered in the local database.

[0087] The main transaction includes multiple ordered sub-transactions, and each sub-transaction corresponds to a target task.

[0088] Step S303: traverse multiple ordered sub-transactions in the main transaction in sequence.

[0089] Step S304: determine whether the currently traversed sub-transaction is a local transaction and obtain a determination result.

[0090] For explanations of steps S301 to S304 , reference may be made to the relevant descriptions in any embodiment of the present disclosure, and no further details will be given here.

[0091] Step S305 : Process the currently traversed sub-transaction according to the judgment result and the forward API and reverse API of the target task corresponding to the currently traversed sub-transaction.

[0092] In any embodiment of the present disclosure, when the judgment result indicates that the currently traversed subtransaction is a local transaction, the currently traversed subtransaction can be opened, and a subtransaction identifier (such as a subtransaction ID) can be generated for the currently traversed subtransaction. Afterwards, the forward API of the target task corresponding to the currently traversed subtransaction can be called to execute the forward operation of the target task corresponding to the currently traversed subtransaction to complete the processing of the currently traversed subtransaction. Then, it can be determined whether the currently traversed subtransaction is successfully processed. If the currently traversed subtransaction is successfully processed, the currently traversed subtransaction flow can be registered in the local memory based on the subtransaction identifier.

[0093] The sub-transaction flow includes the flow number, outgoing parameter information, and incoming parameter information related to the currently traversed sub-transaction call.

[0094] Therefore, the management of distributed transactions is implemented based on the local transaction flow registration system. For example, the main transaction flow is registered in the local database and the local transaction flow in the sub-transaction is registered in the local memory. Compared with the traditional external service or remote call service to implement transaction management, it reduces the delay and complexity caused by network calls and has better performance.

[0095] In any embodiment of the present disclosure, if the currently traversed sub-transaction fails, the reverse API of the target task corresponding to the currently traversed sub-transaction can be further called to cancel or rollback the forward operation of the target task and update the status of the main transaction flow in the local database to a failed state. This ensures the integrity, consistency, and reliability of the target business process.

[0096] In any embodiment of the present disclosure, when the judgment result indicates that the currently traversed subtransaction is not a local transaction, for example, when the currently traversed subtransaction is an RPC-type subtransaction (i.e., a subtransaction of a remote RPC call), the uncommitted and successfully processed local transaction can be committed, and the subtransaction streams in the local memory can be merged. Thereafter, the merged subtransaction streams can be registered in the local database, and the currently traversed subtransaction stream can be registered in the local database, wherein the subtransaction stream only includes the stream number, and the forward API of the target task corresponding to the currently traversed subtransaction is called through a remote call method to execute the forward operation of the target task corresponding to the currently traversed subtransaction, so as to complete the processing of the currently traversed subtransaction.

[0097] Therefore, when the currently traversed sub-transaction is not a local transaction, the previously traversed and adjacent local sub-transactions (including transaction registration) are automatically merged and submitted, which can reduce the number of times transactions are opened and submitted, and improve the performance of microservices.

[0098] Step S306 , in response to multiple sub-transactions being successfully processed, the main transaction is terminated, and the status of the main transaction flow in the local database is updated to a completed status.

[0099] For explanation of step S306, please refer to the relevant description in any embodiment of the present disclosure, and will not be repeated here.

[0100] The distributed transaction processing method of the embodiment of the present disclosure performs targeted processing on the currently traversed sub-transaction based on the judgment result of whether the currently traversed sub-transaction is a local transaction, and based on the forward API and reverse API of the target task corresponding to the currently traversed sub-transaction, thereby improving the accuracy and reliability of transaction processing.

[0101] In order to clearly illustrate any of the above embodiments of the present disclosure, the present disclosure also provides a method for processing distributed transactions.

[0102] Figure 4 A flowchart of another distributed transaction processing method provided by an embodiment of the present disclosure.

[0103] It should be noted that the distributed transaction processing method can be executed alone, or it can be executed in combination with any embodiment of the present disclosure or a possible implementation method in the embodiment, or it can be executed in combination with any technical solution in the related technology, and the embodiments of the present disclosure are not limited to this.

[0104] like Figure 4 As shown, the distributed transaction processing method includes the following steps S401 to S406:

[0105] Step S401 : In response to receiving a transaction request, determining a target business process corresponding to a transaction type of the transaction request.

[0106] Step S402 : Based on the multiple target tasks that need to be executed by the target business process, a main transaction of the distributed transaction is opened for the transaction request, and the main transaction flow is registered in the local database.

[0107] The main transaction includes multiple ordered sub-transactions, and each sub-transaction corresponds to a target task.

[0108] Step S403: traverse the multiple ordered sub-transactions in the main transaction in sequence, and process the currently traversed sub-transaction according to the result of determining whether the currently traversed sub-transaction is a local transaction.

[0109] For explanations of steps S401 to S403 , reference may be made to the relevant descriptions in any embodiment of the present disclosure, and no further details will be given here.

[0110] In any one of the embodiments of the present disclosure, the distributed transaction processing method provided in any one of the embodiments of the present disclosure can be executed by a distributed transaction processing component, which is encapsulated with an SDK. In the present disclosure, the distributed transaction processing method proposed in any one of the embodiments of the present disclosure can be executed based on the algorithm logic encapsulated in the SDK.

[0111] As a result, distributed transaction processing logic is encapsulated within the SDK, eliminating the need to implement distributed transaction processing separately within the business logic code. This approach allows developers to orchestrate business processes directly through visual tools without having to deeply understand the complex implementation of SAGA. The SDK then automatically orchestrates distributed transactions. This eliminates the need for developers to write dedicated code, improving development efficiency and code quality while significantly reducing the difficulty of developing distributed microservices.

[0112] Step S404: When the last sub-transaction in the multiple ordered sub-transactions is successfully processed, it is determined that the target business process is completed.

[0113] It should be noted that if a non-final subtransaction in multiple ordered subtransactions fails, the reverse API of the target task corresponding to the failed subtransaction will be called to undo or rollback the forward operation of the target task, and the status of the main transaction flow will be updated to a failed state. At this point, subsequent subtransactions will not be processed. Therefore, when the last subtransaction in multiple ordered subtransactions succeeds, it indicates that all subtransactions have been successfully processed, and the target business process can be determined to have completed execution.

[0114] Step S405: Commit the currently opened local transaction.

[0115] In the embodiment of the present disclosure, when it is determined that the execution of the target business process is completed, the currently opened local transaction (ie, the local sub-transaction in the multiple sub-transactions) may be committed.

[0116] Step S406: Update the status of the main transaction flow in the local database to a completed status.

[0117] In any embodiment of the present disclosure, the aspect-oriented programming (Spring AOP) technology may be used to update the status of the main transaction pipeline in the local database to a completed state based on the main transaction identifier.

[0118] In summary, by using aspect-oriented programming (Spring AOP) technology, it is possible to insert related operations into the local database flow table without changing the business logic code. At the same time, it is possible to automatically add transaction control logic before and after the execution of business methods, such as starting transactions, committing or rolling back transactions, without intruding on the business logic code.

[0119] In any one of the embodiments of the present disclosure, the present disclosure proposes a method for processing distributed transactions combined with business modeling, and a process engine device for efficiently processing distributed transactions, wherein the process engine device reads and parses the business process definition file generated in the business modeling stage, and automatically completes the distributed transactions of the business process based on the distributed transaction processing components within the process engine device, thereby ensuring the correctness of accounting processing.

[0120] As an example, the specific implementation principle of the distributed transaction processing method can be as follows Figure 5 As shown, it mainly includes the following steps:

[0121] Step 1: Read and parse the business process definition file.

[0122] Through business modeling, a business process definition is generated, which consists of several tasks. Two APIs are designed corresponding to each task in the business process definition, namely the forward API and the reverse API. These APIs are orchestrated in a specific business process. Each execution node or task in the business process contains a pair of forward APIs and reverse APIs. In this step, the business process definition file will be obtained and parsed.

[0123] The second step is to start the main transaction.

[0124] In this step, the main transaction of the distributed transaction is started, a unique main transaction ID is generated, and the main transaction (service) flow is registered in the local database.

[0125] Step 3: Execute the sub-transaction.

[0126] The process engine automatically traverses multiple subtransactions within the main transaction and determines whether the currently traversed subtransaction is a local transaction. If so, it automatically opens the currently traversed subtransaction, generates a unique subtransaction ID, and calls the forward API of the task corresponding to the currently traversed subtransaction to complete the processing of the currently traversed subtransaction. After completing the local subtransaction-related processing, the currently traversed subtransaction transaction flow is registered in the memory of the local flow registration system.

[0127] If it is not a local transaction, the previously uncommitted local transaction will be committed. At the same time, the sub-transaction flows in the memory will be merged and registered in the local database. Then, the currently traversed sub-transaction flow (including only the flow number) will be generated and registered in the local database, and the remote service will be called to complete the processing of the currently traversed sub-transaction.

[0128] If there are unprocessed sub-transactions after the currently traversed sub-transaction, that is, there are subsequent unprocessed tasks, repeat this step; if there are no unprocessed subsequent tasks, execute step 4.

[0129] Step 4: End the main transaction.

[0130] At the end of the business process, the currently opened local transaction is committed, and the status of the main transaction (service) flow is updated to the completed state in the local database.

[0131] Among them, the process engine device can be implemented by using aspect-oriented programming (Spring AOP), which can insert relevant operations of the local database flow table without changing the business logic code. At the same time, it can automatically add transaction control logic before and after the execution of the business method, such as starting a transaction, committing or rolling back a transaction, etc., without intruding into the business logic code.

[0132] In summary, the distributed transaction processing method provided by the present disclosure includes at least the following features:

[0133] 1. Distributed transaction processing logic is encapsulated in the SDK, eliminating the need to implement distributed transaction processing separately in business logic code. This approach allows developers to orchestrate business processes directly through visual tools without having to deeply understand the complex implementation of SAGA. The SDK then automatically orchestrates distributed transactions. This eliminates the need for developers to write dedicated code, improving development efficiency and code quality, and significantly reducing the difficulty of developing distributed microservices.

[0134] 2. When processing distributed transactions, the service flow required by the business is combined with the main transaction flow of the distributed transaction. Only the main transaction flow needs to be logged in the local database, which reduces the number of flow registrations and improves performance. Distributed transactions are also managed based on the local flow registration system. Compared to traditional transaction management methods using external services or remote service calls, this reduces the latency and complexity of network calls and provides better performance.

[0135] 3. Automatically merge adjacent local sub-transactions (including journal entries) to reduce the number of times transactions are opened and submitted, thus improving performance.

[0136] The above design method and implementation allow developers to focus on business logic development while ensuring the correctness and efficiency of distributed transactions. This greatly reduces the difficulty and entry threshold of distributed microservice development and helps enterprises transform their distributed architecture.

[0137] In order to implement the above embodiments, the present disclosure also provides a distributed transaction processing device.

[0138] Figure 6 A schematic diagram of the structure of a distributed transaction processing device provided in an embodiment of the present disclosure.

[0139] like Figure 6 As shown, the distributed transaction processing device 600 includes: a determination module 610, a registration start module 620, a traversal processing module 630 and an update end module 640.

[0140] The determination module 610 is configured to determine, in response to receiving a transaction request, a target business process corresponding to the transaction type of the transaction request;

[0141] The registration module 620 is configured to start a distributed transaction master transaction for the transaction request based on multiple target tasks required to be executed by the target business process, and register the master transaction flow in the local database; wherein the master transaction includes multiple ordered sub-transactions, each of which corresponds to a target task;

[0142] The traversal processing module 630 is used to sequentially traverse multiple ordered sub-transactions and process the currently traversed sub-transaction based on the result of determining whether the currently traversed sub-transaction is a local transaction;

[0143] The end update module 640 is configured to end the main transaction in response to multiple sub-transactions being successfully processed, and update the status of the main transaction pipeline in the local database to a completed status.

[0144] In a possible implementation of the embodiment of the present disclosure, a registration module 620 is started, specifically used to: obtain multiple target tasks required to be executed by the target business process and the corresponding execution order, as well as the forward application program interface API and reverse API defined for the target tasks; wherein the forward API is used to execute the forward operation of the target task, and the reverse API is used to cancel or roll back the forward operation of the target task; based on the multiple target tasks and the corresponding execution order, the forward API and the reverse API, a main transaction of the distributed transaction is started for the transaction request; wherein the main transaction includes multiple ordered sub-transactions, each sub-transaction corresponds to a target task, and the arrangement order of the sub-transactions is determined according to the execution order of the corresponding target tasks.

[0145] In a possible implementation of the embodiment of the present disclosure, the registration module 620 is turned on, specifically for: obtaining the parsing results obtained by parsing the business process definition file; wherein the business process definition file is generated in response to business modeling, and the parsing results include execution tasks defined for multiple business processes, the execution order of execution tasks under each business process, and the forward API and reverse API defined for the execution tasks; from the parsing results, determine the multiple target tasks required to be executed by the target business process, the execution order of the multiple target tasks, and the forward API and reverse API defined for the target tasks.

[0146] In a possible implementation of the embodiment of the present disclosure, the traversal processing module 630 is specifically used to: traverse multiple ordered sub-transactions in sequence; determine whether the currently traversed sub-transaction is a local transaction and obtain a determination result; and process the currently traversed sub-transaction based on the determination result and the forward API and reverse API of the target task corresponding to the currently traversed sub-transaction.

[0147] In a possible implementation of the embodiment of the present disclosure, the traversal processing module 630 is specifically used to: when a judgment result indicates that the currently traversed subtransaction is a local transaction, start the currently traversed subtransaction and generate a subtransaction identifier for the currently traversed subtransaction; call the forward API of the target task corresponding to the currently traversed subtransaction, execute the forward operation of the target task corresponding to the currently traversed subtransaction, so as to complete the processing of the currently traversed subtransaction; when the currently traversed subtransaction is successfully processed, register the currently traversed subtransaction flow in the local memory based on the subtransaction identifier; wherein the subtransaction flow includes a flow number, output parameter information, and input parameter information.

[0148] In a possible implementation of the embodiment of the present disclosure, the distributed transaction processing device 600 further includes:

[0149] The update module is called to call the reverse API of the target task corresponding to the currently traversed sub-transaction when the processing fails, to cancel or roll back the forward operation of the target task; and to update the status of the main transaction flow in the local database to a failed status.

[0150] In a possible implementation of the embodiment of the present disclosure, the traversal processing module 630 is specifically configured to: commit an uncommitted and successfully processed local transaction when a judgment result indicates that the currently traversed subtransaction is not a local transaction; merge the subtransaction flows in the local memory and register the merged subtransaction flows in the local database; register the currently traversed subtransaction flow in the local database; wherein the subtransaction flow includes a flow number; and call the forward API of the target task corresponding to the currently traversed subtransaction through a remote call method, and execute the forward operation of the target task corresponding to the currently traversed subtransaction to complete the processing of the currently traversed subtransaction.

[0151] In a possible implementation of the embodiment of the present disclosure, the end update module 640 is specifically used to: determine the end of execution of the target business process when the last sub-transaction in multiple ordered sub-transactions is successfully processed; commit the currently opened local transaction; and update the status of the main transaction flow in the local database to a completed state.

[0152] In a possible implementation of the embodiment of the present disclosure, the registration module 620 is enabled, specifically configured to: generate a main transaction identifier corresponding to the main transaction; and register the main transaction flow into the local database based on the main transaction identifier.

[0153] In a possible implementation of the embodiment of the present disclosure, the end update module 640 is specifically configured to update the status of the main transaction pipeline in the local database to a completed status based on the main transaction identifier.

[0154] In a possible implementation of the embodiment of the present disclosure, the distributed transaction processing device 600 is applied to a distributed transaction processing component, which is encapsulated with an SDK and executes the steps executed by any of the above modules based on the algorithm logic encapsulated in the SDK.

[0155] It should be noted that the distributed transaction processing device provided by the embodiment of the present disclosure can achieve the above Figures 1 to 5 All the method steps implemented in the method embodiment can achieve the same technical effects, and the parts and beneficial effects of this embodiment that are the same as those in the method embodiment will not be described in detail here.

[0156] In order to implement the above embodiments, the present disclosure also proposes an electronic device, wherein the electronic device can be any device with computing capabilities, and the electronic device includes: a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, it implements the distributed transaction processing method proposed in any of the aforementioned embodiments of the present disclosure.

[0157] As an example, Figure 7 is a structural diagram of an electronic device 700 shown in an exemplary embodiment of the present disclosure, such as Figure 7 As shown, the electronic device 700 may further include:

[0158] The memory 710 and the processor 720, and the bus 730 connecting different components (including the memory 710 and the processor 720), the memory 710 stores a computer program, and when the processor 720 executes the program, the distributed transaction processing method described in the embodiment of the present disclosure is implemented.

[0159] Bus 730 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0160] The electronic device 700 typically includes a variety of electronic device-readable media, which can be any available media that can be accessed by the electronic device 700, including volatile and non-volatile media, removable and non-removable media.

[0161] The memory 710 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 740 and / or cache memory 750. The server 700 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 760 may be used to read and write non-removable, non-volatile magnetic media ( Figure 7 Not shown, often called a "hard drive"). Although Figure 7Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 730 via one or more data medium interfaces. Memory 710 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the present disclosure.

[0162] A program / utility 780 having a set (at least one) of program modules 770 may be stored, for example, in memory 710. Such program modules 770 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may include an implementation of a network environment. Program modules 770 generally implement the functions and / or methods of the embodiments described herein.

[0163] The electronic device 700 can also communicate with one or more external devices 790 (e.g., a keyboard, a pointing device, a display 791, etc.), one or more devices that enable a user to interact with the electronic device 700, and / or any device that enables the electronic device 700 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication can occur via an input / output (I / O) interface 792. Furthermore, the electronic device 700 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 793. As shown, the network adapter 793 communicates with other modules of the electronic device 700 via a bus 730. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 700, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0164] The processor 720 executes various functional applications and data processing by running programs stored in the memory 710 .

[0165] It should be noted that the implementation process and technical principles of the electronic device of this embodiment can be found in the aforementioned explanation of the distributed transaction processing method of the embodiment of the present disclosure, and will not be repeated here.

[0166] In order to implement the above embodiments, the present disclosure further proposes a non-temporary computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it implements the distributed transaction processing method proposed in any of the above embodiments of the present disclosure.

[0167] In order to implement the above embodiments, the present disclosure further proposes a computer program product. When the instructions in the computer program product are executed by a processor, the distributed transaction processing method proposed in any of the above embodiments of the present disclosure is executed.

[0168] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and features of different embodiments or examples, unless they are mutually inconsistent.

[0169] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the present disclosure, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0170] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present disclosure includes additional implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present disclosure belong.

[0171] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0172] It should be understood that various parts of the present disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used to implement: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0173] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0174] In addition, the functional units in the various embodiments of the present disclosure may be integrated into a single processing module, or each unit may exist physically separately, or two or more units may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or in the form of software functional modules. If the integrated modules are implemented in the form of software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium.

[0175] The storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although the embodiments of the present disclosure have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. A person of ordinary skill in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A method for processing distributed transactions, characterized in that: The method is executed by a distributed transaction processing component, which is encapsulated with a software development kit (SDK). Based on the algorithm logic encapsulated in the SDK, the following steps are executed: In response to receiving a transaction request, determining a target business process corresponding to a transaction type of the transaction request; Based on the multiple target tasks required to be executed by the target business process, a master transaction of a distributed transaction is opened for the transaction request; wherein the management of the distributed transaction is implemented based on a local journal registration system; Merging the service flow required by the target business process with the main transaction flow, and using aspect-oriented programming technology to register only the main transaction flow in a local database; wherein the main transaction includes multiple ordered sub-transactions, each sub-transaction corresponding to a target task; Traversing the multiple ordered sub-transactions in sequence, and processing the currently traversed sub-transaction according to a determination result of whether the currently traversed sub-transaction is a local transaction; In response to the multiple sub-transactions being successfully processed, the main transaction is terminated, and the state of the main transaction pipeline in the local database is updated to a completed state using the aspect-oriented programming technology.

2. The method according to claim 1, characterized in that The multiple target tasks required to be executed based on the target business process are used to open a main transaction of a distributed transaction for the transaction request, including: Obtain multiple target tasks required to be executed by the target business process and the corresponding execution order, as well as the forward application programming interface (API) and reverse application programming interface (API) defined for the target tasks; wherein the forward API is used to execute the forward operation of the target task, and the reverse API is used to cancel or roll back the forward operation of the target task; Based on the multiple target tasks and the corresponding execution order, forward API, and reverse API, a master transaction of the distributed transaction is opened for the transaction request; The main transaction includes a plurality of ordered sub-transactions, each sub-transaction corresponds to a target task, and the arrangement order of the sub-transactions is determined according to the execution order of the corresponding target tasks.

3. The method according to claim 2, characterized in that The acquisition of multiple target tasks required to be executed by the target business process and the corresponding execution order, as well as the forward API and reverse API defined for the target tasks, includes: Obtaining a parsing result obtained by parsing a business process definition file, wherein the business process definition file is generated in response to business modeling, and the parsing result includes execution tasks defined for multiple business processes, an execution order for each execution task under the business process, and a forward API and a reverse API defined for the execution task; From the parsing result, a plurality of target tasks required to be executed by the target business process, an execution order of the plurality of target tasks, and forward APIs and reverse APIs defined for the target tasks are determined.

4. The method according to claim 2, characterized in that The sequentially traversing the plurality of ordered subtransactions and processing the currently traversed subtransaction according to a result of determining whether the currently traversed subtransaction is a local transaction includes: Traversing the multiple ordered sub-transactions in sequence; Determine whether the currently traversed subtransaction is a local transaction, and obtain the determination result; The currently traversed sub-transaction is processed according to the judgment result and the forward API and reverse API of the target task corresponding to the currently traversed sub-transaction.

5. The method according to claim 4, characterized in that The processing of the currently traversed sub-transaction according to the judgment result and the forward API and the reverse API of the target task corresponding to the currently traversed sub-transaction includes: If the judgment result indicates that the currently traversed subtransaction is a local transaction, starting the currently traversed subtransaction and generating a subtransaction identifier for the currently traversed subtransaction; Calling the forward API of the target task corresponding to the currently traversed sub-transaction, executing the forward operation of the target task corresponding to the currently traversed sub-transaction, to complete the processing of the currently traversed sub-transaction; In the case that the currently traversed sub-transaction is successfully processed, the currently traversed sub-transaction flow is registered in the local memory based on the sub-transaction identifier; wherein the sub-transaction flow includes a flow number, output parameter information, and input parameter information.

6. The method according to claim 5, characterized in that The distributed transaction processing component further performs the following steps based on the algorithm logic encapsulated in the SDK: If the currently traversed sub-transaction fails to process, calling the reverse API of the target task corresponding to the currently traversed sub-transaction to cancel or roll back the forward operation of the target task; The status of the main transaction flow in the local database is updated to a failed status.

7. The method according to claim 4, characterized in that The processing of the currently traversed sub-transaction according to the judgment result and the forward API and the reverse API of the target task corresponding to the currently traversed sub-transaction includes: If the judgment result indicates that the currently traversed sub-transaction is not a local transaction, committing the uncommitted and successfully processed local transaction; Merging the sub-transaction flows in the local memory and registering the merged sub-transaction flows in the local database; Registering the currently traversed sub-transaction flow into the local database; wherein the sub-transaction flow includes a flow number; By remote calling, the forward API of the target task corresponding to the currently traversed sub-transaction is called, and the forward operation of the target task corresponding to the currently traversed sub-transaction is executed to complete the processing of the currently traversed sub-transaction.

8. The method according to claim 1, characterized in that In response to the multiple sub-transactions being successfully processed, ending the main transaction and updating the status of the main transaction pipeline in the local database to a completed state using the aspect-oriented programming technology include: If the last sub-transaction in the multiple ordered sub-transactions is successfully processed, determining that the target business process is completed; Commit the currently opened local transaction; The aspect-oriented programming technology is used to update the status of the main transaction pipeline in the local database to a completed state.

9. The method according to claim 1, characterized in that The aspect-oriented programming technology is used to register the main transaction flow only in the local database, including: Generate a main transaction identifier corresponding to the main transaction; Using aspect-oriented programming technology, based on the main transaction identifier, register the main transaction flow into the local database; The adopting of the aspect-oriented programming technology to update the status of the main transaction pipeline in the local database to a completed state includes: The aspect-oriented programming technology is adopted and based on the main transaction identifier, the status of the main transaction pipeline in the local database is updated to a completed state.

Images