Distributed transaction processing method, system and equipment in disaster recovery switching scene

Abstract

The embodiment of the invention relates to the technical field of financial science and technology, and discloses a distributed transaction processing method, system and equipment in a disaster recovery backup switching scene. The method comprises the following steps: establishing a second distributed transaction platform which is in peer-to-peer support with a production environment in a disaster recovery environment; and when the target switching application is switched from the production environment to the disaster recovery environment for distributed transaction processing, controlling the target switching application to subscribe to a second distributed transaction platform in the disaster recovery environment, and initiating a transaction to the second distributed transaction platform. By establishing the second distributed transaction platform which is in peer-to-peer support with the production environment in the disaster recovery environment, the service can be isolated from the production environment in the disaster recovery environment, end-to-end accurate registration and subscription of the service can be realized, and the transaction efficiency and the success rate can be improved.

Description

Technical Field

[0001] The present invention relates to the field of financial technology, and in particular to a distributed transaction processing method, system, and device in a disaster recovery switching scenario. Background Art

[0002] In distributed scenarios, a distributed transaction involves multiple participants. To address the consistency issues associated with distributed transactions in distributed scenarios, a distributed transaction platform typically coordinates all transaction participants to ensure consistency across all transaction participants.

[0003] However, in the existing off-site disaster recovery switching scenario, the application that needs to be switched is in the disaster recovery environment, but other transaction participants are still in the production environment. In this case, the application that needs to be switched in the disaster recovery environment initiates a transaction request to the distributed transaction platform in the production environment. At the same time, the distributed transaction platform in the production environment initiates a request to the application that needs to be switched in the disaster recovery environment during compensation.

[0004] In existing disaster recovery scenarios, transactions require cross-regional calls to the distributed transaction platform across both the production and disaster recovery environments. As more applications are switched, the number of remote calls to the distributed transaction platform increases, increasing overall transaction time. Furthermore, in remote disaster recovery switching scenarios, service registration and subscription are not isolated from the production environment, preventing accurate end-to-end registration and subscription of services, posing transaction risks. Summary of the Invention

[0005] The present invention provides a distributed transaction processing method, system and device in a disaster recovery switching scenario to achieve end-to-end accurate registration and subscription of services, thereby improving transaction efficiency and success rate.

[0006] According to one aspect of the present invention, a distributed transaction processing method in a disaster recovery switching scenario is provided, the method comprising:

[0007] Establish a second distributed transaction platform in the disaster recovery environment that provides equal support to the production environment;

[0008] When the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction to the second distributed transaction platform.

[0009] According to another aspect of the present invention, a distributed transaction processing system in a disaster recovery switching scenario is provided, the system comprising: a production environment and a disaster recovery environment;

[0010] A first distributed transaction platform is provided in the production environment, and a second distributed transaction platform is provided in the disaster recovery environment to provide peer-to-peer support to the first distributed transaction platform;

[0011] Applications involved in transaction processing are switched from the production environment to the disaster recovery environment, or from the disaster recovery environment to the production environment, depending on the transaction processing situation.

[0012] When the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application subscribes to the second distributed transaction platform in the disaster recovery environment and initiates a transaction to the second distributed transaction platform.

[0013] According to another aspect of the present invention, a distributed transaction processing device in a disaster recovery switching scenario is provided, the device comprising:

[0014] A second distributed transaction platform establishment module is used to establish a second distributed transaction platform in the disaster recovery environment that is equivalent to the production environment;

[0015] The transaction control module is used to control the target switching application to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction to the second distributed transaction platform when the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing.

[0016] According to another aspect of the present invention, an electronic device is provided, comprising:

[0017] at least one processor; and

[0018] a memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed transaction processing method in the disaster recovery switching scenario described in any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed transaction processing method in the disaster recovery switching scenario described in any embodiment of the present invention when executed.

[0021] According to another aspect of the present invention, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the distributed transaction processing method in a disaster recovery switching scenario according to any embodiment of the present invention.

