A distributed transaction scheduling method, electronic equipment and storage medium

Abstract

The application provides a distributed transaction scheduling method, an electronic device and a storage medium, comprising: a first application program executing a first stage main transaction of a target aggregation service to sequentially send a first call request to each second application program in a predetermined order; each second application program executing a corresponding first stage sub-transaction in response to the received first call request, generating first stage sub-transaction execution data, and feeding back an execution result to the first application program; the first application program executing a second stage main transaction of the target aggregation service according to the received execution result to determine a first target second application program according to a second stage call strategy and send a second call request, and then mutual calling between the application programs to which each sub-transaction belongs. In this way, single-point blocking can be avoided, scheduling efficiency can be improved, single-node pressure can be reduced, the failure of a single scheduling node can be avoided to cause the entire system to be down, and the overall stability of the system can be improved.

Description

Technical Field

[0001] This application relates to the field of distributed technology, and in particular to a distributed transaction scheduling method, electronic device, and storage medium. Background Technology

[0002] Distributed system architecture has now become widespread across industries. With the shift from monolithic to distributed architecture, transactions have evolved from traditional local transactions to supporting distributed architectures. In a distributed system, an operation requires the collaboration of multiple services; such transactions, completed through network collaboration between different services, are called distributed transactions.

[0003] Currently, distributed transactions use a centralized scheduling model. This scheduling model faces the risk of single point of failure. At the same time, as the scale of the business system increases, a single scheduling node cannot handle too many requests, resulting in poor system scalability and low efficiency. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a distributed transaction scheduling method, electronic device and storage medium to solve the problems of high single point of failure risk and low implementation efficiency in the existing centralized scheduling mode.

[0005] This application provides a distributed transaction scheduling method applied to a distributed transaction system. The distributed transaction system includes a first application and multiple second applications. The first application provides a target aggregation service. Each second application provides an atomic service or other aggregation service. The target aggregation service is obtained by arranging the services provided by the multiple second applications in a predetermined order. The service provided by each second application is set as a sub-transaction of that second application. The target aggregation service provided by the first application is set as the main transaction. The method includes:

[0006] The first application executes the first phase of the main transaction of the target aggregation service to send first call requests to each second application in the predetermined order; wherein, the first phase of the main transaction is the initiation of the main transaction;

[0007] Each second application, in response to the received first call request, executes the corresponding first-stage sub-transaction, generates first-stage sub-transaction execution data, stores the first-stage sub-transaction execution data in the database, and feeds back the execution result to the first application;

[0008] The first application executes the second-phase main transaction of the target aggregation service based on the received execution result, in order to determine the first target second application and send a second invocation request according to the second-phase invocation strategy; wherein, the second-phase main transaction includes committing the main transaction and rolling back the main transaction;

[0009] The first target second application responds to the received second call request, executes the corresponding second-stage sub-transaction, and determines the next target second application based on the first-stage sub-transaction execution data stored in the database;

[0010] The first target second application sends a second call request to the next target second application, so that the next target second application executes the corresponding second-stage sub-transaction and continues to call other target second applications until each target second application is called in sequence.

[0011] Furthermore, the data items in the first-stage sub-transaction execution data generated by each second application include a transaction ID item, a source transaction location information item, a current transaction location information item, a transaction behavior item, and a transaction behavior status item; each second application, in response to the received first call request, executes the corresponding first-stage sub-transaction and generates first-stage sub-transaction execution data, including:

[0012] For any second application, the second application determines the data value of the source transaction location information item based on the main transaction location information and the previous transaction location information included in the request header of the received first call request;

[0013] The second application executes the corresponding first-stage sub-transaction to generate a sub-transaction ID, generates the data value of the current transaction location information item according to the association between the sub-transaction and the main transaction and the sub-transaction ID, sets the data value of the transaction behavior item to start behavior, and sets the data value of the transaction behavior status item to in progress.

[0014] The second application performs business operations related to startup, and sets the data value of the transaction behavior status item to "completed" after the business operation is successfully executed, otherwise it is set to "terminated".

[0015] Furthermore, when the second phase main transaction is a commit main transaction, each second application is the target second application;

[0016] When the second phase main transaction is a rollback main transaction, each second application that has executed the corresponding first phase sub-transaction is the target second application;

[0017] When the second phase invocation strategy is a forward invocation, the first target second application is the first target second application to execute the corresponding first phase sub-transaction; when the second phase invocation strategy is a reverse invocation, the first target second application is the last target second application to execute the corresponding first phase sub-transaction.

[0018] Furthermore, when the second-stage invocation strategy is a forward invocation, the first target second application determines the next target second application based on the first-stage sub-transaction execution data stored in the database, including:

[0019] The first target second application uses its own sub-transaction location information as the query condition for the source transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the current transaction location information item in the queried first-stage sub-transaction execution data;

[0020] The first target second application determines the second application corresponding to the data value of the current transaction location information item as the next target second application.

[0021] Furthermore, when the second-stage invocation strategy is a reverse invocation, the first target second application determines the next target second application based on the first-stage sub-transaction execution data stored in the database, including:

[0022] The first target second application uses its own sub-transaction location information as the query condition for the current transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the source transaction location information item in the queried first-stage sub-transaction execution data;

[0023] The first target second application determines the second application corresponding to the data value of the source transaction location information item as the next target second application.

[0024] Furthermore, the next target, the second application, executes the corresponding second-phase sub-transaction, including:

