Distributed transaction exception processing method and device, electronic equipment and storage medium
By monitoring and dynamically adjusting the retry waiting time of distributed transactions in real time, combined with system load and historical recovery time, the problem of low efficiency in exception handling in distributed transaction processing is solved, achieving efficient exception transaction management and data consistency, and providing a visualized processing solution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-04-07
AI Technical Summary
Existing distributed transaction processing methods struggle to effectively handle abnormal transactions when faced with network anomalies, node failures, and other factors, leading to issues such as data inconsistency and system congestion. Furthermore, existing solutions suffer from high retry frequencies and low success rates, increasing system burden and lacking visual and traceable processing methods.
By monitoring the execution information of distributed transactions in real time, the retry waiting time is dynamically adjusted. Combined with system load and historical recovery time, the retry interval is dynamically determined. Abnormal transactions are handled by retry or rollback operations, and alarm information is generated and displayed.
It improves the retry success rate of abnormal transactions, reduces system load, ensures data consistency, provides a visual display of abnormal handling information, reduces system maintenance difficulty, supports automatic and manual handling strategies, and improves system stability and availability.
Smart Images
Figure CN121807649A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of distributed transaction processing technology, and in particular to a distributed transaction exception handling method, a distributed transaction exception handling device, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology
[0002] With the rapid development of internet technology, microservice architecture has been widely applied in various large-scale distributed systems. How to achieve data consistency, reliability, and availability in a distributed environment has become a key issue. Traditional monolithic applications can guarantee data consistency through local transactions; however, in microservice architectures, a single business request often requires collaborative processing between multiple services, thus introducing the concept of distributed transactions.
[0003] In practical applications, distributed transactions are susceptible to various factors such as network anomalies, node failures, service timeouts, or code logic errors, leading to transaction failures or partial commits. If these anomalies are not handled promptly, they can cause serious consequences such as data inconsistency, transaction congestion, and system degradation. Existing anomaly handling methods, such as simple automatic retries at fixed times or intervals, or simple failure alerts, often fail to meet complex business requirements and suffer from high retry frequency and low success rates, increasing system load. They are also prone to missed, mishandled, or untraceable issues. Therefore, there is an urgent need for a visualized, traceable, and intervention-enabled distributed transaction anomaly handling solution to enable operations and development personnel to promptly detect, locate, and handle anomalies, ensuring the overall stability and consistency of the system. Summary of the Invention
[0004] This application provides a distributed transaction exception handling method, a distributed transaction exception handling device, an electronic device, a computer-readable storage medium, and a computer program product to solve the problems of low efficiency and difficulty in traceability in existing distributed transaction processing.
[0005] A first aspect of this application provides a distributed transaction exception handling method, comprising: Obtain execution information for each distributed transaction; If the current distributed transaction is determined to be abnormal based on the execution information, the current system load information and the historical recovery time of the current distributed transaction are obtained. The retry waiting time of the current distributed transaction is determined based on the system load information and the historical recovery time. After the retry waiting time, a retry operation is performed on the current distributed transaction until the current distributed transaction eliminates the abnormality. The historical recovery time is the historical time taken for the current distributed transaction to eliminate the abnormality. Alternatively, if the current distributed transaction is determined to be abnormal based on the execution information, a rollback operation is performed on the current distributed transaction to roll back to the state at the specified time point; Furthermore, upon determining that the current distributed transaction is abnormal, an alarm message is generated and the execution information, retry operation information, or rollback operation information of the current distributed transaction are displayed.
[0006] Optionally, the execution information includes at least one of network connection time, service status, and database connection time; determining the current distributed transaction anomaly based on the execution information includes: If the network connection time of the current distributed transaction exceeds the preset network connection time threshold, the current distributed transaction is determined to be abnormal. Alternatively, if the current distributed transaction service status is unavailable, determine that the current distributed transaction is abnormal; Alternatively, if the database connection time of the current distributed transaction exceeds a preset database connection time threshold, the current distributed transaction is determined to be abnormal.
[0007] Optionally, the current system load information and the historical recovery time of the current distributed transaction are obtained, and the retry waiting time of the current distributed transaction is determined based on the system load information and the historical recovery time, including: Get multiple historical recovery times for the current distributed transaction within a specified historical period; The average of the multiple historical recovery times of the current distributed transaction is taken as the current historical recovery time of the current distributed transaction. Determine the current load impact factors based on the current system load information; Determine the base waiting time, and based on the base waiting time and the current historical recovery time, determine the current historical recovery time influencing factor; Generate random jitter values within a specified range, and determine the retry wait time for the current distributed transaction based on the base wait time, load impact factor, historical recovery time impact factor, and random jitter values.
[0008] Optionally, the current load impact factors are determined based on the current system load information, including: Determine the baseline value of the load impact factor, and determine the current adjustment value of the load impact factor based on the current system load information, so that the adjustment value of the load impact factor increases as the load value corresponding to the current system load information increases; The current load impact factor is the sum of the baseline value of the load impact factor and the current adjusted value of the load impact factor. Based on the aforementioned baseline waiting time and current historical recovery time, the current historical recovery time influencing factors are determined, including: Determine the baseline value for the historical recovery time impact factor; The ratio of the baseline waiting time to the current historical recovery time is determined as the current historical recovery time impact factor determination value; The smaller of the historical recovery time impact factor baseline value and the current historical recovery time impact factor determination value is determined as the current historical recovery time impact factor.
[0009] Optionally, a base waiting time is determined, including: Determine the reference delay time and the reference delay multiple; Obtain the current retry count of the current distributed transaction, and construct a dynamic index of the baseline latency multiple based on the current retry count of the current distributed transaction, so that the dynamic index of the baseline latency multiple increases as the current retry count of the current distributed transaction increases; The current adjustment value of the reference delay time is determined by exponentiation of the reference delay multiple based on the dynamic exponent of the reference delay multiple. The baseline delay time is obtained by weighting the current adjustment value.
[0010] Optionally, the retry wait time for the current distributed transaction is determined based on the base wait time, load impact factor, historical recovery time impact factor, and random jitter value, including: The retry waiting time of the current distributed transaction is obtained by weighting the base waiting time with the load impact factor, the historical recovery time impact factor, and the random jitter value.
[0011] Optionally, after performing a retry operation on the current distributed transaction, the method further includes: If the abnormal state of the current distributed transaction is not eliminated after the retry operation, determine that the execution status of the current retry operation is that the retry operation failed, and return to the step of obtaining the current system load information and the historical recovery time of the current distributed transaction. If the number of failed retry operations of the current distributed transaction reaches the preset retry operation threshold, the historical recovery time of the current distributed transaction is weighted by a specified multiple to determine the circuit breaker time of the current distributed transaction. After the circuit breaker period, return to the steps of obtaining the current system load information and the historical recovery time of the current distributed transaction, and repeat the above process until the current distributed transaction eliminates the anomaly.
[0012] A second aspect of this application provides a distributed transaction exception handling apparatus, comprising: The data acquisition module is configured to obtain execution information for each distributed transaction; The distributed transaction processing module is configured to, if it is determined that the current distributed transaction is abnormal based on the execution information, obtain the current system load information and the historical recovery time of the current distributed transaction, determine the retry waiting time of the current distributed transaction based on the system load information and the historical recovery time, and after the retry waiting time, perform a retry operation on the current distributed transaction until the current distributed transaction eliminates the abnormality, wherein the historical recovery time is the historical time taken for the current distributed transaction to eliminate the abnormality; or If the current distributed transaction is determined to be abnormal based on the execution information, a rollback operation is performed on the current distributed transaction to roll back to the state at the specified time point. The alarm module is configured to generate alarm information and display the execution information, retry operation information, or rollback operation information of the current distributed transaction after determining that the current distributed transaction is abnormal.
[0013] A third aspect of this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method described above.
[0014] In a fourth aspect, this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described above.
[0015] In a fifth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0016] This application monitors the execution information of each distributed transaction in real time. After determining that the current distributed transaction is abnormal based on the monitoring information, it dynamically adjusts the retry operation waiting time of the current distributed transaction according to the system load and the historical recovery time of the current distributed transaction. This allows for the dynamic determination of the interval between each retry based on the current system state and the historical recovery time of the current distributed transaction, thereby reducing the number of retries and improving the retry success rate. This avoids the problem of multiple abnormal distributed transactions performing retry operations simultaneously when the system load is high, which would cause the system load to increase. The rollback operation can ensure the data consistency of distributed transactions that cannot eliminate abnormalities through retries. At the same time, it can display the abnormal information and abnormal handling operation information of distributed transactions. Attached Figure Description
[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0018] Figure 1 This is a flowchart of a distributed transaction exception handling method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a microservice system architecture provided in an embodiment of this application; Figure 3 This is a logic diagram for distributed transaction exception handling provided in an embodiment of this application; Figure 4 A schematic block diagram of a distributed transaction exception handling device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0019] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0020] 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. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0021] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.
[0022] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application. It is understood that in the technical solutions of this application, the acquisition, collection, storage, use, processing, transmission, provision, disclosure, and application of data all comply with the provisions of relevant laws and regulations. It should be noted that in the embodiments of this application, certain software, components, models, and other existing industry solutions may be mentioned. These should be considered exemplary, and their purpose is merely to illustrate the feasibility of implementing the technical solutions of this application, but does not mean that the applicant has already used or necessarily used such solutions.
[0023] Existing distributed transaction frameworks can only display simple transaction data and status through a management interface. Because they cannot monitor distributed transactions in real time or display complete call chains, it is often difficult to troubleshoot truly complex transactions (such as those spanning multiple services and involving mutual calls) to verify the correctness of the transaction chain or analyze the causes of abnormal transaction failures. Furthermore, existing distributed transaction frameworks focus on transaction management and synchronization during "online" periods, lacking systematic archiving, auditing, and analysis methods for completed abnormal transactions, resulting in a lack of effective data support for subsequent tracing and improvement strategies. In addition, current solutions are inadequate in handling abnormal transaction recovery. For example, after the compensation logic is executed, is it necessary to further verify the consistency of business data, and how to trigger a secondary alert when inconsistencies recur? Existing technologies have not yet proposed systematic solutions for these issues. Therefore, while existing technologies achieve distributed transaction management and anomaly handling to some extent, they cannot meet the higher demands for high availability, high reliability, and visualized management of microservice systems.
[0024] To solve the above problems, such as Figure 1 As shown, the first aspect of this application provides a distributed transaction exception handling method, comprising: S100, Obtain the execution information of each distributed transaction; S200. If the current distributed transaction is determined to be abnormal based on the execution information, obtain the current system load information and the historical recovery time of the current distributed transaction, determine the retry waiting time of the current distributed transaction based on the system load information and the historical recovery time, and perform a retry operation on the current distributed transaction after the retry waiting time until the current distributed transaction eliminates the abnormality. The historical recovery time is the historical time taken for the current distributed transaction to eliminate the abnormality. Alternatively, if the current distributed transaction is determined to be abnormal based on the execution information, a rollback operation is performed on the current distributed transaction to roll back to the state at the specified time point; S300: After determining that the current distributed transaction is abnormal, generate alarm information and display the execution information, retry operation information or rollback operation information of the current distributed transaction.
[0025] Thus, this application monitors the execution information of each distributed transaction in real time. After determining that the current distributed transaction is abnormal based on the monitoring information, it dynamically adjusts the retry operation waiting time of the current distributed transaction according to the system load and the historical recovery time of the current distributed transaction. This allows for the dynamic determination of the interval between each retry based on the current system state and the historical recovery time of the current distributed transaction, thereby reducing the number of retries and improving the retry success rate. This avoids the problem of high system load caused by multiple abnormal distributed transactions performing retry operations simultaneously when the system load is high. The rollback operation can ensure the data consistency of distributed transactions that cannot eliminate abnormalities through retries, and can also display the abnormal information and abnormal handling operation information of distributed transactions.
[0026] Understandable, such as Figure 2As shown, in a microservice architecture, after services A, B, and C register with the microservice gateway, they can perform transaction processing through the microservice architecture. For example, a distributed transaction is initiated by service A, which can invoke services B and C. Services A, B, and C can access the distributed transaction server through the transaction client SDK. The distributed transaction server includes various components, such as a transaction coordination module, a transaction monitoring module, an exception handling module, a recovery verification module, an auditing and logging module, and a storage module. Specifically, the transaction coordination module coordinates the execution of each microservice; the transaction monitoring module monitors the execution information of each distributed service; the exception handling module handles retry or rollback strategies for abnormal transactions; the recovery verification module recovers or verifies data from abnormal transactions; the auditing and logging module analyzes log information of distributed transactions, such as execution information; and the storage module stores execution information, retry operations, or rollback operations for abnormal transactions. In detail, during execution, the transaction monitoring module continuously tracks the transaction status. Once an exception occurs, the exception handling module handles it according to a preset strategy, and then the recovery and verification module ensures data consistency. The entire process is recorded by the audit and log module, forming a closed-loop management system.
[0027] In step S100, this application deploys a monitoring component (or introduces a dedicated SDK into the business code) on each service node or gateway layer of the microservice architecture to collect and record the execution information of each distributed transaction. This monitoring component can obtain information such as the transaction ID, initiating service, participating services, execution progress, and results of the distributed transaction in real time, and maintains heartbeat communication with the distributed monitoring server. Once a timeout or anomaly is detected, it immediately reports to the monitoring server. The execution information of the distributed transaction includes, but is not limited to, network connection time, service status, and database connection time.
[0028] In this application, the execution information of each distributed transaction is stored in a distributed log system or a backend server. The backend server analyzes the execution information of each transaction, such as transaction logs, based on preset rules (such as timeout thresholds, retry counts, and call chain depth) or machine learning algorithms. Once an abnormal transaction is detected, an abnormal event record is generated, and an alarm notification is sent to the operations and maintenance personnel via telephone, SMS, or email. In addition, the system can automatically execute some preset strategies, such as rapid retries or marking the transaction status as "requiring manual intervention".
[0029] In step S200, determining the current distributed transaction as abnormal based on execution information includes: determining the current distributed transaction as abnormal if the network connection time of the current distributed transaction is greater than a preset network connection time threshold; or, determining the current distributed transaction as abnormal if the service status of the current distributed transaction is unavailable; or, determining the current distributed transaction as abnormal if the database connection time of the current distributed transaction is greater than a preset database connection time threshold; or, determining the current distributed transaction as abnormal if the current transaction execution times out.
[0030] In this application, if any distributed transaction is found to be abnormal based on the execution information of each distributed transaction—for example, if the execution time of a distributed transaction is detected to exceed a preset execution time threshold—then the current system load information and the historical recovery time of the current distributed transaction are obtained. The system load information may include the processor utilization rate, memory utilization rate, and / or the current network latency of the server. Determining the retry waiting time of the current distributed transaction based on the system load information and historical recovery time includes: S210. Obtain multiple historical recovery times for the current distributed transaction within a specified historical period. For example, if service A experiences N exceptions within a specified historical period, obtain the historical recovery time taken for service A from the detection of the exception to its elimination each time within that historical period, resulting in N historical recovery times.
[0031] S220. The average of multiple historical recovery times of the current distributed transaction is used as the current historical recovery time of the current distributed transaction. For example, the average of N historical recovery times of service A within a historical period is calculated as the current historical recovery time of service A.
[0032] S230. Determine the current load impact factor based on the current system load information.
[0033] Specifically, the current load impact factor is determined through the following steps: S231. Determine the baseline value of the load impact factor. For example, determine the baseline value of the load impact factor as 1. Based on the current system load information, determine the current load impact factor adjustment value so that the load impact factor adjustment value increases with the increase of the load value corresponding to the current system load information. For example, the load impact factor adjustment value = (current load - 50) / 100.
[0034] S232. The current load impact factor is the sum of the baseline load impact factor and the current adjusted load impact factor. Specifically, the load impact factor = 1 + (current load - 50) / 100. If the current server processor load is 50%, the adjusted load impact factor is 0, and the load impact factor is 1.
[0035] The historical recovery time influencing factors are determined based on the baseline waiting time and the current historical recovery time, including: S233. Determine the baseline value of the historical recovery time impact factor. For example, determine the baseline value of the historical recovery time impact factor to be 2.
[0036] S234. The ratio of the basic waiting time to the current historical recovery time is determined as the current historical recovery time influence factor judgment value.
[0037] S235. Determine the smaller of the historical recovery time impact factor baseline value and the current historical recovery time impact factor judgment value as the current historical recovery time impact factor. For example, historical recovery time impact factor = min(2, baseline waiting time / current historical recovery time).
[0038] S240. Determine the basic waiting time, and determine the current historical recovery time influencing factor based on the basic waiting time and the current historical recovery time.
[0039] The determination of the base waiting time includes: determining the baseline delay time and the baseline delay multiple; obtaining the current number of retry operations for the current distributed transaction, and constructing a dynamic exponent of the baseline delay multiple based on the current number of retry operations for the current distributed transaction, so that the dynamic exponent of the baseline delay multiple increases with the increase of the current number of retry operations for the current distributed transaction; performing an exponentiation operation on the baseline delay multiple based on the dynamic exponent of the baseline delay multiple to determine the current adjustment value of the baseline delay time; and weighting the baseline delay time with the current adjustment value to obtain the base waiting time. For example, in this application, the base waiting time = baseline delay time × baseline delay multiple ^ (current number of retry operations - 1). In this way, for the current distributed transaction, the more retry operations, the longer the base waiting time, thereby avoiding the situation where multiple distributed transactions need to perform retry operations, resulting in a large number of retry operations submitted by each distributed transaction at the same time, leading to high server load and low transaction processing efficiency.
[0040] S250. Generate a random jitter value within a specified range, and determine the retry wait time for the current distributed transaction based on the base wait time, load impact factor, historical recovery time impact factor, and random jitter value. The random jitter value can be a random number between 0.8 and 1.2. Determining the retry wait time for the current distributed transaction based on the base wait time, load impact factor, historical recovery time impact factor, and random jitter value includes: weighting the base wait time with the load impact factor, historical recovery time impact factor, and random jitter value to obtain the retry wait time for the current distributed transaction. Specifically, retry wait time = base wait time × load impact factor × historical recovery time impact factor × random jitter value.
[0041] In this way, when each abnormal transaction performs a retry operation, this application dynamically determines the retry waiting time of the current transaction in real time based on the current load and the historical recovery time of the current transaction. Compared with the existing technology's fixed waiting time and fixed number of retry operation strategies, this can effectively avoid the situation where multiple abnormal transactions perform transaction retry operations at the same time, thereby reducing system load and improving the retry efficiency of each transaction.
[0042] The method of this application further includes the following steps after performing a retry operation on the current distributed transaction: if the abnormal state of the current distributed transaction is not eliminated after the retry operation, the execution status of the current retry operation is determined to be a retry operation failure, and the method returns to the step of obtaining the current system load information and the historical recovery time of the current distributed transaction; if the number of retry operation failures of the current distributed transaction reaches a preset retry operation number threshold, the historical recovery time of the current distributed transaction is weighted by a specified multiple to determine the circuit breaker time of the current distributed transaction; after the circuit breaker time, the method returns to the step of obtaining the current system load information and the historical recovery time of the current distributed transaction, and the above process is repeated until the abnormality of the current distributed transaction is eliminated. For example, after each failed retry operation, step S200 is repeated to obtain the current system load information and the historical recovery time of the current distributed transaction. Based on the system load information and the historical recovery time, the retry waiting time for the current distributed transaction is determined. After the retry waiting time, the retry operation is performed on the current distributed transaction. If the number of failed retryes reaches a threshold, the historical recovery time of the current distributed transaction is weighted by a specified multiple, such as n times. That is, the circuit breaker time for the current transaction is n × the historical recovery time of the current distributed transaction. During this time period, no further retry operations are performed on the current distributed transaction. In this way, through the dynamic circuit breaker mechanism, some abnormal transactions that are difficult to recover can be isolated or degraded, thereby improving the overall system efficiency.
[0043] Understandably, if an abnormal transaction fails to eliminate the anomaly after multiple retries and circuit breakers, or if certain distributed transactions are not suitable for retry operations, a rollback operation can be performed on the abnormal transaction, reverting its state to a previous point in time. This rollback operation can be performed automatically or manually through the system's management interface. This application allows the management interface to display detailed information about abnormal transactions, including the transaction ID, service node, execution time, call chain, and cause of the anomaly. The management interface has search and filtering functions, allowing users to locate abnormal transactions based on transaction ID, service name, transaction status, etc.; it also has anomaly transaction analysis functions, displaying detailed call paths of distributed transactions and highlighting abnormal branch paths. Specifically, the management interface can be implemented via a web application or a standalone client. Through the management interface, key information about all abnormal transactions is visualized, including: transaction ID, initiation time, current status; involved service nodes and call chains; failure reasons and log information; risk level and potential impact. Operations personnel can search, filter, and sort on the management interface to quickly locate target abnormal transactions.
[0044] The management interface allows you to configure processing strategies for each transaction. For example, this application provides the following processing options in the management interface: Automatic retry: If it can be determined that the abnormal transaction is caused by network jitter or temporary service unavailability, it can be retried immediately or after a delay through automatic policies.
[0045] Manual compensation and rollback: For complex business processes that cannot be easily retried, a manual compensation function is provided. Operations personnel or authorized technical personnel can achieve data consistency by inputting compensation commands through the management interface to call the compensation interface or by performing database rollback operations, based on the business logic.
[0046] Risk isolation: When large-scale transaction anomalies are detected, operations and maintenance personnel can implement degradation or isolation policies for specific services (such as shutting down specific instances or limiting rates) with one click on the management interface to avoid the spread of large-scale failures.
[0047] like Figure 3As shown, once a global transaction is initiated, it is executed through various branch transactions. That is, a global transaction typically consists of a set of branch transactions. For example, a global transaction for placing an order might include two branch transactions: creating the order and deducting inventory. Alternatively, in a financial system containing two microservices: Account A (database DB_A) and Account B (database DB_B), the business requirement is that a user transfers 100 yuan from Account A to Account B. The transfer of 100 yuan is the global transaction. Branch transaction 1 deducts 100 yuan from Account A (executed on DB_A); branch transaction 2 deposits 100 yuan into Account B (executed on DB_B). If all branch transactions execute successfully, the global transaction is completed. If any branch transaction fails, an exception alarm is generated, and automatic retry or manual repair operations are performed on the branch transaction. If the automatic retry or manual repair operation succeeds, the global transaction is completed. After a transaction is retried or compensated, the system automatically checks whether the data status of each related service is consistent with expectations to verify the consistency of processed abnormal transactions and ensure that the data returns to the expected state. If discrepancies exist, the system triggers an alarm again, requiring secondary processing or manual review. The data verification process can be implemented by comparing the business database or distributed cache, or by using a dedicated auditing service for consistency checks.
[0048] In this application, the processing and results of all abnormal transactions are recorded in a log database, including the handler, processing time, strategy used, and final state, to provide data support for adjusting subsequent abnormal transaction handling strategies. These historical records can be used for data mining in the future to identify periods, business scenarios, and root causes of concentrated anomalies, further optimizing the system architecture or adjusting fault tolerance strategies.
[0049] Compared with existing technologies, this application provides a real-time monitoring and alarm mechanism that enables operations and maintenance personnel to promptly detect and locate distributed transaction anomalies, shortening fault handling time. Simultaneously, it offers a visual and traceable display of abnormal transaction information and diverse operation entry points through a management interface, reducing system maintenance difficulty. It allows for flexible combinations of various processing strategies, such as automatic retries, manual compensation, and risk isolation, to meet the needs of different business scenarios and improve system stability and availability. It achieves final data consistency through recovery and verification processes, reducing the risk of business data anomalies. Furthermore, historical records and anomaly analysis provide a basis for decision-making regarding subsequent system upgrades and improvements to anomaly handling strategies, enabling continuous optimization.
[0050] like Figure 4 As shown, in a second aspect, this application provides a distributed transaction exception handling apparatus, comprising: The data acquisition module is configured to obtain execution information for each distributed transaction; The distributed transaction processing module is configured to, if an anomaly is determined in the current distributed transaction based on execution information, obtain the current system load information and the historical recovery time of the current distributed transaction, determine the retry waiting time for the current distributed transaction based on the system load information and the historical recovery time, and after the retry waiting time, perform a retry operation on the current distributed transaction until the anomaly is eliminated. The historical recovery time is the historical time taken for the current distributed transaction to eliminate the anomaly. Alternatively... If the current distributed transaction is determined to be abnormal based on the execution information, a rollback operation is performed on the current distributed transaction to roll it back to the state at the specified time point. The alarm module is configured to generate alarm information and display the execution information, retry operation information, or rollback operation information of the current distributed transaction after determining that the current distributed transaction is abnormal.
[0051] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing elements; they can be fully implemented in hardware; or some modules can be implemented by processing elements calling software, while others are implemented in hardware. For example, the data acquisition module can be a separate processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.
[0052] A third aspect of this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method described above.
[0053] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device may include: transceiver 121, processor 122, and memory 123.
[0054] Processor 122 executes computer execution instructions stored in memory, causing processor 122 to perform the scheme in the above embodiments. Processor 122 may be a general-purpose processor, including CPU, network processor (NP), etc.; it may also be a digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0055] The memory 123 is connected to the processor 122 via the system bus and completes communication between them. The memory 123 is used to store computer program instructions.
[0056] Transceiver 121 can be used to obtain the task to be run and its configuration information.
[0057] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.
[0058] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments.
[0059] In a fourth aspect, this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described above.
[0060] In a fifth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0061] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0062] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A distributed transaction exception handling method, characterized in that, include: Obtain execution information for each distributed transaction; If the current distributed transaction is determined to be abnormal based on the execution information, the current system load information and the historical recovery time of the current distributed transaction are obtained. The retry waiting time of the current distributed transaction is determined based on the system load information and the historical recovery time. After the retry waiting time, a retry operation is performed on the current distributed transaction until the current distributed transaction eliminates the abnormality. The historical recovery time is the historical time taken for the current distributed transaction to eliminate the abnormality. Alternatively, if the current distributed transaction is determined to be abnormal based on the execution information, a rollback operation is performed on the current distributed transaction to roll back to the state at the specified time point; Furthermore, upon determining that the current distributed transaction is abnormal, an alarm message is generated and the execution information, retry operation information, or rollback operation information of the current distributed transaction are displayed.
2. The distributed transaction exception handling method according to claim 1, characterized in that, The execution information includes at least one of network connection time, service status, and database connection time; Determining the current distributed transaction exception based on the execution information includes: If the network connection time of the current distributed transaction exceeds the preset network connection time threshold, the current distributed transaction is determined to be abnormal. Alternatively, if the current distributed transaction service status is unavailable, determine that the current distributed transaction is abnormal; Alternatively, if the database connection time of the current distributed transaction exceeds a preset database connection time threshold, the current distributed transaction is determined to be abnormal.
3. The distributed transaction exception handling method according to claim 1, characterized in that, Obtain current system load information and historical recovery time of the current distributed transaction, and determine the retry waiting time of the current distributed transaction based on the system load information and the historical recovery time, including: Get multiple historical recovery times for the current distributed transaction within a specified historical period; The average of the multiple historical recovery times of the current distributed transaction is taken as the current historical recovery time of the current distributed transaction. Determine the current load impact factors based on the current system load information; Determine the base waiting time, and based on the base waiting time and the current historical recovery time, determine the current historical recovery time influencing factor; Generate random jitter values within a specified range, and determine the retry wait time for the current distributed transaction based on the base wait time, load impact factor, historical recovery time impact factor, and random jitter values.
4. The distributed transaction exception handling method according to claim 3, characterized in that, Based on the current system load information, determine the current load impact factors, including: Determine the baseline value of the load impact factor, and determine the current adjustment value of the load impact factor based on the current system load information, so that the adjustment value of the load impact factor increases as the load value corresponding to the current system load information increases; The current load impact factor is the sum of the baseline value of the load impact factor and the current adjusted value of the load impact factor. Based on the aforementioned baseline waiting time and current historical recovery time, the current historical recovery time influencing factors are determined, including: Determine the baseline value for the historical recovery time impact factor; The ratio of the baseline waiting time to the current historical recovery time is determined as the current historical recovery time impact factor determination value; The smaller of the historical recovery time impact factor baseline value and the current historical recovery time impact factor determination value is determined as the current historical recovery time impact factor.
5. The distributed transaction exception handling method according to claim 3, characterized in that, Determine the base waiting time, including: Determine the reference delay time and the reference delay multiple; Obtain the current retry count of the current distributed transaction, and construct a dynamic index of the baseline latency multiple based on the current retry count of the current distributed transaction, so that the dynamic index of the baseline latency multiple increases as the current retry count of the current distributed transaction increases; The current adjustment value of the reference delay time is determined by exponentiation of the reference delay multiple based on the dynamic exponent of the reference delay multiple. The baseline delay time is obtained by weighting the current adjustment value.
6. The distributed transaction exception handling method according to claim 3, characterized in that, The retry wait time for the current distributed transaction is determined based on the aforementioned base wait time, load impact factor, historical recovery time impact factor, and random jitter value, including: The retry waiting time of the current distributed transaction is obtained by weighting the base waiting time with the load impact factor, the historical recovery time impact factor, and the random jitter value.
7. The distributed transaction exception handling method according to claim 1, characterized in that, After performing a retry operation on the current distributed transaction, the method further includes: If the abnormal state of the current distributed transaction is not eliminated after the retry operation, determine that the execution status of the current retry operation is that the retry operation failed, and return to the step of obtaining the current system load information and the historical recovery time of the current distributed transaction. If the number of failed retry operations of the current distributed transaction reaches the preset retry operation threshold, the historical recovery time of the current distributed transaction is weighted by a specified multiple to determine the circuit breaker time of the current distributed transaction. After the circuit breaker period, return to the steps of obtaining the current system load information and the historical recovery time of the current distributed transaction, and repeat the above process until the current distributed transaction eliminates the anomaly.
8. A distributed transaction exception handling device, characterized in that, include: The data acquisition module is configured to obtain execution information for each distributed transaction; The distributed transaction processing module is configured to, if it is determined that the current distributed transaction is abnormal based on the execution information, obtain the current system load information and the historical recovery time of the current distributed transaction, determine the retry waiting time of the current distributed transaction based on the system load information and the historical recovery time, and after the retry waiting time, perform a retry operation on the current distributed transaction until the current distributed transaction eliminates the abnormality, wherein the historical recovery time is the historical time taken for the current distributed transaction to eliminate the abnormality; or If the current distributed transaction is determined to be abnormal based on the execution information, a rollback operation is performed on the current distributed transaction to roll back to the state at the specified time point. The alarm module is configured to generate alarm information and display the execution information, retry operation information, or rollback operation information of the current distributed transaction after determining that the current distributed transaction is abnormal.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as claimed in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.
11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.