[0022] The technical solution of the embodiment of the present invention solves the problem of remote calling of distributed transaction platforms in disaster recovery switching scenarios by establishing a second distributed transaction platform that is on par with the production environment in the disaster recovery environment; when the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction transaction to the second distributed transaction platform. By establishing a second distributed transaction platform that is on par with the production environment in the disaster recovery environment, isolation of services from the disaster recovery environment to the production environment can be achieved, and accurate registration and subscription of services from end to end can be achieved, thereby improving transaction efficiency and success rate.

[0023] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0025] Figure 1a This is a flowchart of a distributed transaction processing method in a disaster recovery switching scenario provided by Embodiment 1 of the present invention;

[0026] Figure 1b This is a schematic diagram of a distributed transaction consistency processing process provided according to the first embodiment of the present invention;

[0027] Figure 1c This is a diagram of the service call relationship during the non-switching period in a remote disaster recovery switching scenario;

[0028] Figure 1d This is a diagram of the service call relationship during the switching period in a remote disaster recovery switching scenario;

[0029] Figure 1e This is a schematic diagram of the interaction of distributed transaction processing in a disaster recovery switching scenario provided by the first embodiment of the present invention;

[0030] Figure 2a This is a flowchart of a distributed transaction processing method in a disaster recovery switching scenario provided by Embodiment 2 of the present invention;

[0031] Figure 2b It is a schematic diagram of the generation of a unilateral account;

[0032] Figure 2cThis is a schematic diagram of transaction processing after transaction traffic is intercepted according to the second embodiment of the present invention;

[0033] Figure 2d This is a schematic diagram of intercepting transaction traffic according to the second embodiment of the present invention;

[0034] Figure 2e This is another schematic diagram of transaction traffic interception provided according to the second embodiment of the present invention;

[0035] Figure 3 2 is a schematic diagram of the structure of a distributed transaction processing system in a disaster recovery switching scenario provided by Embodiment 3 of the present invention;

[0036] Figure 4 2 is a schematic structural diagram of a distributed transaction processing device in a disaster recovery switching scenario provided by a fourth embodiment of the present invention;

[0037] Figure 5 It is a structural diagram of an electronic device for implementing the distributed transaction processing method in a disaster recovery switching scenario according to an embodiment of the present invention. DETAILED DESCRIPTION

[0038] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0039] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0040] Example 1

[0041] Figure 1aThis is a flowchart of a distributed transaction processing method in a disaster recovery switching scenario provided according to Example 1 of the present invention. This embodiment is applicable to situations where consistency is guaranteed during distributed transaction processing in a disaster recovery switching scenario. The method can be executed by a distributed transaction processing device in the disaster recovery switching scenario. The distributed transaction processing device in the disaster recovery switching scenario can be implemented in the form of hardware and / or software. The distributed transaction processing device in the disaster recovery switching scenario can be configured in an electronic device, which can be a mobile device such as a mobile phone, a tablet computer (PAD), a wearable device, or a personal computer (PC, Personal Computer), etc.

[0042] Figure 1b This is a schematic diagram of a distributed transaction consistency processing process provided by the first embodiment of the present invention. Figure 1b As shown in the figure, to ensure the consistency of distributed transactions, in addition to the main transaction initiating a request to the distributed transaction platform, the distributed transaction platform also initiates callback requests to the subtransactions. Assume that there are two subtransactions under the main transaction. Before initiating the transaction, the main transaction registers a main transaction information with the distributed transaction platform (the specific process is received by the transaction receiver and finally persisted to the transaction processor). It then calls subtransaction 1 and subtransaction 2 in sequence. Before executing the actual business transaction, the subtransaction registers the subtransaction information with the distributed transaction platform and associates it with the corresponding main transaction information. If an exception occurs in the transaction, the transaction processor notifies all subtransactions to execute a counter-transaction to ensure the consistency of the entire transaction.

[0043] In a remote disaster recovery switchover scenario, to ensure rapid transaction recovery after a natural disaster, man-made accident, or technical failure, the target application (i.e., the application to be switched) is located in the disaster recovery environment, while all other transaction participants remain in the production environment. The target application in the disaster recovery environment initiates a transaction request to the distributed transaction platform in the production environment, while the distributed transaction platform in the production environment simultaneously initiates a request to the target application in the disaster recovery environment for compensation.