[0025] The next target second application determines other target second applications that have a direct calling relationship with the target second application according to the second-stage calling strategy by querying the first-stage sub-transaction execution data stored in the database.

[0026] After receiving a second call request from each other target second application, the corresponding second-phase sub-transaction is executed.

[0027] Furthermore, the first application executes the first phase of the main transaction of the target aggregation service to send first invocation requests to each second application in the predetermined order, including:

[0028] The first application executes the first phase of the main transaction of the target aggregation service, and sequentially sends a first call request to each of the second applications in the predetermined order;

[0029] Specifically, after the first application sends a first call request to any of the second applications...

[0030] If the received execution result indicates that the second application has successfully executed the corresponding first-stage sub-transaction, then the first application continues to send the first call request to the next second application in the predetermined sequence.

[0031] If the received execution result indicates that the first second application failed to execute the corresponding first-phase sub-transaction, then the first application stops sending the first call request and ends the first-phase main transaction.

[0032] Furthermore, based on the received execution result, the first application executes the second phase of the main transaction of the target aggregation service, including:

[0033] When the received execution result indicates that the first-stage sub-transaction of each second application has been successfully executed, the commit main transaction of the target aggregation service is executed.

[0034] When the received execution result is that the first-stage sub-transaction of any second application fails, the rollback main transaction of the target aggregation service is executed.

[0035] Furthermore, the distributed transaction system further includes: a transaction management terminal; the method further includes:

[0036] The transaction management terminal determines the execution order of the second-stage sub-transactions based on the first-stage sub-transaction execution data and the second-stage invocation strategy stored in the database.

[0037] Each target second application will execute the second-stage sub-transaction execution data generated by the second-stage sub-transaction and store it into the database in real time;

[0038] The transaction management terminal determines the execution progress of the second-stage main transaction by comparing the execution order of the second-stage sub-transactions with the execution data of the second-stage sub-transactions stored in the database in real time, and displays the execution progress of the second-stage main transaction in a visual form.

[0039] This application also provides a distributed transaction system, including a first application and multiple second applications; the first application is used to provide a target aggregation service; each second application is used to provide an atomic service or other aggregation service; the target aggregation service is obtained by arranging the services provided by the multiple second applications in a predetermined order; the service provided by each second application is set as a sub-transaction of that second application; the target aggregation service provided by the first application is set as the main transaction;

[0040] The first application is configured to execute the first phase main transaction of the target aggregation service, in order to send a first call request to each second application in the predetermined order; wherein, the first phase main transaction is the initiation of the main transaction;

[0041] Each second application is used to respond to the received first call request, execute the corresponding first-stage sub-transaction, generate first-stage sub-transaction execution data, store the first-stage sub-transaction execution data in the database, and feed back the execution result to the first application;

[0042] The first application is configured to execute the second-phase main transaction of the target aggregation service based on the received execution result, so as to determine the first target second application and send a second invocation request according to the second-phase invocation strategy; wherein, the second-phase main transaction includes committing the main transaction and rolling back the main transaction;

[0043] The first target second application is used to respond to the received second call request, execute the corresponding second phase sub-transaction, and determine the next target second application based on the first phase sub-transaction execution data stored in the database;

[0044] The first target second application is used to send a second call request to the next target second application, so that the next target second application executes the corresponding second-stage sub-transaction and continues to call other target second applications until each target second application is called in sequence.

[0045] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the distributed transaction scheduling method described above are performed.

[0046] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the distributed transaction scheduling method described above.

[0047] This application provides a distributed transaction scheduling method, electronic device, and storage medium. During the second phase of the main transaction of the target aggregation service, applications belonging to sub-transactions call each other. This distributes the tasks of a single scheduling node in a centralized scheduling model to various nodes for execution, thereby avoiding single-point blocking, improving scheduling efficiency, reducing the pressure on individual nodes, preventing system downtime due to the failure of a single scheduling node, and improving overall system stability.

[0048] Furthermore, this application embodiment designs a data structure for the application to generate the execution data of the first-stage sub-transaction, and stores the data in the database during the execution of the first-stage main transaction, so that the second application can automatically clarify the calling relationship by querying the execution data of the first-stage start transaction during the execution of the second-stage main transaction; and supports two second-stage calling strategies, forward calling and reverse calling, which can adapt to more business scenarios.

[0049] In addition, the distributed transaction system may also include a transaction management terminal. By using the execution data of the second-stage sub-transactions stored in the database, the transaction management terminal can efficiently calculate the real-time execution progress of the second-stage main transaction and display it in a visual form.

[0050] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 A flowchart of a distributed transaction scheduling method provided in an embodiment of this application is shown;

[0053] Figure 2 This illustration shows one of the schematic diagrams of a distributed transaction scheduling process provided in an embodiment of this application;

[0054] Figure 3 This illustration shows a second schematic diagram of a distributed transaction scheduling process provided in an embodiment of this application;

[0055] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0057] Research has shown that distributed system architecture has become widespread across industries. With the shift from monolithic to distributed architectures, transactions have evolved from traditional local transactions to supporting distributed architectures. In a distributed system, an operation requires the collaboration of multiple services; such transactions, completed through network collaboration between different services, are called distributed transactions.

[0058] Currently, existing distributed transactions use a centralized scheduling model. This scheduling model faces the risk of single point of failure. At the same time, as the scale of the business system increases, a single scheduling node cannot handle too many requests, resulting in poor system scalability and low efficiency.

[0059] Based on this, embodiments of this application provide a distributed transaction scheduling method, electronic device, and storage medium to avoid single-point blocking, improve scheduling efficiency, reduce pressure on individual nodes, and improve overall system stability.

[0060] Please see Figure 1 , Figure 1 This is a flowchart illustrating a distributed transaction scheduling method provided in an embodiment of this application. The method provided in this embodiment is applied to a distributed transaction system; the distributed transaction system includes a first application and multiple second applications; the first application provides a target aggregation service; each second application provides an atomic service or other aggregation service; the target aggregation service is obtained by arranging the services provided by the multiple second applications in a predetermined order; therefore, in this embodiment, the target aggregation service can be obtained by arranging multiple atomic services, multiple other aggregation services, or a mixture of atomic services and other aggregation services. The service provided by each second application is set as a sub-transaction of that second application; the target aggregation service provided by the first application is set as the main transaction of the first application.

[0061] In one example, see Figure 2 , Figure 2 This is one of the schematic diagrams of a distributed transaction scheduling process provided in an embodiment of this application. Application APP2 provides atomic service B to the outside world, and application APP3 provides atomic service C to the outside world. Application APP1 weaves atomic service B and atomic service C into target aggregate service A, and sets target aggregate service A as the main transaction of APP1. Atomic service B and atomic service C are set as sub-transactions of APP2 and APP3, respectively.

[0062] like Figure 1 As shown, the method includes:

[0063] S101, the first application executes the first phase of the main transaction of the target aggregation service to send first call requests to each second application in the predetermined order.

[0064] S102. In response to the received first call request, each second application executes the corresponding first-stage sub-transaction, generates first-stage sub-transaction execution data, stores the first-stage sub-transaction execution data in the database, and feeds back the execution result to the first application.

[0065] Here, the first application can expose the service interface of the target aggregation service to the outside world. After receiving the call request for the target aggregation service through the service interface, it provides the target aggregation service to the outside world through a two-phase transaction operation.

[0066] Regarding step S101, in the first stage, namely the transaction begin stage, the first stage main transaction is also the start main transaction. At this time, the first application executes the start main transaction of the target aggregation service and sends the first call request to each of the second applications in the predetermined order.

[0067] Here, the request header of any first call request includes main transaction location information and previous transaction location information. The previous transaction location information indicates the location of the second application that executed the corresponding sub-transaction before the first call request was sent to the second application. Thus, when the second application receives the first call request, it can determine the previous transaction of its own sub-transaction based on the information in the request header. Then, based on this information, it can generate sub-transaction execution data during the execution of its own sub-transaction and store it in the database for subsequent queries to determine the call order.

[0068] Wherein, after the first application sends a first call request to any second application, if the received execution result is that the second application has successfully executed the corresponding first-stage sub-transaction, that is, the execution of the startup sub-transaction has been successful, then the first application continues to send a first call request to the next second application in the predetermined order; and so on, until multiple second applications have all successfully executed the corresponding startup sub-transactions in sequence, or any second application fails to execute the corresponding startup sub-transaction.

[0069] If the received execution result indicates that the first second application failed to execute the corresponding first-stage sub-transaction, then the first application stops sending the first call request and ends the initiation of the main transaction.

[0070] Regarding step S102, after receiving the first call request, each second application executes the corresponding start sub-transaction by parsing the transaction message header included in the first call request. During the execution, it generates first-stage sub-transaction execution data, i.e. start sub-transaction data, and stores it in the database. After the execution is completed, it sends the first application back the execution result information of success or failure.

[0071] In one example, the data items in the first-stage sub-transaction execution data generated by each second application include a transaction ID item, a source transaction location information item, a current transaction location information item, a transaction behavior item, and a transaction behavior status item.

[0072] In step S102, each second application responds to the received first call request by executing the corresponding initiation sub-transaction and generating first-stage sub-transaction execution data, including:

[0073] For any given second application, the second application determines the data value of the source transaction location information item based on the main transaction location information and the previous transaction location information included in the request header of the received first call request; the second application executes the corresponding first-stage sub-transaction to generate a sub-transaction ID, generates the data value of the current transaction location information item based on the association between the sub-transaction and the main transaction and the sub-transaction ID, sets the data value of the transaction behavior item to start behavior, and sets the data value of the transaction behavior status item to in progress; the second application executes the business operation related to the start, and sets the data value of the transaction behavior status item to completed after the business operation is successfully executed, otherwise sets it to terminated.

[0074] In this way, by designing the data structure for the execution data of the sub-transaction, the data during the execution of the main transaction is stored in the database, and the call data traces of the transaction begin phase are retained, which are used by the second application to determine the call relationship in the second phase.

[0075] In one example, see Figure 2 APP1 executes the target aggregation service A, performs the "begin" action to start the main transaction, generates a transaction ID, and also stores the event data generated by the "begin" transaction as the data for starting the sub-transaction. The main data of the transaction event are as follows:

[0076]

[0077] Then APP1 executes a remote call to atomic service B, the call process is as follows: Figure 2 In process ①, the first call request received by the transaction interface in ① carries a request header (i.e., a transaction message header, including main transaction location information: DC1 / UNIT1 / APP1 / 1000, and previous transaction location information: DC1 / UNIT1 / APP1 / 1000). After receiving the first call request, atomic service B first executes the "begin" action to start a sub-transaction, generating a sub-transaction ID; based on the main transaction location information and previous transaction location information in the request header, it combines them to generate the data value of the source transaction location information item; it sets the association relationship between the sub-transaction and the main transaction, i.e., which main transaction the sub-transaction ID belongs to, generates the data value of the current transaction location information item, and sets the transaction behavior status to "PROCESS". For example, the main data for starting a sub-transaction execution is as follows:

[0078]

[0079] Then, the business operations related to startup are invoked (i.e., Figure 2 After the business begin operation in the transaction is successfully executed, the transaction begin operation is executed again, and the transaction status is set to COMPLETED. The main data of the sub-transaction execution is as follows:

[0080]

[0081] Finally, APP2 returns the data after the remote call was executed, i.e., the execution result, to APP1. The return process is as described above. Figure 2 In process ②, there is also a transaction message header (main transaction location information: DC1 / UNIT1 / APP1 / 1000, previous transaction location information: DC1 / UNIT1 / APP2 / 1001).

[0082] Then, APP1 executes a remote call to atomic service C, as shown in process ③ in the diagram above. Similar to the process of calling atomic service B, ③ also contains a transaction message header (including main transaction location information: DC1 / UNIT1 / APP1 / 1000, previous transaction location information: DC1 / UNIT1 / APP2 / 1001). After receiving the first call request, atomic service C first executes the "begin" action to start a sub-transaction, generating a sub-transaction ID; based on the main transaction location information and previous transaction location information in the request header, it combines them to generate the data value of the source transaction location information item; it sets the association between the sub-transaction and the main transaction, i.e., which main transaction the sub-transaction ID belongs to, generates the data value of the current transaction location information item, and sets the transaction behavior status to "PROCESS". The main data for starting the sub-transaction execution is as follows:

[0083]

[0084] Then, the business operations related to startup are invoked (i.e., Figure 2 After the business begin operation in the transaction is successfully executed, the transaction begin operation is executed again, and the transaction status is set to COMPLETED. The main data of the sub-transaction execution is as follows:

[0085]

[0086] Finally, APP3 returns the data after the remote call execution to APP1, i.e. the execution result. The return process is shown in process ④ in the figure above. ④ also contains a transaction message header (main transaction location information: DC1 / UNIT1 / APP1 / 1000, previous transaction location information: DC1 / UNIT1 / APP3 / 1002).

[0087] S103. The first application executes the second phase main transaction of the target aggregation service according to the received execution result, so as to determine the first target second application and send the second call request according to the second phase invocation strategy.

[0088] The second phase of the main transaction includes a commit main transaction and a rollback main transaction, which are mutually exclusive. When the received execution result indicates that the startup sub-transaction of each second application has been successfully executed, the commit main transaction of the target aggregation service is executed; when the received execution result indicates that the startup sub-transaction of any second application has failed, the rollback main transaction of the target aggregation service is executed.

[0089] When the second phase main transaction is a commit main transaction, each second application that has successfully executed the corresponding start sub-transaction is the target second application; that is, each second application needs to execute the commit sub-transaction. When the second phase main transaction is a rollback main transaction, each second application that has executed the corresponding start sub-transaction is the target second application; that is, the second application that has executed the start sub-transaction needs to execute the rollback sub-transaction to completely eliminate the impact of the start main transaction and roll back the entire business data to before the transaction started.

[0090] Here, this application embodiment supports both forward and reverse calling strategies in the second stage to meet the needs of different business scenarios. When the second stage calling strategy is forward calling, that is, the calling order is the same as that in the transaction begin stage, the first target second application is the first target second application to execute the corresponding first stage sub-transaction. When the second stage calling strategy is reverse calling, that is, the calling order is opposite to that in the transaction begin stage, the first target second application is the last target second application to execute the corresponding first stage sub-transaction.

[0091] In practice, the first application can determine the first target second application by querying the first-stage sub-transaction execution data stored in the database during the transaction begin phase, based on the second-stage invocation strategy.

[0092] Specifically, when the second-stage invocation strategy is a forward invocation, the first application uses the current main transaction location information as the query condition for the source transaction location information item, queries the first-stage sub-transaction execution data stored in the database, and determines the second application indicated by the data value of the current transaction location information item in the first-stage sub-transaction execution data that meets the query conditions as the first target second application; when the second-stage invocation strategy is a reverse invocation, the first application uses the current main transaction location information as the query condition for the current transaction location information item, queries the first-stage sub-transaction execution data stored in the database, and determines the second application indicated by the data value of the source transaction location information item in the first-stage sub-transaction execution data that meets the query conditions as the first target second application.

[0093] S104. The first target second application responds to the received second call request, executes the corresponding second-stage sub-transaction, and determines the next target second application based on the sub-transaction execution data stored in the database.

[0094] In this step, the second-stage main transaction scheduling relies on the transaction behavior generated during the execution of the target aggregation service, which is the data of `begin`, i.e., the data for initiating sub-transaction execution. The corresponding transaction API is requested using the location information of the target second application as a parameter. Upon receiving the second call request, the transaction API immediately responds and asynchronously retrieves the data for initiating the sub-transaction execution of `begin` for querying.

[0095] Specifically, when the second-stage invocation strategy is a forward invocation, the first target second application determines the next target second application based on the first-stage sub-transaction execution data stored in the database, including:

[0096] The first target second application uses its own sub-transaction location information as the query condition for the source transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the current transaction location information item in the queried first-stage sub-transaction execution data; the first target second application determines the second application corresponding to the data value of the current transaction location information item as the next target second application.

[0097] In practice, the first target second application queries its own sub-transaction location information as the value of the source transaction location information item in the start sub-transaction execution data. If a matching start sub-transaction execution data is found, the sub-transaction corresponding to the current transaction location information item in the matching start sub-transaction execution data is the subsequent transaction of the first target second application's own sub-transaction, and the application to which the location information belongs can then be identified as the next target second application.

[0098] Alternatively, when the second-phase invocation strategy is a reverse invocation, the first target second application determines the next target second application based on the first-phase sub-transaction execution data stored in the database, including:

[0099] The first target second application uses its own sub-transaction location information as the query condition for the current transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the source transaction location information item in the queried first-stage sub-transaction execution data; the first target second application determines the second application corresponding to the data value of the source transaction location information item as the next target second application.

[0100] In practice, the first target second application queries its own sub-transaction location information as the value of the current transaction location information item in the start sub-transaction execution data. If a matching start sub-transaction execution data is found, the sub-transaction corresponding to the source transaction location information item in the matching start sub-transaction execution data is the previous transaction of the first target second application's own sub-transaction, and the application to which the location information belongs can then be identified as the next target second application.

[0101] S105. The first target second application sends a second call request to the next target second application, so that the next target second application executes the corresponding second-stage sub-transaction and continues to call other target second applications until each target second application is called in sequence.

[0102] In this step, the first target second application sends a second call request to the next target second application. The next target second application responds to the second call request to execute the corresponding second-stage sub-transaction, and continues to determine the next target second application to be called in a similar manner to S104, and so on, until each target second application is called in sequence, and the transaction operation of the target aggregation service is completed.

[0103] Continue reading Figure 2 Taking the second-stage main transaction as an example, after the execution of the begin main transaction process of target aggregation service A, APP1 triggers the commit main transaction process, which will execute the main transaction commit behavior. APP1 sets the main transaction behavior to commit, the transaction behavior status to PROCESS, and stores the event data generated by the main transaction commit in the database. In this embodiment, the data structure of the second-stage sub-transaction execution data is the same as that of the first-stage sub-transaction execution data, and the main data is as follows:

[0104]

[0105] Then, APP1 asynchronously executes the main transaction commit schedule, requesting the address: http: / / {DC1 / UNIT1 / APP2} / eunomia-tx / 1001 / COMMIT. The request process is step ⑤. Finally, the main transaction commit action will be executed, the main transaction action status will be set to COMPLETED, and the event data generated by the main transaction commit will be written to the database. The main data of the transaction event is as follows:

[0106]

[0107] Then APP1 executes a remote call to atomic service B, the call process is as follows: Figure 2In process ⑤, after receiving the second call request in ⑤, application APP2 triggers the sub-transaction commit, executes the sub-transaction commit behavior, sets the sub-transaction behavior status to PROCESS, and writes the event data generated by the sub-transaction commit to the database. The main data of the transaction event are as follows:

[0108]

[0109] Then, the business operations related to the submission are invoked (i.e., Figure 2 After the business commit in the transaction is successfully executed, the transaction commit behavior is executed again, and the transaction behavior status is set to COMPLETED. The main data of the transaction event is as follows:

[0110]

[0111] Then, APP2 executes a remote call to atomic service C, as shown in process ⑥ in the diagram above. After receiving the second call request in ⑥, application APP3 triggers a sub-transaction commit, executes the sub-transaction commit behavior, sets the sub-transaction behavior status to PROCESS, and writes the event data generated by the sub-transaction commit to the database. The main data of the transaction event is as follows:

[0112]

[0113] APP3 executes the business operation commit. After execution, if there is no subsequent transaction, the transaction commit scheduling ends, the sub-transaction behavior status is set to COMPLETED, and the event data generated by the sub-transaction commit is written to the database. The main data of the transaction event is as follows:

[0114]

[0115] See another example. Figure 3 , Figure 3 This is a second schematic diagram of a distributed transaction scheduling process provided in an embodiment of this application. Figure 3 As shown, during the main transaction execution phase, APP1 calls atomic service C to start a sub-transaction exception, setting the transaction behavior status to TERMINATED. The main transaction event data is as follows:

[0116]

[0117] APP3 returns the data after the remote call is executed to APP1, i.e. the execution result. The return process is shown in process ④ in the figure above. ④ also contains a transaction message header (main transaction location information: DC1 / UNIT1 / APP1 / 1000, previous transaction location information: DC1 / UNIT1 / APP3 / 1002).

[0118] When the main transaction for the target aggregation service A terminates, APP1 triggers a rollback to reverse the main transaction process, executing the main transaction rollback behavior. The main transaction behavior status is set to PROCESS, and the event data generated by the main transaction rollback is written to the database. The main data of the transaction events are as follows:

[0119]

[0120] Then, APP1 asynchronously executes the transaction rollback schedule, requesting the address: http: / / {DC1 / UNIT1 / APP3} / eunomia-tx / 1002 / ROLLBACK. The request process is step ⑤: APP1 executes the main transaction rollback behavior, sets the main transaction behavior status to COMPLETED, and writes the event data generated by the main transaction rollback to the database. The main data of the transaction events are as follows:

[0121]

[0122] After receiving request ⑤, APP3 triggers a sub-transaction rollback, executes the sub-transaction rollback behavior, sets the sub-transaction behavior status to PROCESS, and writes the event data generated by the sub-transaction rollback to the database. The main data of the transaction event are as follows:

[0123]

[0124] APP3 performs a business rollback. After completion, it asynchronously executes a transaction rollback scheduler. The request address is: http: / / {DC1 / UNIT1 / APP2} / eunomia-tx / 1001 / ROLLBACK, and the request process is step ⑥. It then executes a sub-transaction rollback and sets the sub-transaction's status to COMPLETED. The event data generated by the sub-transaction rollback is then written to the database. The main data of the transaction events is as follows:

[0125]

[0126] Then, APP3 executes a remote call to atomic service B, as shown in process ⑥ in the diagram above. After receiving request ⑥, application APP2 triggers a sub-transaction rollback, executes the sub-transaction rollback behavior, sets the sub-transaction behavior status to PROCESS, and writes the event data generated by the sub-transaction rollback to the database. The main data of the transaction events are as follows:

[0127]

[0128] Then, APP2 executes the business rollback. After execution, it asynchronously executes the transaction rollback schedule. If there is no preceding transaction, the transaction rollback schedule ends. The sub-transaction rollback behavior is executed, and the sub-transaction behavior status is set to COMPLETED. The event data generated by the sub-transaction rollback is written to the database. The main data of the transaction events are as follows:

[0129]

[0130] Furthermore, the next target second application executes the corresponding second-stage sub-transaction, including: the next target second application queries the first-stage sub-transaction execution data stored in the database to determine other target second applications that have a direct calling relationship with the target second application according to the second-stage calling strategy; and after receiving a second calling request sent by each other target second application, it executes the corresponding second-stage sub-transaction.

[0131] This is because in actual business scenarios, the relationships between atomic services may not be simple linear, such as ABCD; rather, they may involve more complex dependencies, such as a tree structure, where atomic service D can only be called after atomic services B and C have been invoked. Therefore, the next target second application can determine other target second applications that have a direct calling relationship with it according to the second-phase invocation strategy by querying the initiation sub-transaction execution data stored in the database—that is, other atomic services that the atomic service depends on. The corresponding second-phase sub-transaction is only executed after receiving a second invocation request from each of the dependent other target second applications.

[0132] Furthermore, the distributed transaction system further includes: a transaction management terminal; the method further includes:

[0133] The transaction management terminal determines the execution order of the second-stage sub-transactions based on the first-stage sub-transaction execution data and the second-stage invocation strategy stored in the database; each target second application stores the second-stage sub-transaction execution data generated by executing the second-stage sub-transactions into the database in real time; the transaction management terminal determines the execution progress of the second-stage main transaction by comparing the execution order of the second-stage sub-transactions with the second-stage sub-transaction execution data stored in the database in real time, and displays the execution progress of the second-stage main transaction in a visual form.

[0134] Here, the transaction management terminal can determine the overall execution order of each second application when executing each second-stage sub-transaction by using the first-stage sub-transaction execution data stored in the database and the pre-set second-stage invocation strategy. The specific determination method can refer to the aforementioned method of determining the first target second application and each target second application determining the next target second application.

[0135] Subsequently, the transaction management terminal can determine the currently completed second-stage sub-transactions by reading the execution data of the second-stage sub-transactions stored in the database in real time by the second application. Then, by comparing the expected execution order with the currently completed second-stage sub-transactions, the overall execution progress of the second-stage main transaction can be determined. For example, the execution order of the second-stage sub-transactions should be: sub-transaction A of application a - sub-transaction B of application b - sub-transaction C of application c. Since sub-transaction B has been completed, the execution progress is 66%, sub-transaction B is finished, and sub-transaction C is currently executing. Furthermore, the transaction management terminal can display the execution progress visually, such as as a dynamic progress bar, allowing users to intuitively understand the transaction's execution progress.

[0136] In this way, compared with the method where each atomic service feeds back the execution result to the aggregate service one by one, and the aggregate service determines a final execution result, the transaction management terminal reads data from the database and performs logical calculations faster than the response and interaction between services. Moreover, it can display the execution progress in real time, thus improving the real-time display and reducing the pressure on the aggregate service node.

[0137] This application provides a distributed transaction scheduling method in which, during the second phase of the main transaction of the target aggregation service, applications belonging to sub-transactions call each other. This distributes the tasks of a single scheduling node in a centralized scheduling model to various nodes for execution, thereby avoiding single-point blocking, improving scheduling efficiency, reducing the pressure on individual nodes, preventing system downtime due to the failure of a single scheduling node, and improving overall system stability.

[0138] This application also provides a distributed transaction system, including a first application and multiple second applications; the first application is used to provide a target aggregation service; each second application is used to provide an atomic service or other aggregation service; the target aggregation service is obtained by arranging the services provided by the multiple second applications in a predetermined order; the service provided by each second application is set as a sub-transaction of that second application; the target aggregation service provided by the first application is set as the main transaction;

[0139] The first application is configured to execute the first phase main transaction of the target aggregation service, in order to send a first call request to each second application in the predetermined order; wherein, the first phase main transaction is the initiation of the main transaction;

[0140] Each second application is used to respond to the received first call request, execute the corresponding first-stage sub-transaction, generate first-stage sub-transaction execution data, store the first-stage sub-transaction execution data in the database, and feed back the execution result to the first application;

[0141] The first application is configured to execute the second-phase main transaction of the target aggregation service based on the received execution result, so as to determine the first target second application and send a second invocation request according to the second-phase invocation strategy; wherein, the second-phase main transaction includes committing the main transaction and rolling back the main transaction;

[0142] The first target second application is used to respond to the received second call request, execute the corresponding second phase sub-transaction, and determine the next target second application based on the first phase sub-transaction execution data stored in the database;

[0143] The first target second application is used to send a second call request to the next target second application, so that the next target second application executes the corresponding second-stage sub-transaction and continues to call other target second applications until each target second application is called in sequence.

[0144] Furthermore, the data items in the first-stage sub-transaction execution data generated by each second application include a transaction ID item, a source transaction location information item, a current transaction location information item, a transaction behavior item, and a transaction behavior status item; when each second application executes the corresponding first-stage sub-transaction in response to the received first call request and generates the first-stage sub-transaction execution data, each second application is used to:

[0145] For any second application, the second application determines the data value of the source transaction location information item based on the main transaction location information and the previous transaction location information included in the request header of the received first call request;

[0146] The second application executes the corresponding first-stage sub-transaction to generate a sub-transaction ID, generates the data value of the current transaction location information item according to the association between the sub-transaction and the main transaction and the sub-transaction ID, sets the data value of the transaction behavior item to start behavior, and sets the data value of the transaction behavior status item to in progress.

[0147] The second application performs business operations related to startup, and sets the data value of the transaction behavior status item to "completed" after the business operation is successfully executed, otherwise it is set to "terminated".

[0148] Furthermore, when the second phase main transaction is a commit main transaction, each second application is the target second application;

[0149] When the second phase main transaction is a rollback main transaction, each second application that has executed the corresponding first phase sub-transaction is the target second application;

[0150] When the second phase invocation strategy is a forward invocation, the first target second application is the first target second application to execute the corresponding first phase sub-transaction; when the second phase invocation strategy is a reverse invocation, the first target second application is the last target second application to execute the corresponding first phase sub-transaction.

[0151] Furthermore, when the second-stage invocation strategy is a forward invocation, the first target second application, when determining the next target second application based on the first-stage sub-transaction execution data stored in the database, is used to:

[0152] The first target second application uses its own sub-transaction location information as the query condition for the source transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the current transaction location information item in the queried first-stage sub-transaction execution data;

[0153] The first target second application determines the second application corresponding to the data value of the current transaction location information item as the next target second application.

[0154] Furthermore, when the second-stage invocation strategy is a reverse invocation, the first target second application, when determining the next target second application based on the first-stage sub-transaction execution data stored in the database, is used to:

[0155] The first target second application uses its own sub-transaction location information as the query condition for the current transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the source transaction location information item in the queried first-stage sub-transaction execution data;

[0156] The first target second application determines the second application corresponding to the data value of the source transaction location information item as the next target second application.

[0157] Furthermore, when the next target second application is used to execute the corresponding second-phase sub-transaction, the next target second application is used for:

[0158] By querying the first-stage sub-transaction execution data stored in the database, other target second applications that have a direct calling relationship with the target second application according to the second-stage calling strategy are identified.

[0159] After receiving a second call request from each other target second application, the corresponding second-phase sub-transaction is executed.

[0160] Furthermore, when the first application executes the first-phase main transaction of the target aggregation service to send first call requests to each second application in the predetermined order, the first application is used to:

[0161] The first phase of the main transaction of the target aggregation service is executed by sending a first call request to each of the second applications in the predetermined order.

[0162] Specifically, after the first application sends a first call request to any of the second applications...

[0163] If the received execution result indicates that the second application has successfully executed the corresponding first-stage sub-transaction, then the first application continues to send the first call request to the next second application in the predetermined sequence.

[0164] If the received execution result indicates that the first second application failed to execute the corresponding first-phase sub-transaction, then the first application stops sending the first call request and ends the first-phase main transaction.

[0165] Furthermore, when the first application executes the second-phase main transaction of the target aggregation service based on the received execution result, the first application is used to:

[0166] When the received execution result indicates that the first-stage sub-transaction of each second application has been successfully executed, the commit main transaction of the target aggregation service is executed.

[0167] When the received execution result is that the first-stage sub-transaction of any second application fails, the rollback main transaction of the target aggregation service is executed.

[0168] Furthermore, the distributed transaction system also includes: a transaction management terminal;

[0169] The transaction management terminal determines the execution order of the second-stage sub-transactions based on the first-stage sub-transaction execution data and the second-stage invocation strategy stored in the database.

[0170] Each target second application will execute the second-stage sub-transaction execution data generated by the second-stage sub-transaction and store it into the database in real time;

[0171] The transaction management terminal determines the execution progress of the second-stage main transaction by comparing the execution order of the second-stage sub-transactions with the execution data of the second-stage sub-transactions stored in the database in real time, and displays the execution progress of the second-stage main transaction in a visual form.

[0172] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0173] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 1 The steps of a distributed transaction scheduling method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0174] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of a distributed transaction scheduling method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0175] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0176] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0178] In addition, the functional units 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.