[0044] Figure 1c This is a diagram of the service call relationship during the non-switching period in a remote disaster recovery switching scenario. Figure 1d This is a diagram of the service call relationship during the switching period in the remote disaster recovery switching scenario. Figure 1c As shown, during the non-switching period, the application registers and subscribes to the distributed transaction platform in the production environment, initiates a transaction, and the distributed transaction platform in the production environment rolls back the transaction of the application in the production environment. Figure 1c There is no cross-environment transaction processing involved. However, when the application switches to the disaster recovery environment, Figure 1dAs shown in the figure, when the application in the disaster recovery environment is processing a transaction, it needs to register and subscribe to the distributed transaction platform in the production environment to initiate a transaction. When a transaction exception requires a rollback, the distributed transaction platform in the production environment needs to call back the application in the disaster recovery environment. Figure 1d Cross-environment transaction processing is required.

[0045] In cross-environment transaction processing, the increasing number of target switching applications leads to increased remote interactions between applications and the distributed transaction platform, impacting overall transaction processing time. Furthermore, since the target switching application subscribes to the production environment's distributed transaction platform services during the positive transaction chain, and the target switching application's callback service is registered with the production environment during the compensation transaction chain, this lacks strict end-to-end service registration and subscription accuracy, posing risks.

[0046] Therefore, in order to solve the above problems, a distributed transaction processing method in a disaster recovery switching scenario is provided in an embodiment of the present invention, such as Figure 1a As shown, the method includes:

[0047] Step 110: Establish a second distributed transaction platform in the disaster recovery environment that supports the production environment on an equal footing.

[0048] The second distributed transaction platform in the disaster recovery environment is a redundant backup of the first distributed transaction platform in the production environment. The first distributed transaction platform in the production environment and the second distributed transaction platform in the disaster recovery environment can subscribe to each other to achieve data consistency of the distributed transaction platforms.

[0049] Step 120: When the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction to the second distributed transaction platform.

[0050] By building a second distributed transaction platform within the disaster recovery environment, we achieve the same support capabilities as the production environment, enabling both production and disaster recovery environments to support access and coordination of all transactions. For off-site disaster recovery switching scenarios, this second distributed transaction platform supports the target application's transaction flow within the disaster recovery environment, coordinates transaction consistency, reduces off-site calls between transactions and the distributed transaction platform, and optimizes overall transaction processing time. This also enables precise subscription and registration of services in both production and disaster recovery environments, reducing unnecessary risk.

[0051] Optionally, the method further includes: when the target switching application switches from the disaster recovery environment to the production environment for distributed transaction processing, controlling the target switching application to subscribe to the first distributed transaction platform in the production environment and initiating a transaction transaction to the first distributed transaction platform.

[0052] Figure 1e FIG. 1 is a schematic diagram of the interaction of distributed transaction processing in a disaster recovery switching scenario according to the first embodiment of the present invention. Figure 1e As shown, for applications in the production environment, they can register and subscribe to the first distributed transaction platform in the production environment to make transaction requests. When the transaction needs to be rolled back, the transaction is rolled back through the first distributed transaction platform in the production environment.

[0053] like Figure 1e As shown, applications in the disaster recovery environment can register and subscribe to the second distributed transaction platform in the disaster recovery environment, making transaction requests. When a transaction needs to be rolled back, the transaction is rolled back through the second distributed transaction platform in the disaster recovery environment. The first distributed transaction platform in the production environment and the second distributed transaction platform in the disaster recovery environment can subscribe to each other, achieving data consistency across the distributed transaction platforms.

[0054] The technical solution of this embodiment solves the problem of remote calling of distributed transaction platforms in disaster recovery switching scenarios by establishing a second distributed transaction platform that supports the production environment on an equal footing in the disaster recovery environment; when the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction transaction to the second distributed transaction platform. By establishing a second distributed transaction platform that supports the production environment on an equal footing in the disaster recovery environment, it is possible to isolate services in the disaster recovery environment from the production environment, achieve end-to-end accurate registration and subscription of services, and improve transaction efficiency and success rate.

[0055] Example 2

[0056] Figure 2a This is a flow chart of a distributed transaction processing method in a disaster recovery switching scenario provided by the second embodiment of the present invention. This embodiment is a further refinement of the above technical solution. The technical solution in this embodiment can be combined with various optional solutions in one or more of the above embodiments. Figure 2a As shown, the method includes:

[0057] Step 210: Establish a second distributed transaction platform in the disaster recovery environment that supports the production environment on an equal footing.

[0058] Step 220: When the target switching application is switched from the production environment to the disaster recovery environment to perform distributed transaction processing, the target switching application is controlled to subscribe to a second distributed transaction platform in the disaster recovery environment.

[0059] Step 230: When the target switching application is in the process of switching from the production environment to the disaster recovery environment, intercept the transaction traffic of the target switching application.

[0060] During a remote disaster recovery switchover, database writes to the target application may be uncertain. For example, if a connection to the second distributed transaction processing platform in the disaster recovery environment fails, the target application may be conducting transactions with the first distributed transaction processing platform in the production environment. If a business transaction fails due to an inability to process, the first distributed transaction platform will initiate compensation in real time. The target application may compensate for the inability to execute the transaction, resulting in a large number of unilateral accounts, which is a sign of business transaction inconsistency.

[0061] Figure 2b This is a schematic diagram of the generation of a unilateral account. Figure 2b As shown, when the target switching application is in the process of switching from the production environment to the disaster recovery environment, the target switching application connects to the first distributed transaction platform in the production environment to perform a transaction call. However, when the transaction processing fails and transaction compensation is performed, the first distributed transaction platform cannot connect to the target switching application, causing the compensation transaction to fail and generating a one-sided account.

[0062] In the embodiment of the present invention, in order to solve the following problems Figure 2b To address the unilateral accounting issue shown above, the target application's transaction traffic is intercepted while the application is being switched from a production environment to a disaster recovery environment. By intercepting transaction traffic and temporarily suspending transaction processing, unilateral accounting can be avoided during the switchover process.

[0063] Figure 2c This is a schematic diagram of transaction processing after transaction flow interception according to the second embodiment of the present invention. Figure 2c As shown in the figure, when the target application is switching from the production environment to the disaster recovery environment, if a main transaction calls a subtransaction of the target application, the call will fail due to traffic interception. Therefore, when the transaction is compensated, there is no need to call back to the target application for compensation, and no one-sided account will occur.

[0064] Optionally, when the target switching application is in the process of switching from the production environment to the disaster recovery environment, the transaction traffic of the target switching application is intercepted, including: monitoring the application transaction indicators of the transaction transactions between the target switching application and the first distributed transaction platform in the production environment; when the application transaction is determined to be abnormal based on the application transaction indicators, it is determined that the target switching application is in the process of switching from the production environment to the disaster recovery environment, and the transaction traffic of the target switching application is intercepted.

[0065] Application transaction indicators include, but are not limited to, transaction success rate, transaction failure rate, and transaction timeout. When a transaction anomaly is determined based on the application transaction indicators, it can be determined that the target application is in the process of switching from a production environment to a disaster recovery environment, and the transaction traffic of the target application can be intercepted. For example, if the transaction failure rate is greater than or equal to 30%, or the transaction success rate is less than or equal to 70%, or the transaction time exceeds a preset time threshold, such as 1 minute, an application transaction anomaly is determined, and interception of the transaction traffic of the target application is initiated.

[0066] Optionally, the transaction traffic of the target switching application is intercepted, including: intercepting the transaction traffic of the target switching application according to traffic interception dimension information; wherein the traffic interception dimension information includes: application dimension, group dimension, main transaction method dimension and sub-transaction method dimension.

[0067] In transaction processing, an application can include multiple groups, a group can include multiple main transaction methods, and a main transaction method can include multiple sub-transaction methods. Groups can be divided according to the functional needs of the application. For example, a group can include a front-end page display group, an interface entry group, a server group, an access layer group, and a processing layer group. The access layer group can include main transaction methods such as credit, loan, and financing. The main transaction method for credit can include sub-transaction methods such as qualification review, credit agreement signing, bookkeeping, collection, and repayment and write-off.