[0179] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0180] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A distributed transaction scheduling method, characterized in that, This is applied to a distributed transaction system; the distributed transaction system includes a first application and multiple second applications; the first application is used to provide a target aggregation service; each second application is used to provide an atomic service or other aggregation service. The target aggregation service is obtained by arranging services provided by multiple second applications in a predetermined order; each service provided by a second application is set as a sub-transaction of that second application. The target aggregation service provided by the first application is set as the main transaction; the method includes: The first application executes the first phase of the main transaction of the target aggregation service to send first call requests to each second application in the predetermined order; wherein, the first phase of the main transaction is the initiation of the main transaction; Each second application, in response to the received first call request, executes the corresponding first-stage sub-transaction, generates first-stage sub-transaction execution data, stores the first-stage sub-transaction execution data in the database, and feeds back the execution result to the first application; The first application executes the second-phase main transaction of the target aggregation service based on the received execution result, in order to determine the first target second application and send a second invocation request according to the second-phase invocation strategy; wherein, the second-phase main transaction includes committing the main transaction and rolling back the main transaction; The first target second application responds to the received second call request, executes the corresponding second-stage sub-transaction, and determines the next target second application based on the first-stage sub-transaction execution data stored in the database; The first target second application sends a second call request to the next target second application, so that the next target second application executes the corresponding second-stage sub-transaction and continues to call other target second applications until each target second application is called in sequence. The data items in the first-stage sub-transaction execution data generated by each second application include source transaction location information items and current transaction location information items; When the second-phase invocation strategy is a forward invocation, the first target second application determines the next target second application based on the first-phase sub-transaction execution data stored in the database, including: The first target second application uses its own sub-transaction location information as the query condition for the source transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the current transaction location information item in the queried first-stage sub-transaction execution data; The first target second application determines the second application corresponding to the data value of the current transaction location information item as the next target second application.