[0068] When intercepting transaction traffic for the target switching application, interception can be performed in different dimensions to achieve precise control of the application.

[0069] Step 240: When the target switching application completes switching from the production environment to the disaster recovery environment, stop intercepting the transaction traffic of the target switching application and conduct transaction transactions through the second distributed transaction platform.

[0070] Figure 2d This is a schematic diagram of intercepting transaction traffic according to the second embodiment of the present invention. Figure 2dAs shown, when the target switching application is normally connected to the production environment, transaction processing can be performed through the first distributed transaction platform in the production environment. When the application transaction indicator is monitored to indicate a transaction abnormality, it is determined that the target switching application is in the process of switching from the production environment to the disaster recovery environment, and the transaction flow of the target switching application is intercepted. When the target switching application completes the switch from the production environment to the disaster recovery environment, the interception of the transaction flow of the target switching application can be stopped, and the second distributed transaction platform in the disaster recovery environment can be used to perform transaction transactions. By accurately controlling the opening and closing of the interception of the transaction flow of the target switching application, the generation of unilateral accounts can be avoided, the accuracy of transaction processing can be improved, and the consistency of distributed transactions can be ensured.

[0071] Step 250: When the target switching application switches from the disaster recovery environment to the production environment to perform distributed transaction processing, control the target switching application to subscribe to the first distributed transaction platform in the production environment.

[0072] Step 260: When the target switching application is in the process of switching from the disaster recovery environment to the production environment, intercept the transaction traffic of the target switching application.

[0073] Similarly, when the target switching application is switched from the disaster recovery environment back to the production environment, transaction traffic can be intercepted during the switching process to avoid the generation of unilateral accounts and improve the accuracy and consistency of transaction transactions.

[0074] Optionally, the transaction traffic of the target switching application is intercepted, including: monitoring application transaction indicators of transaction transactions between the target switching application and the second distributed transaction platform in the disaster recovery environment; when it is determined that the application transaction is abnormal based on the application transaction indicators, it is determined that the target switching application is in the process of switching from the disaster recovery environment to the production environment, and the transaction traffic of the target switching application is intercepted.

[0075] Optionally, the transaction traffic of the target switching application is intercepted, including: intercepting the transaction traffic of the target switching application according to traffic interception dimension information; wherein the traffic interception dimension information includes: application dimension, group dimension, main transaction method dimension and sub-transaction method dimension.

[0076] Step 270: When the target switching application completes switching from the disaster recovery environment to the production environment, stop intercepting the transaction traffic of the target switching application and conduct transaction transactions through the first distributed transaction platform.

[0077] Figure 2e This is another schematic diagram of intercepting transaction traffic according to the second embodiment of the present invention. Figure 2eAs shown, when the target switching application is connected to the second distributed transaction platform in the disaster recovery environment for transaction processing, the application transaction indicators can be monitored. When the application transaction is determined to be abnormal based on the application transaction indicators, it is determined that the target switching application is in the process of switching from the disaster recovery environment to the production environment, and the transaction flow of the target switching application is intercepted. When the target switching application completes the switch from the disaster recovery environment to the production environment, the interception of the transaction flow of the target switching application is stopped, and the transaction transaction is carried out through the first distributed transaction platform. By accurately turning on and off the interception of transaction flow when the target switching application switches from the disaster recovery environment to the production environment, transaction consistency can be achieved and the generation of unilateral accounts can be avoided.

[0078] Based on the above implementation, optionally, the method further includes: when the target switching application completes switching from the production environment to the disaster recovery environment, obtaining transaction data of application transaction abnormalities during the process of the target switching application switching from the production environment to the disaster recovery environment; and performing application transaction callback compensation processing based on the transaction data through a second distributed transaction platform in the disaster recovery environment.

[0079] Since a second distributed transaction platform is established in the disaster recovery environment to provide peer support to the first distributed transaction platform in the production environment, callback compensation can be performed on transactions with abnormalities in the production environment through the second distributed transaction platform, further resolving the problem of unilateral accounts. Callbacks through the second distributed transaction platform avoid the unilateral account problem caused by the inability to connect when the target switching application is already in the process of switching to the disaster recovery environment when callbacks are made through the first distributed transaction platform for abnormal transactions. It also avoids cross-environment issues when callbacks are made through the first distributed transaction platform. Callback compensation through the second distributed transaction platform can achieve end-to-end precise subscription and registration of services, reducing transaction risks.

[0080] Similarly, optionally, the method further includes: when the target switching application completes switching from the disaster recovery environment to the production environment, obtaining transaction data of application transaction abnormalities during the process of the target switching application switching from the disaster recovery environment to the production environment; and performing application transaction callback compensation processing based on the transaction data through the first distributed transaction platform in the production environment.

[0081] The technical solution of the embodiment of the present invention is to establish a second distributed transaction platform in the disaster recovery environment that is equivalent to the production environment; when the target switching application is switched from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the disaster recovery environment; when the target switching application is in the process of switching from the production environment to the disaster recovery environment, the transaction flow of the target switching application is intercepted; when the target switching application completes the switching from the production environment to the disaster recovery environment, the transaction flow of the target switching application is stopped from being intercepted, and transaction transactions are performed through the second distributed transaction platform; when the target switching application is switched from the disaster recovery environment to the production environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the production environment. A distributed transaction platform; when the target switching application is in the process of switching from the disaster recovery environment to the production environment, the transaction flow of the target switching application is intercepted; when the target switching application completes the switch from the disaster recovery environment to the production environment, the transaction flow of the target switching application is stopped from being intercepted, and transaction transactions are conducted through the first distributed transaction platform, thereby solving the problem of remote calling of the distributed transaction platform in the disaster recovery switching scenario. By establishing a second distributed transaction platform in the disaster recovery environment that is on par with the production environment, isolation of services in the disaster recovery environment from the production environment can be achieved, and accurate registration and subscription of services from end to end can be achieved, thereby improving transaction efficiency and success rate; by intercepting the transaction flow during the switching process, unilateral accounts can be avoided and transaction consistency can be achieved.

[0082] Example 3

[0083] Figure 3 FIG. 1 is a structural diagram of a distributed transaction processing system in a disaster recovery switching scenario according to the third embodiment of the present invention. Figure 3 As shown, the distributed transaction processing system 300 in the disaster recovery switching scenario includes: a production environment 310 and a disaster recovery environment 320.

[0084] A first distributed transaction platform 311 is provided in the production environment, and a second distributed transaction platform 321 is provided in the disaster recovery environment to provide peer-to-peer support for the first distributed transaction platform 311. Applications participating in transaction processing are switched from the production environment to the disaster recovery environment, or vice versa, depending on the transaction processing situation.

[0085] When the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application subscribes to the second distributed transaction platform in the disaster recovery environment and initiates a transaction to the second distributed transaction platform.

[0086] Optionally, the system is specifically used to: intercept the transaction traffic of the target switching application when the target switching application is in the process of switching from the production environment to the disaster recovery environment; when the target switching application completes switching from the production environment to the disaster recovery environment, stop intercepting the transaction traffic of the target switching application and conduct transaction transactions through the second distributed transaction platform.

[0087] Optionally, the system is also used to: monitor application transaction indicators of transaction transactions between the target switching application and the first distributed transaction platform in the production environment; when an application transaction abnormality is determined based on the application transaction indicators, determine that the target switching application is in the process of switching from the production environment to the disaster recovery environment, and intercept the transaction traffic of the target switching application.

[0088] Optionally, the system is specifically used to intercept the transaction traffic of the target switching application based on traffic interception dimension information; wherein the traffic interception dimension information includes: application dimension, group dimension, main transaction method dimension and sub-transaction method dimension.

[0089] Optionally, the system is also used to: when the target switching application completes switching from the production environment to the disaster recovery environment, obtain transaction data of application transaction abnormalities during the process of the target switching application switching from the production environment to the disaster recovery environment; and perform application transaction callback compensation processing based on the transaction data through the second distributed transaction platform in the disaster recovery environment.

[0090] Optionally, the system is also used to: when the target switching application switches from the disaster recovery environment to the production environment for distributed transaction processing, control the target switching application to subscribe to the first distributed transaction platform in the production environment and initiate a transaction transaction to the first distributed transaction platform.