2. The method according to claim 1, characterized in that, The data items in the first-stage sub-transaction execution data generated by each second application also include a transaction ID item, a transaction behavior item, and a transaction behavior status item; each second application, in response to the received first call request, executes the corresponding first-stage sub-transaction and generates the first-stage sub-transaction execution data, including: For any second application, the second application determines the data value of the source transaction location information item based on the main transaction location information and the previous transaction location information included in the request header of the received first call request; The second application executes the corresponding first-stage sub-transaction to generate a sub-transaction ID, generates the data value of the current transaction location information item according to the association between the sub-transaction and the main transaction and the sub-transaction ID, sets the data value of the transaction behavior item to start behavior, and sets the data value of the transaction behavior status item to in progress. The second application performs business operations related to startup, and sets the data value of the transaction behavior status item to "completed" after the business operation is successfully executed, otherwise it is set to "terminated".

3. The method according to claim 2, characterized in that, When the second phase main transaction is the commit main transaction, each second application is the target second application; When the second phase main transaction is a rollback main transaction, each second application that has executed the corresponding first phase sub-transaction is the target second application; When the second-stage invocation strategy is a forward invocation, the first target second application is the first target second application that executes the corresponding first-stage sub-transaction; When the second-stage invocation strategy is a reverse invocation, the first target second application is the last target second application that executes the corresponding first-stage sub-transaction.