[0091] Optionally, the system is specifically used to: intercept the transaction traffic of the target switching application when the target switching application is in the process of switching from the disaster recovery environment to the production environment; when the target switching application completes switching from the disaster recovery environment to the production environment, stop intercepting the transaction traffic of the target switching application and conduct transaction transactions through the first distributed transaction platform.

[0092] The technical solution of the embodiment of the present invention is to set up a distributed transaction processing system in a disaster recovery switching scenario including a production environment and a disaster recovery environment, wherein a first distributed transaction platform is set up in the production environment, and a second distributed transaction platform that is peer-to-peer with the first distributed transaction platform is set up in the disaster recovery environment; applications participating in transaction processing are switched from the production environment to the disaster recovery environment, or from the disaster recovery environment to the production environment according to the transaction processing situation; when the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application subscribes to the second distributed transaction platform in the disaster recovery environment and initiates a transaction transaction to the second distributed transaction platform, thereby solving the problem of remote calling of the distributed transaction platform in the disaster recovery switching scenario. By establishing a second distributed transaction platform that is peer-to-peer with the production environment in the disaster recovery environment, it is possible to achieve isolation of services in the disaster recovery environment from the production environment, achieve end-to-end accurate registration and subscription of services, and improve transaction efficiency and success rate.

[0093] Example 4

[0094] Figure 4 FIG. 1 is a structural diagram of a distributed transaction processing device in a disaster recovery switching scenario provided by the fourth embodiment of the present invention. Figure 4 As shown, the device includes: a second distributed transaction platform establishment module 410 and a transaction control module 420.

[0095] A second distributed transaction platform establishment module 410 is used to establish a second distributed transaction platform in the disaster recovery environment that is equivalent to the production environment;

[0096] The transaction control module 420 is used to control the target switching application to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction to the second distributed transaction platform when the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing.

[0097] Optionally, the transaction control module 420 includes:

[0098] A traffic interception unit is used to intercept the transaction traffic of the target switching application when the target switching application is in the process of switching from the production environment to the disaster recovery environment;

[0099] The stopping interception unit is used to stop intercepting the transaction flow of the target switching application when the target switching application completes switching from the production environment to the disaster recovery environment, and conduct transaction transactions through the second distributed transaction platform.

[0100] Optional, traffic interception unit, including:

[0101] An application transaction indicator monitoring subunit, configured to monitor application transaction indicators of transaction transactions performed between a target switching application and a first distributed transaction platform in a production environment;

[0102] The first traffic interception sub-unit is used to determine that the target switching application is in the process of switching from the production environment to the disaster recovery environment when the application transaction is determined to be abnormal based on the application transaction indicator, and intercept the transaction traffic of the target switching application.

[0103] Optional, traffic interception unit, including:

[0104] The second traffic interception sub-unit is used to intercept the transaction traffic of the target switching application according to the traffic interception dimension information;

[0105] The traffic interception dimension information includes: application dimension, group dimension, main transaction method dimension, and sub-transaction method dimension.

[0106] Optionally, the device further includes:

[0107] The transaction abnormality data acquisition module is used to acquire transaction data of application transaction abnormalities during the process of switching the target switching application from the production environment to the disaster recovery environment when the target switching application completes the switching from the production environment to the disaster recovery environment;

[0108] The transaction callback compensation module is used to perform application transaction callback compensation processing based on transaction data through the second distributed transaction platform in the disaster recovery environment.

[0109] Optionally, the device further includes:

[0110] Another transaction control module is used to control the target switching application to subscribe to the first distributed transaction platform in the production environment and initiate a transaction transaction to the first distributed transaction platform when the target switching application switches from the disaster recovery environment to the production environment for distributed transaction processing.

[0111] Optionally, another transaction control module includes:

[0112] a traffic interception unit, configured to intercept transaction traffic of the target switching application when the target switching application is in the process of switching from the disaster recovery environment to the production environment;

[0113] Another stopping and intercepting unit is used to stop intercepting the transaction flow of the target switching application when the target switching application completes switching from the disaster recovery environment to the production environment, and conduct transaction transactions through the first distributed transaction platform.

[0114] The distributed transaction processing apparatus in the disaster recovery switching scenario provided by the embodiment of the present invention can execute the distributed transaction processing method in the disaster recovery switching scenario provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0115] Example 5

[0116] Figure 5 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0117] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0118] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0119] The processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the distributed transaction processing method in a disaster recovery switch scenario.

[0120] In some embodiments, the distributed transaction processing method in the disaster recovery switching scenario can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the distributed transaction processing method in the disaster recovery switching scenario described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to execute the distributed transaction processing method in the disaster recovery switching scenario in any other appropriate manner (for example, by means of firmware).

[0121] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0122] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0123] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0124] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0125] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0126] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0127] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0128] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A distributed transaction processing method in a disaster recovery switching scenario, characterized in that: include: Establish a second distributed transaction platform in the disaster recovery environment that provides equal support to the production environment; When the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application is controlled to subscribe to the second distributed transaction platform in the disaster recovery environment and initiate a transaction to the second distributed transaction platform.

2. The method according to claim 1, characterized in that Initiating a transaction to the second distributed transaction platform includes: When the target switching application is in the process of switching from the production environment to the disaster recovery environment, intercepting the transaction traffic of the target switching application; When the target switching application completes switching from the production environment to the disaster recovery environment, interception of the transaction traffic of the target switching application is stopped, and transaction transactions are performed through the second distributed transaction platform.

3. The method according to claim 2, characterized in that When the target switching application is in the process of switching from the production environment to the disaster recovery environment, the transaction traffic of the target switching application is intercepted, including: Monitor application transaction indicators of target switching applications performing transaction transactions with the first distributed transaction platform in the production environment; When it is determined that the application transaction is abnormal based on the application transaction indicator, it is determined that the target switching application is in the process of switching from the production environment to the disaster recovery environment, and the transaction flow of the target switching application is intercepted.

4. The method according to claim 2, characterized in that Intercepting the transaction traffic of the target switching application, including: intercepting the transaction traffic of the target switching application according to the traffic interception dimension information; The traffic interception dimension information includes: application dimension, group dimension, main transaction method dimension and sub-transaction method dimension.

5. The method according to claim 3, characterized in that Also includes: When the target switching application completes switching from the production environment to the disaster recovery environment, obtaining transaction data of application transaction abnormalities during the process of switching the target switching application from the production environment to the disaster recovery environment; Through the second distributed transaction platform in the disaster recovery environment, application transaction callback compensation processing is performed based on transaction data.

6. The method according to claim 1, wherein Also includes: When the target switching application switches from the disaster recovery environment to the production environment for distributed transaction processing, the target switching application is controlled to subscribe to the first distributed transaction platform in the production environment and initiate a transaction to the first distributed transaction platform.

7. The method according to claim 6, characterized in that Initiating a transaction to the first distributed transaction platform includes: When the target switching application is in the process of switching from the disaster recovery environment to the production environment, intercepting the transaction traffic of the target switching application; When the target switching application completes switching from the disaster recovery environment to the production environment, interception of the transaction traffic of the target switching application is stopped, and transaction transactions are performed through the first distributed transaction platform.

8. A distributed transaction processing system in a disaster recovery switching scenario, characterized in that: The system includes: a production environment and a disaster recovery environment; A first distributed transaction platform is provided in the production environment, and a second distributed transaction platform is provided in the disaster recovery environment to provide peer-to-peer support to the first distributed transaction platform; Applications involved in transaction processing are switched from the production environment to the disaster recovery environment, or from the disaster recovery environment to the production environment, depending on the transaction processing situation. When the target switching application switches from the production environment to the disaster recovery environment for distributed transaction processing, the target switching application subscribes to the second distributed transaction platform in the disaster recovery environment and initiates a transaction to the second distributed transaction platform.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed transaction processing method in the disaster recovery switching scenario described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed transaction processing method in a disaster recovery switching scenario according to any one of claims 1 to 7 when executed.

11. A computer program product, comprising a computer program, wherein when executed by a processor, the computer program implements the distributed transaction processing method in a disaster recovery switching scenario according to any one of claims 1 to 7.

Images