4. The method according to claim 3, characterized in that, When the second-phase invocation strategy is a reverse invocation, the first target second application determines the next target second application based on the first-phase sub-transaction execution data stored in the database, including: The first target second application uses its own sub-transaction location information as the query condition for the current transaction location information item, and queries the first-stage sub-transaction execution data stored in the database to determine the data value of the source transaction location information item in the queried first-stage sub-transaction execution data; The first target second application determines the second application corresponding to the data value of the source transaction location information item as the next target second application.

5. The method according to claim 1, characterized in that, The next objective is for the second application to execute the corresponding second-phase sub-transaction, including: The next target second application determines other target second applications that have a direct calling relationship with the target second application according to the second-stage calling strategy by querying the first-stage sub-transaction execution data stored in the database. After receiving a second call request from each other target second application, the corresponding second-phase sub-transaction is executed.

6. The method according to claim 1, characterized in that, The first application executes the first phase of the main transaction of the target aggregation service to send first invocation requests to each of the second applications in the predetermined order, including: The first application executes the first phase of the main transaction of the target aggregation service, and sequentially sends a first call request to each of the second applications in the predetermined order; Specifically, after the first application sends a first call request to any of the second applications... If the received execution result indicates that the second application has successfully executed the corresponding first-stage sub-transaction, then the first application continues to send the first call request to the next second application in the predetermined sequence. If the received execution result indicates that the first second application failed to execute the corresponding first-phase sub-transaction, then the first application stops sending the first call request and ends the first-phase main transaction.

7. The method according to claim 1, characterized in that, Based on the received execution result, the first application executes the second phase of the main transaction of the target aggregation service, including: When the received execution result indicates that the first-stage sub-transaction of each second application has been successfully executed, the commit main transaction of the target aggregation service is executed. When the received execution result is that the first-stage sub-transaction of any second application fails, the rollback main transaction of the target aggregation service is executed.

8. The method according to claim 1, characterized in that, The distributed transaction system further includes: a transaction management terminal; the method further includes: The transaction management terminal determines the execution order of the second-stage sub-transactions based on the first-stage sub-transaction execution data and the second-stage invocation strategy stored in the database. Each target second application will execute the second-stage sub-transaction execution data generated by the second-stage sub-transaction and store it into the database in real time; The transaction management terminal determines the execution progress of the second-stage main transaction by comparing the execution order of the second-stage sub-transactions with the execution data of the second-stage sub-transactions stored in the database in real time, and displays the execution progress of the second-stage main transaction in a visual form.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the distributed transaction scheduling method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the distributed transaction scheduling method as described in any one of claims 1 to 8.

Images