Distributed transaction compensation method and system based on compensation feasibility matrix

Abstract

This invention belongs to the field of distributed business technology and relates to a distributed transaction compensation method and system based on a compensation feasibility matrix. The compensation method includes identifying failed transactions, defining business process boundaries, generating a list of operation parameters, obtaining candidate positive-compensation relationships, constructing a compensation feasibility matrix representing different compensation paths, setting the state of matrix elements, matching the positive operation links of new failed transactions with the compensation feasibility matrix to select compensation operations, performing anti-duplication repair checks, executing the selected compensation operations, performing post-verification, and updating and optimizing the compensation feasibility matrix based on the execution results of the compensation operations. The compensation system includes modules for failed transaction identification, process boundary definition, operation candidate generation, compensation feasibility matrix construction, matrix element state setting, compensation operation selection, compensation operation verification, updating, and optimization. This invention can automatically identify business failure scenarios and automatically match and filter the optimal compensation path in the matrix.

Description

Technical Field

[0001] This invention belongs to the field of distributed business technology, and in particular relates to a distributed transaction compensation method and system based on a compensation feasibility matrix. Background Technology

[0002] With the widespread application of internet technology and distributed architecture, modern business systems, such as e-commerce, finance, and logistics systems, are typically composed of multiple microservices. For complex business processes, to ensure consistency in distributed transactions, the industry commonly uses patterns such as TCC (Try-Confirm-Cancel) and Saga for business compensation. These patterns, when a step in the business process fails, execute the opposite compensation operation to roll back the steps that were previously executed successfully, thereby avoiding data inconsistency (for example, if an order is created and then canceled, the TCC pattern returns the locked inventory for that order to an unlocked state, preventing inconsistencies between the order status and inventory).

[0003] However, existing compensation techniques have the following drawbacks: 1. Regarding business compensation, the current mainstream practice is for developers to explicitly declare compensation methods in the code through annotations or configuration files. This approach heavily relies on the developer's experience and coding standards. For the transformation of old systems (referring to the transformation of existing business systems that did not previously have a compensation mechanism, adding a compensation mechanism), there is often a lack of standard compensation entry points, requiring a large amount of manual intervention, resulting in extremely high governance costs.

[0004] 2. The compensation operation lacks a secure closed loop, resulting in weak risk control capabilities. Existing compensation frameworks typically focus only on "execution," neglecting the mandatory constraints of "validation" and "duplicate prevention." Many solutions determine compensation success solely based on the interface return code (such as HTTP 200), lacking post-validation of the actual state of business data. Furthermore, due to the lack of global idempotent control and state machine management, duplicate compensations (such as duplicate refunds or duplicate inventory releases) or invalid compensations are prone to occur, introducing secondary errors into the business.

[0005] 3. Blurred business process boundaries lead to a high rate of misjudgment. Complex call chains contain a large number of business operations and operational tasks (such as logging, monitoring, and auditing). Existing technologies often cannot accurately distinguish between "core business resource actions" and "non-business actions." This can lead to the incorrect inclusion of operational actions in compensation matching when generating compensation plans, or the inability to accurately reconstruct the actual execution path before failure due to the disconnection of trace IDs in asynchronous scenarios, resulting in incorrect compensation decisions.

[0006] 4. Lack of self-healing and evolutionary capabilities. Traditional compensation mechanisms are one-off; if a compensation operation fails, the system usually only logs or issues an alert, without feeding the experience of the failure into the rule base.

[0007] The system cannot automatically learn which compensation combinations are high-risk and which parameters are frequently missing, which may cause the same error to occur repeatedly and prevent the formation of a closed loop of "execution-feedback-optimization".

[0008] In summary, existing technologies lack a universal solution capable of automatically identifying business logic, accurately matching compensation schemes, and possessing a robust security verification mechanism. Therefore, a new technical solution is urgently needed to address these issues and achieve fully automated, highly reliable repair of business anomalies. Summary of the Invention

[0009] To address the aforementioned technical problems, this invention discloses a distributed transaction compensation method based on a compensation feasibility matrix, comprising the following steps: Step 1: Identify failed business transactions from existing business data; Step 2: Explicitly code the failed business processes and define the business process boundaries; Step 3: Filter and remove maintenance operations from failed services, keeping only service operations; Step 4: Calculate the positive candidate score and compensation candidate score of the business operation, and classify the business operation into positive operation candidates or compensation operation candidates; Step 5: Identify the operation parameters of the business operation, generate an operation parameter list, and identify the post-validation operation; Step 6: Calculate the matching score between the forward operation candidate and the compensation operation candidate to obtain the forward-compensation relationship candidate; Step 7: Write the forward operation candidates, compensation operation candidates, operation parameter list, and forward-compensation relationship candidates into the compensation feasibility matrix representing different compensation paths; Step 8: Manually confirm the compensation feasibility matrix and set the status of matrix elements based on the confirmation results; Step 9: When a new failed service occurs, generate a positive operation link for the new failed service, record the new failure information, identify the operation execution status, and mark the operation. Step 10: Match the forward operation links of the new failed business with the compensation feasibility matrix, find the forward-compensation relationship candidates corresponding to the successfully executed forward operations, determine the feasibility and classify the execution level, and select the compensation operation according to the execution level from high to low and the matching score from high to low. Step 11: Perform anti-duplicate repair verification; Step 12: Perform the selected compensation operation; Step 13: Perform post-verification to check if the compensation operation is successful. If the post-verification fails, proceed to retry, manual confirmation, or freeze the matrix. If the post-verification status is unknown, proceed to wait, asynchronous re-verification, or manual confirmation. If the post-verification passes, mark the compensation operation as successful. Step 14: Update and optimize the compensation feasibility matrix based on the results of the compensation operation.

[0010] Preferably, in step 2, the business process boundaries of failed businesses are defined by calling chain aggregation and business key aggregation.

[0011] Preferably, in step 4, the scoring factors for positive candidate scores and compensation candidate scores include: the path of the operation, whether it is a real business resource operation, whether it affects business objects, whether there is a business primary key, whether there is an interface contract, whether there is a message contract, whether there are idempotent clues, and whether it hits hard exclusion and soft penalty.

[0012] Preferably, in step 7, each matrix element in the compensation feasibility matrix contains at least the following: process code, forward action code, compensation operation code, forward-compensation relationship candidate, confirmation source, parameter list, idempotent rule, fallback rule, execution level, risk score, credibility score, historical success rate, post-verification pass rate, and matrix status; in step 8, the matrix element status includes: candidate, confirmed, enabled, confirmation conflict, requires re-verification, frozen, and disabled.

[0013] Preferably, in step 10, by using the forward operation code in the forward operation chain of the new failed business, all candidate compensation relationships corresponding to the forward operation are found from the compensation feasibility matrix. Then, based on the matrix status, pre-verification, parameter completeness, and risk strategy, a comprehensive score is given, and the compensation operation with the highest score is selected. The feasibility is determined and the execution level is defined based on the matrix element status, pre-verification, parameter completeness, risk strategy, and execution level.

[0014] Preferably, in step 14, if the compensation operation is successfully executed and the post-verification passes, the failed business, the positive operation information in the business, and the compensation operation information are written into the compensation feasibility matrix; if the compensation operation fails, the matrix element where the compensation operation is located is updated, and the matrix relationship is downgraded or frozen in the compensation feasibility matrix.

[0015] A distributed transaction compensation system based on a compensation feasibility matrix, used to implement the aforementioned distributed transaction compensation method based on a compensation feasibility matrix, includes: The failed service identification module is used to identify failed services from existing service data; The process boundary delineation module is used to explicitly code failed business processes and delineate business process boundaries. The operation candidate generation module is used to filter and remove operation and maintenance operations from failed services, retaining only business operations; it calculates the positive candidate score and compensation candidate score of business operations, and classifies business operations into positive operation candidates or compensation operation candidates. The compensation feasibility matrix construction module is used to identify the operation parameters of business operations, generate an operation parameter list, identify post-verification operations, calculate the matching score between forward operation candidates and compensation operation candidates, obtain forward-compensation relationship candidates, and write the forward operation candidates, compensation operation candidates, operation parameter list and forward-compensation relationship candidates into the compensation feasibility matrix representing different compensation paths. The matrix element status setting module is used for manual confirmation of the compensation feasibility matrix and setting the matrix element status based on the confirmation result. The compensation operation selection module is used to generate a forward operation link for a new failed service when a new failed service occurs, record the new failure information, identify the operation execution status and mark the operation; match the forward operation link of the new failed service with the compensation feasibility matrix, find the forward-compensation relationship candidates corresponding to the successfully executed forward operations, determine the feasibility and classify the execution level, and select the compensation operation according to the execution level from high to low and the matching score from high to low. The compensation operation verification module is used to prevent duplicate repair verification; it executes the selected compensation operation; it performs a post-verification to check whether the compensation operation is successful. If the post-verification fails, it proceeds to retry, manual confirmation, or freeze the matrix. If the post-verification status is unknown, it proceeds to wait, asynchronous re-verification, or manual confirmation. If the post-verification passes, the compensation operation is marked as successful. The update and optimization module is used to update and optimize the compensation feasibility matrix based on the results of the compensation operation.

[0016] The beneficial effects of this invention are: This invention abandons the existing model that relies on developers to explicitly declare compensation methods through code. Instead, it innovatively constructs a compensation feasibility matrix for compensation decisions. The system can automatically identify business failure scenarios, automatically match and filter the optimal compensation path within the matrix, greatly reducing reliance on developer experience and manual configuration. Especially for the transformation of complex legacy systems, it can achieve automatic repair of business anomalies without large-scale, intrusive code modifications, significantly reducing system governance costs and maintenance difficulty. Furthermore, this invention, through a positive cycle of "execution-feedback-optimization," enables the compensation feasibility matrix to dynamically evolve, continuously correcting and improving the matrix element information based on the results of each compensation operation, thereby continuously improving the reliability of compensation. Attached Figure Description

[0017] Figure 1 This is a flowchart of a distributed transaction compensation method based on a compensation feasibility matrix according to Embodiment 1 of the present invention. Detailed Implementation

[0018] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] Example 1

[0020] like Figure 1 As shown, Embodiment 1 of the present invention provides a distributed transaction compensation method based on a compensation feasibility matrix, comprising the following steps: Step 1: Identify failed business transactions from existing business data.

[0021] The existing business data includes business data that has been confirmed to be correct in the old system, as well as business data generated during system operation that has been manually coded through annotations, interface contracts, or message contracts.

[0022] The term "failed business" refers to a scenario in which certain operations in a business process have already had a business impact, but subsequent operations fail, leading to inconsistent business scenarios in the system. Examples include "inventory deduction failed after order creation was successful," "payment request was sent but local order status update failed," "MQ message was sent but downstream consumption failed," and "Redis business lock was acquired but subsequent business execution failed."

[0023] Specific methods for identifying failed business processes include status inconsistency detection, process break detection, data missing / data conflict detection, or timeout detection. For example, detecting an order status of "cancelled" but the inventory status not being restored, or detecting two mutually exclusive statuses for the same order.

[0024] By following the steps above, compensation is only provided for failed transactions, avoiding the use of all operations across the entire system for compensation matching and reducing the scope of misjudgments.

[0025] Step 2: Explicitly code the failed business processes, define the business process boundaries, and identify the failure information.

[0026] Specifically, the following steps are included: Step 21: By aggregating call chains and business keys, delineate the business process boundaries of failed business processes and generate a list of operations within the process.

[0027] The call chain aggregation includes the following steps: reconstructing the call chain in a request based on traceId, spanId, or parentSpanId, and aggregating database writes, API calls, Redis writes, and MQ sending that occur in the same business request into the same business process.

[0028] In asynchronous message queue (MQ) scenarios, traceIds for the same business might be disconnected, necessitating business key aggregation. Business key aggregation refers to using fields such as orderNo, paymentNo, businessKey, messageKey, topic, tag, and messageType (based on annotations, unique indexes in database tables, historical manual confirmations, etc.) to aggregate the producer and consumer ends, grouping asynchronous operations belonging to the same business process into a single business process.

[0029] Starting from the business entry point, the set of all operations of call chain aggregation and business key aggregation constitutes the "business process boundary".

[0030] A business process boundary refers to the starting and ending point of a business operation, including the databases, interfaces, Redis, message queues, etc., involved in its execution. All these operations belong to the same business process. For example, "order cancellation after user places order" is a failed business process. Its business process boundary includes: user creating order, locking inventory, generating payment order, sending order success message, user canceling order, releasing inventory, canceling payment, and sending order cancellation message. All operations within the business process boundary are written into the "In-Process Operation List".

[0031] Because many business processes in the system are prone to confusion, such as multiple different business operations by the same user being confused as the same business, it is necessary to first define the business boundaries to avoid mixing operations of different business processes together.

[0032] Each failed business transaction includes a unique business process code and defined process boundaries.

[0033] Step 22: Explicitly code the business processes for failed transactions.

[0034] For new business processes, encoding is performed through annotations, configurations, or contract declarations; for existing business processes, if available process codes already exist, they can be directly read; otherwise, encoding is performed through annotations, configurations, or contract declarations. The process code is equivalent to an "identity ID" for each business process, used to uniquely identify it.

[0035] Step 23: Identify the failure information of failed services.

[0036] The failure information includes: business entry point, business domain, failure node, failure type, failure evidence, abnormal branch location, historical failure count, potentially affected resource types, and whether there is a compensation entry point.

[0037] The "identification of failure information" includes at least one of the following methods: static code analysis, runtime link tracing, compensation framework / business configuration identification, and querying historical manual compensation. Static code analysis obtains failure information by analyzing code structure, call relationships, and annotations; runtime link tracing refers to tracing the request call chain using traceid or spanid; querying historical manual compensation refers to checking whether manual compensation exists for the failed business.

[0038] A business entry point refers to the starting point of a business process. Depending on the type of business, the business entry point can be identified from the Controller interface, scheduled task entry point, MQ consumption entry point, or application service entry point. The business entry point is also the starting point of the business process boundary.

[0039] A business domain refers to the type of business. The business domain can be matched by rules using the business primary key, method name, service name, or package name. Machine learning can also be introduced, or it can be configured through annotations, contracts, or manual configuration.

[0040] A failure node refers to a specific step in a business process where a failure occurs. For example, in the business process of "user places an order and then cancels it", the "user creates an order" operation is the business entry point, and the "user cancels an order" operation is the failure node.

[0041] Data such as failure type, failure evidence, abnormal branch location, historical failure count, potentially affected resource types, and whether there is a compensation entry point are used to record more detailed information about business identification.

[0042] Step 3: Filter and remove maintenance operations from failed services, keeping only the service operations.

[0043] The business operations refer to operations that change or confirm the business status. The maintenance operations refer to operations that do not directly change the business status, such as generating logs, setting monitoring points, sending alarms, recording failure reasons, and sending SMS reminders.

[0044] After defining the process boundaries of failed business operations, various operations within the process should be identified; not all operations should be included in the compensation analysis.

[0045] Operational maintenance does not change the business status and is unrelated to business compensation. Therefore, the above operations filter out operations that do not require compensation, thereby reducing the amount of subsequent identification data and more accurately identifying positive and supplementary operations.

[0046] Operations and maintenance are typically invoked through framework services. Therefore, the filtering can be achieved through hard exclusion (hard exclusion directly excludes operations that are clearly not part of the business compensation action; for example, the logger component only records logs and is an operations and maintenance action, so it should be excluded) and whitelist overriding. Furthermore, the execution results of operations and maintenance are usually only recorded and not invoked by other operations; their results have no dependency on other operations. Therefore, dependency lookup can also be used to achieve this.

[0047] The filtering process is as follows: Identification and filtering are typically performed in the following order: resource action identification, action type classification, hard exclusion filtering, whitelist coverage, candidate scoring, and source verification. Special business scenarios can be extended through strategies, but hard exclusion filtering and whitelist coverage should be completed before candidate scoring.

[0048] Resource action identification is used to determine whether the current operation is a manageable action, such as database write, Redis write, external interface call, MQ message sending, etc.

[0049] Action type classification is used to distinguish between general system actions and business actions. Query actions can be divided into pure system queries and business status queries; notification actions can be divided into ordinary system notifications and notifications with business impact; work order actions can be divided into ordinary record work orders and manual compensation entry work orders.

[0050] Hard exclusion filtering is used to exclude actions that are not included in business compensation, such as diagnostic logs, system alarms, monitoring points, ordinary work orders, temporary cleanup, permission verification, parameter conversion, etc.

[0051] The whitelist is used to handle business actions that are easily mistakenly blocked. These include business status queries, business impact notifications, manual compensation entry points, and business audit records. Once a request is placed on the whitelist, it can re-enter the candidate process. It's important to note that the whitelist only indicates permission to participate in scoring and review; it does not guarantee permission to directly execute compensation.

[0052] Candidate scores are used to score and rank the retained actions.

[0053] Confirmation source verification is used to determine whether a candidate action can be upgraded from CANDIDATE to CONFIRMED. Valid confirmation sources include manual confirmation, explicit annotations, interface contracts, message contracts, compensation framework metadata, and runtime closed-loop verification.

[0054] Step 4: Identify the operation information of each business operation in the failed business, calculate the positive candidate score and compensation candidate score of each business operation, and classify the business operation into positive operation candidates or compensation operation candidates.

[0055] The operation information refers to the information contained in a single operation within a business process, including the operation path, evidence of business impact, operation code, type of resource called (database, external interface, MQ, cache, etc.), business key, operation type (CRUD), candidate score, failure evidence, reason for exclusion, confirmation source (the source of the "confirmation" in the system), etc. The specific identification method for operation information is similar to the method for identifying business failure information.

[0056] The positive operation candidates refer to operations that are performed normally in the business process. For example, for a user to purchase a service, "creating an order" and "deducting inventory" are positive operations. The compensation operation candidates refer to operations used to undo previous operation results and restore the original data when a positive operation fails, the process malfunctions, or the user cancels, such as "canceling the order" and "restoring inventory".

[0057] Positive candidate scores and compensation candidate scores are obtained by multi-factor weighted scoring. For example, based on the path in which the operation is located, if an operation is located before a normal path, a try phase, a successful branch, or an abnormal node, it is more likely to be a positive operation, and the positive candidate score of that operation increases.

[0058] If an operation is located in a catch branch, failure return branch, rollback, cancel, compensate, scheduled repair task, reconciliation task, or manual compensation entry point, it is more likely to be a compensation operation, and the compensation candidate score for that operation will increase.

[0059] Candidate scores can also incorporate the following scoring factors: whether it is a genuine business resource operation, whether it falls within a normal or failed path, whether it affects business objects (generally referring to database data changes), whether there is a business primary key, whether there is an interface contract, whether there is a message contract, whether there are idempotent clues, and whether it hits hard exclusion and soft penalties (rule base, whitelist, compensation feasibility matrix, etc.). Specific candidate score rules can be set according to specific circumstances.

[0060] An operation is classified into a positive operation candidate or a compensation operation candidate based on its positive candidate score and compensation candidate score. For example, a scoring threshold can be set; if either the positive candidate score or the compensation candidate score is higher than the threshold, the operation is classified into the corresponding type; if both the positive candidate score and the compensation candidate score of an operation are higher than or lower than their respective thresholds, the classification is made manually.

[0061] Candidate scores primarily address the question of whether a scanned resource action warrants further review and matching. Different business scenarios can be configured with different strategies; if no separate configuration is specified, the system uses the default candidate rules. The default candidate rules comprehensively consider the resource operation facts, code path location, business object association, parameter base, state change characteristics, confirmation source credibility, and negative evidence. Each factor's value ranges from 0 to 1, and the weights are loaded by the candidate identification strategy. During calculation, the system multiplies each factor value by its corresponding weight, sums the results, multiplies by 100, and deducts the negative evidence penalty score. The final result is limited to between 0 and 100 using the clamp function. A result less than 0 is set to 0, a result greater than 100 is set to 100, and a result within the range is kept unchanged. If the current action matches a hard exclusion rule but not a whitelist, candidate scores are not calculated, and the action is directly marked as EXCLUDED.

[0062] When determining whether an operation is suitable as a compensation candidate, if it fails to hit the hard exclusion filter rule but is found to be potentially not a business compensation action—for example, an operation with a name like notification, cache refresh, or task record, or with an unclear business object, weak parameter relationships, or missing business primary keys—it can serve as negative evidence. The existence of negative evidence indicates that the action is not 100% a compensation candidate, so its candidate score needs to be lowered. Therefore, a negative evidence penalty score mechanism is introduced.

[0063] Step 5: Identify the operation parameters of each business operation and generate an operation parameter list; identify post-verification operations.

[0064] The operating parameters include core parameters, automatically required parameters, and optional parameters.

[0065] The core parameters are those that determine who the compensation recipient is, what the impact of the compensation is, and whether the compensation is safe. Examples include product ID, order number, and amount. Without these core parameters, the compensation process cannot proceed.

[0066] Automatically required parameters refer to the parameters that the system must possess to automatically execute compensation, in addition to the core parameters. These parameters are the actual execution parameters of the method. Required parameters determine whether the system can execute automatically safely, idempotently ("idempotent" means that the same operation, whether executed once or multiple times, produces the same result. An idempotent operation is like "changing the order status to canceled," which yields the same result after multiple executions. A non-idempotent operation is like "deducting 100 yuan from the account," which will result in incorrect results after multiple executions), and verifiably. Required parameters are determined based on idempotency rules, post-validation rules, and other methods.

[0067] Idempotency rules are commonly used in distributed systems, including sub-transaction barriers and unique request identifier deduplication rules. The parameters required for idempotency rules are automatically required.

[0068] The automatic required parameters also include fallback rule parameters. These fallback rules define the situations in which automatic compensation will be switched to manual intervention. For example, in cases such as unknown transaction status, external interface offline, lost Redis values, dead letters in the message queue, parameter conflicts, plugin malfunctions, or data not being anonymized, the system must switch to manual handling and cannot continue with automatic repair. The parameters required by the fallback rules are considered automatic required parameters.

[0069] When the core parameters are complete but the automatically required parameters are missing, automatic compensation may result in errors. However, compensation can be performed manually, or the compensation result can be manually verified after system compensation to ensure it is safe and idempotent.

[0070] Optional parameters refer to parameters that can be omitted during the automatic compensation process. If optional parameters are missing, the system can still fill in the missing parameters through default rules, query actions, manual explanations, etc., and continue to automatically complete the compensation process.

[0071] The identification of operation parameters includes identifying positive method input parameters, positive method return values, database snapshots before and after changes, external interface requests, external interface responses, Redis primary keys, Redis values, Redis expiration times, MQ message primary keys, MQ payloads, Trace context, confirmed query actions, and manually supplemented parameters.

[0072] The "post-verification operation" refers to the operation performed after the compensation operation to confirm whether the business status has been correctly restored. Examples include checking whether an order has been cancelled, whether inventory has been replenished, the status of a third-party refund, whether the Redis key has been restored, and whether the MQ message has been consumed.

[0073] Post-validation operations are identified based on the following rules: interface contract, message contract, fixed syntax of the compensation framework, and state machine configuration. If the state machine defines the target state after compensation, such as CANCELLED after order cancellation and REFUNDED after a refund, then the corresponding state query action can be found as a candidate for post-validation. For fixed syntax of the compensation framework, for example, if a certain query action consistently appears after the compensation operation in the compensation operation execution chain, and the input parameters of this query action are consistent with the business key of the compensation operation, then this query action is a post-validation operation for that compensation operation.

[0074] Step 6: Calculate the matching score between each forward operation candidate and each compensation operation candidate to obtain forward-compensation relationship candidates.

[0075] The matching score calculation considers the following factors: whether they belong to the same business process (automatic candidate matching is only performed within the same business process by default; cross-process matching must rely on interface contracts, message contracts, manual configuration, or runtime closed-loop verification), whether the business objects are consistent, whether the business primary keys are consistent or transferable, whether the fields correspond, whether the values ​​can be reversed, whether the status can be rolled back, whether the Redis key is consistent, whether the MQ messageKey is consistent, whether the external system is consistent, whether the parameters are traceable, whether similar compensation operations have been successfully performed in the past, etc.

[0076] Furthermore, different matching weights are applied to operations that call different resource types. For example, databases focus more on tables, fields, status, amounts, quantities, and versions; external interfaces focus more on the target system, interface contract, business primary key, and status query capabilities; Redis focuses more on key patterns, values, TTL, ownerToken, and keyRole; and message queues (MQ) focus more on topics, tags, messageType, messageKey, businessKey, and consumer-side support capabilities. Based on the resource type of each operation, higher weights are given to the data items that are emphasized in it.

[0077] For a forward operation, all compensation operations are sorted from highest to lowest according to their matching scores. At least one compensation operation with a high matching score is matched with the forward operation. The matching relationships and matching scores between the forward operation and each compensation operation are called "forward-compensation relationship candidates." Specifically, a matching score threshold can be used to determine whether to match compensation operations with scores higher than the threshold with the forward operation, or to select the top N operations in the matching score ranking to establish a match.

[0078] After identifying candidate positive and compensation operations, it's necessary to determine which compensation operation can correct which positive operation. For example, the compensation operation for "deducting inventory" might be "releasing inventory" or "replenishing inventory"; the compensation operation for "initiating payment" might be "refund" or "reversal"; the compensation operation for "sending a shipment message" might be "sending a cancellation message"; and the compensation operation for "writing to a Redis business lock" might be "releasing the business lock." Existing technologies typically use operations following the failure node in historical business data as compensation operations. However, for complex business systems, this compensation rule is unreliable, and compensation rules obtained from a single business cannot be applied to a large number of different business scenarios. Therefore, this invention uses a scoring method to measure the degree of matching between positive and compensation operations. By generating and ranking matching scores, it considers various compensation methods applicable to the same type of operation in different business scenarios.

[0079] The matching score is used to determine whether a compensatory relationship may exist between a set of positive actions and compensatory actions. It differs from the candidate score, which evaluates whether a single action is worth retaining, while the matching score evaluates whether two actions can form a compensatory relationship. Business scenarios can configure specific matching strategies; otherwise, the system uses the default matching strategy. The default matching strategy comprehensively considers process consistency, business object consistency, business key consistency, parameter transitivity, operational effect reversibility, validation rule completeness, and historical co-occurrence relationships. Each factor's value ranges from 0 to 1, and the results are calculated by multiplying the weights by 100 to output a matching score of 0 to 100.

[0080] Both candidate score thresholds and matching score thresholds are bound to specific strategies, and do not use globally fixed values. The system maintains threshold standards according to resource type, business domain, business object type, risk level, and model version. During the cold start phase, the system's preset thresholds are used; after stable operation, adjustments are made based on manual confirmation, post-validation results, false positive cases, and long-term execution data. For high-risk businesses such as funds, accounts, and inventory, the candidate score thresholds and matching score thresholds can be appropriately increased.

[0081] Step 7: Write all forward operation candidates, compensation operation candidates, operation parameter list, and forward-compensation relationship candidates into the compensation feasibility matrix.

[0082] Each element in the compensation feasibility matrix must contain at least the following: process code, forward action code, compensation operation code, forward-compensation relationship candidate, confirmation source, parameter list, idempotency rule, fallback rule, execution level, risk score, credibility score, historical success rate, post-validation pass rate, and matrix status.

[0083] The source of the confirmation is the operation information identified in step 4; the parameter list, idempotent rule and fallback rule are from step 5; the initial values ​​of "execution level, risk score, credibility score, historical success rate and post-verification pass rate" are default, and these values ​​will be generated and written into the matrix elements in steps 13-14 below.

[0084] Each matrix element represents the degree of matching between a forward operation and a compensation operation, as well as the confidence level of the compensation.

[0085] The positive operation candidates and compensation operation candidates in the compensation feasibility matrix are stored as relational dimensions through their unique operation codes.

[0086] A positive operation can correspond to one or more compensation operations, and different compensation operations can be precisely matched through operation parameter matching. Different compensation operations can be adopted based on different pre-verification results. For example, if the positive operation is "modify inventory", it corresponds to two compensation operations: if the inventory is not locked, the compensation operation is "directly modify inventory"; if the inventory is locked, the compensation operation is "release inventory and modify inventory".

[0087] The compensation feasibility matrix includes all business process operations of the system, rather than an aggregation of actions in a specific scenario.

[0088] Each element in the matrix represents whether, in a certain business process, a certain positive operation, if successfully executed, can be repaired using a certain compensation operation.

[0089] The matrix element status includes seven states: "Candidate, Confirmed, Enabled, Confirmation Conflict, Requires Re-verification, Frozen, and Disabled". The candidate status can only be displayed and reviewed, and cannot be changed during runtime.

[0090] "Candidate" represents the initial state when a matrix element is first written into the matrix; "Confirmed" indicates that the relationship is established, but automatic execution is not guaranteed. "Enabled" indicates that the rule is complete and can participate in runtime compensation decisions. "Frozen" indicates increased risk, prohibiting automatic execution. "Disabled" indicates that it is no longer used. "Candidate" cannot directly become "Enabled"; "Confirm Conflict" indicates that the relationship has a compensation conflict and is not enabled unless the conflict is resolved; "Requires Re-verification" indicates that the relationship cannot be executed automatically by the system and the compensation parameters or compensation operation results must be manually verified; "Frozen" cannot be directly restored to automatic execution; "Disabled" requires re-confirmation to be restored.

[0091] The compensation feasibility matrix can be understood as a rule table of "whether it can be repaired, how to repair it, how to verify it after repair, and what to do if there is an anomaly". Unlike other existing compensation rules, the compensation feasibility matrix of Embodiment 1 of this invention uniformly lists and scores all possible compensation relationships in the entire system, and uses the parameter of "matrix element status" to mark different matching relationships and perform different operations, thereby greatly improving the compensation reliability of different services.

[0092] Step 8: Manually check and confirm the compensation feasibility matrix, and set the status of matrix elements according to the confirmation results.

[0093] The verification and confirmation include manual verification, explicit annotations, interface contracts, message contracts, compensation framework metadata, state machine configuration, and runtime closed-loop verification.

[0094] During manual verification, an evidence chain will be displayed, which includes the failed business, process entry point, positive action, compensation operation, business domain, business object, business primary key, call path, SQL change, interface request and response summary, Redis key / value / TTL, MQ topic / tag / messageKey, parameter source, candidate score, matching score, post-verification rules, risk score, trust score, and historical samples.

[0095] If multiple confirmation sources conflict, for example, if the annotation says the compensation operation is A, the interface contract says the compensation operation is B, or the parameter list confirmed manually is inconsistent with the message contract, the matrix element will be marked as "confirmation conflict" and forced to be manually reviewed.

[0096] After the compensation feasibility matrix is ​​generated, it cannot be used directly for automatic execution; the matrix needs to be checked and confirmed. If parameters, idempotency, pre-validation, post-validation, or fallback rules are missing, automatic execution cannot proceed.

[0097] Once confirmed, the matrix element status can change from "candidate" to "confirmed". Otherwise, the matrix element status will be marked accordingly based on the different situations described above (e.g., marked as disabled, frozen, etc.). Generally, only when parameters, idempotency, pre-validation, post-validation, fallback rules, and risk strategies are all complete can the element enter the "confirmed" state.

[0098] After verification and confirmation, the compensation feasibility matrix becomes a reliable compensation relationship matching rule table. The following steps will explain how to use the compensation feasibility matrix to complete automatic compensation for newly emerging failed businesses.

[0099] Step 9: When a new failed service occurs, generate a complete positive operation chain for the new failed service, record the new failure information, identify the operation execution status, and mark the operation.

[0100] When a service operation encounters an anomaly, it becomes a newly failed service, and the system will enter the runtime compensation process. The runtime compensation process first generates a complete forward operation chain for the newly failed service. The specific steps for generating the complete forward operation chain are as follows: The complete business chain and process boundaries are reconstructed using traceId, spanId, parentSpanId, API call records, database SQL, transaction status, Redis commands, MQ messages, external API responses, business audit tables, and log events. For synchronous calls, traceId can be used for reconstruction. For asynchronous MQ calls, if the traceId is broken, the asynchronous chain is completed using messageKey, businessKey, topic, tag, producerService, consumerService, and message contract. Generating a complete forward operation chain is similar to the method described in step 22 above.

[0101] Obtaining failure information for new failed business transactions is similar to step 23 described above, and will not be repeated here.

[0102] The system then identifies the execution status of each operation in the complete forward operation chain of the newly failed service. The execution status includes executed, not executed, and execution status unknown. Executed refers to which forward operations were executed and affected the service before the failure occurred; not executed refers to forward operations that should have been executed but were not; and execution status unknown means that the execution status cannot be identified or determined.

[0103] The various operations of a newly failed business will be marked as successful, failed, unknown, or require no compensation.

[0104] Different identification methods are typically used for different business operations to identify the execution status of an operation. For example: For database operations, it is necessary to identify whether the SQL was successful, whether the number of rows affected is greater than 0, and whether the transaction has been committed. Database operations also need to identify whether the operation has been rolled back. If the local transaction of the database has already performed a ROLLBACK operation, then there is no need to compensate for this database action.

[0105] For external interface operations, identify whether HTTP 200 or RPC is successful, identify the business status of the response body, external status query results, interface contracts or reconciliation records, etc.

[0106] For Redis operations, it is necessary to identify whether the confirmation command was successful and whether it is a business decision point. If the Redis operation is just a normal display cache, compensation is usually not required. However, if it is a decision point such as a business lock, inventory cache, idempotent flag, or limit count, further judgment rules need to be introduced for identification.

[0107] For MQ operations, it's necessary to identify whether message sending was successful, whether the transaction message was successfully committed, and whether the consumer-side business impact was successful. A Broker ack (identifying message sending) indicates that a message has entered the Broker, but this does not mean that the downstream has consumed it and generated a business impact; therefore, it's still necessary to further identify whether the consumer-side business impact was successful.

[0108] For "unknown operation status", identification and confirmation are performed through binlog, business audit table or post-query.

[0109] Existing technologies typically compensate directly based on simple rules regarding "business errors," while Embodiment 1 of this invention first determines "which positive operations have actually occurred." Compensation is only applied to positive operations that have already had an impact.

[0110] Step 10: Match the complete forward operation chain of the new failed business with the compensation feasibility matrix to find the "forward-compensation relationship candidates" corresponding to each successfully executed forward operation; then determine the feasibility based on the matrix element status, pre-verification, parameter completeness, risk strategy and execution level, define the execution level, and select the compensation operation according to the execution level from high to low and the matching score from high to low.

[0111] The term "matching" refers to comparing the failure information of a new failed service with the failure information recorded in each matrix element based on similarity. This matching process identifies the closest failure scenario and operation within the compensation feasibility matrix, thereby achieving reliable compensation operation matching.

[0112] The feasibility determination refers to judging whether the matched matrix elements and positive-compensation relationship candidates are applicable. If a positive operation corresponds to more than one compensation operation, the determination is performed sequentially from highest to lowest matching score.

[0113] Specifically, the following criteria are included: First, determine whether the matrix element status is "Enabled" or "Confirmed". Only "Enabled" matrix elements can undergo automatic system compensation. For "Confirmed" matrix elements, the system will recommend corresponding compensation operations as manual repair suggestions, but these will not be executed automatically by the system.

[0114] Secondly, it is necessary to determine whether the source of the confirmation is valid. For example, confirmations from annotations or compensation framework configurations are reliable and valid, while confirmations from message queue Broker ACKs or timeouts found by scanning logs are unreliable and invalid.

[0115] Finally, the operation parameters in the new failed business must be complete, especially the core parameters and automatically required parameters (such as idempotent key dependency parameters and post-validation parameters).

[0116] In addition, for some types of business, it is necessary to confirm the idempotency rules to avoid repeated repairs; Some services have built-in pre-verification and post-verification rules: the pre-verification rules determine whether the current service status still allows compensation, and the post-verification rules verify whether the compensation was successful after it has been completed. For these types of services, it is necessary to confirm the pre-verification and post-verification rules.

[0117] Finally, the fallback rules must be checked. The fallback rules mean that if the following situations are triggered: unknown transaction status, external interface offline, loss of old Redis values, dead letter in MQ, parameter conflict, plugin malfunction, or data not being anonymized, the system must be downgraded or switched to manual compensation and cannot continue to automatically repair.

[0118] Based on the above judgment criteria, four execution levels are given from high to low: automatic compensation can be executed, automatic compensation is executed after pre-verification, compensation requires manual confirmation, and compensation is disabled.

[0119] Compensation operations are selected based on execution level from highest to lowest and matching score from highest to lowest.

[0120] Existing technologies typically rely on fixed rules or simple human experience to determine business compensation, resulting in poor reliability. In Embodiment 1 of this invention, the "can it be repaired?" metric is broken down into multiple technical conditions, including source confirmation, parameters, idempotency, verification, risk, fallback, and historical reliability. After confirming which positive operations have been successful, the corresponding compensation scheme is retrieved from the compensation feasibility matrix and operated according to different execution levels.

[0121] Step 11: Perform anti-duplicate repair verification.

[0122] Before performing a repair, it is crucial to prevent duplicate repairs. Duplicate repairs can lead to serious consequences, such as duplicate refunds, duplicate inventory replenishments, duplicate lock releases, and duplicate cancellation messages. Duplicate repair prevention can be implemented using a combination of idempotent keys, idempotent records, distributed locks, and unique database indexes.

[0123] The idempotent key is typically generated from the traceId, a unique business process code, a business key, a forward action code, a compensation operation code, and a parameter summary. Duplicate compensation requests under the same business impact must fall under the same idempotent key.

[0124] Idempotent records are used to track the status of compensation tasks, including initialization, execution, successful execution, failed execution, unknown result, and requiring manual intervention. Distributed locks are used to prevent concurrent execution for short periods. Database unique indexes or idempotent tables are used to prevent duplicates at the end.

[0125] If the lock expires, execution times out, the system crashes, or the external interface status is unknown, it cannot be executed again directly. Instead, the idempotency record and business status are checked first, and then a decision is made on whether to retry, mark as successful, mark as failed, or transfer to manual intervention.

[0126] Make anti-duplication repair a mandatory technical access control before the compensation operation is executed, and handle extreme scenarios such as lock expiration, unknown status, and inconsistent idempotent records.

[0127] Step 12: Perform the selected compensation operation.

[0128] The compensation operation can only be executed after the compensation operation is selected and the anti-duplication repair check is passed.

[0129] The execution of compensation operations is a well-known technology in distributed systems. Specific execution methods include calling the business layer compensation service, calling the remote compensation interface, performing restricted Redis repair, sending compensation MQ messages, or performing specific resource compensation through plugins.

[0130] Compensation operations should prioritize invoking the dedicated compensation entry point in the business layer, rather than directly calling internal private methods or arbitrarily executing SQL. This is because the business layer compensation entry point typically includes transactions, permissions, state machines, parameter validation, idempotent protection, and business rules.

[0131] Resource-level executors (such as Redis executors and MQ executors) can only execute restricted actions that have been declared, confirmed, and enabled in the matrix. For example, a Redis executor can only restore a specified key, value, TTL, or release the lock after verifying the owner token. An MQ executor can only send the topic, tag, message type, and payload mapping declared in the matrix. Database executors can only execute restricted actions when snapshots, versions, and post-validations are available.

[0132] Compensation is performed using matrix constraints and constrained executors, rather than by directly modifying the data, ensuring that the compensation operation is controllable, auditable, and has a clear rollback strategy.

[0133] Step 13: Perform post-verification to check if the compensation operation was successful. If the post-verification fails, proceed to retry, manual confirmation, or freeze the matrix. If the post-verification status is unknown, proceed to wait, asynchronous re-verification, or manual confirmation. If the post-verification passes, mark the compensation operation as successful.

[0134] After the compensation operation returns a successful result, it cannot be immediately assumed that the business has been restored to consistency.

[0135] A successful API response only indicates that the call process was successful, not that the business logic is correct. Therefore, a post-consistency check must be performed.

[0136] The post-verification needs to adopt different verification strategies according to different business scenarios, for example: For database scenarios, verify whether the status of business records, inventory flow, points flow, amount status, or version number meet expectations.

[0137] For external interface scenarios, query the business status of third parties or the called service, such as whether the refund has been completed, whether the invoice has been reversed, and whether the logistics has been cancelled.

[0138] In a Redis scenario, the checks include whether the key exists, whether the value is correct, whether the TTL meets expectations, and whether the ownerToken matches.

[0139] In MQ scenarios, it is necessary to verify whether the compensation message has been delivered, consumed, whether the downstream business status has been corrected, or whether the original message will no longer have an impact.

[0140] If the post-verification fails, proceed to retry, manual confirmation, or freeze matrix elements.

[0141] The retry refers to re-executing from step 9 to attempt to complete the compensation. Since the system may experience non-persistent errors such as data transmission errors or data loss, retrying previous operations can overcome these issues and complete the compensation. However, for post-verification failures that cannot be resolved through retrying, manual confirmation is required. If the error originates from the matrix element itself in the compensation feasibility matrix, the matrix element's state needs to be adjusted to "frozen," temporarily disabling any positive-compensation relationship candidates recorded in that matrix element.

[0142] If the status of the post-verification is unknown, then proceed to waiting, asynchronous re-verification, or manual confirmation.

[0143] If the post-verification passes, the compensation operation is marked as successful.

[0144] The verification rules are determined as follows: Pre-verification rules are formulated based on the resource type corresponding to the compensation action. Before database compensation is executed, it is necessary to verify whether the target record exists, whether the current business status supports rollback, and whether the data version number is consistent with the status after the forward operation ends. Before external interface compensation is executed, it is necessary to verify whether the external business status is queryable, whether the current status supports cancellation or reversal, and whether the compensation interface is available. Before Redis compensation is executed, it is necessary to verify whether the key, value, TTL, ownerToken, and version information meet expectations. Before MQ compensation is executed, it is necessary to confirm the delivery, consumption, and dead letter status of the original message, and confirm whether the consumer supports reverse message or correction message processing.

[0145] Post-verification is designed around the target state after compensation. In database scenarios, it is necessary to verify whether the business record status, transaction information, amount or quantity meet expectations; in external interface scenarios, it is necessary to confirm whether the external system has completed operations such as cancellation, refund, closure or resource reclamation; in Redis scenarios, it is necessary to verify whether the key value, expiration time, and distributed lock status have reached the target state; in MQ scenarios, it is necessary to confirm whether the compensation message has been delivered and consumed normally, and further confirm whether the downstream business status meets expectations.

[0146] Step 14: Update and optimize the compensation feasibility matrix.

[0147] The update and optimization refer to: updating the compensation feasibility matrix in reverse with the results of the compensation operation.

[0148] The specific steps are as follows: If the compensation operation is successfully executed and the post-validation passes, information such as the failed business, the positive operations within the business, and the compensation operation are written into the compensation feasibility matrix. The specific method for writing this information is described in steps 1-8 above.

[0149] Successful write compensation operations increase the number of successful samples in the feasibility matrix, thus improving the reliability of the matrix relationships.

[0150] If the compensation operation fails, the post-verification fails, the status is unknown, the parameters are missing, there is an idempotency conflict, the plugin is abnormal, or the manual rejection occurs, the matrix element containing the compensation operation will be updated in the compensation feasibility matrix. For example, the failure index, the unknown status rate, the fallback trigger rate, and the manual rejection rate will be updated. The matrix element may be downgraded (downgrading means changing the status of the matrix element from "enabled" to "confirmed" or "re-verification required") or the matrix relationship may be frozen as appropriate.

[0151] The state updates of matrix elements in the compensation feasibility matrix only allow automatic downgrading or freezing; automatic upgrading of the execution level based on historical successes is not permitted. Historical successes can only generate upgrade suggestions, and upgrades must be confirmed manually or through a contract. Furthermore, manual confirmation results, rejection results, and post-verification results will be used as training samples to optimize candidate identification and ranking.

[0152] For the compensation feasibility matrix representing different compensation paths, each compensation path can be screened and evaluated to determine the target compensation path; the compensation operations in the target compensation path can be executed under control, including execution order control, execution condition verification and execution process monitoring.

[0153] This invention forms a closed-loop optimization through the feedback of compensation operation results. The compensation operation results will inversely affect the compensation judgment of subsequent similar anomalies, making the system clearer the more it runs, the clearer which compensations are reliable, which compensations are high-risk, and which compensations require manual handling.

[0154] Example 2

[0155] Embodiment 2 of the present invention discloses a distributed transaction compensation system based on a compensation feasibility matrix, used to implement the distributed transaction compensation method based on a compensation feasibility matrix described in Embodiment 1, comprising: The failed service identification module is used to identify failed services from existing service data; The process boundary delineation module is used to explicitly code failed business processes and delineate business process boundaries. The operation candidate generation module is used to filter and remove operation and maintenance operations from failed services, retaining only business operations; it calculates the positive candidate score and compensation candidate score of business operations, and classifies business operations into positive operation candidates or compensation operation candidates. The compensation feasibility matrix construction module is used to identify the operation parameters of business operations, generate an operation parameter list, identify post-verification operations, calculate the matching score between forward operation candidates and compensation operation candidates, obtain forward-compensation relationship candidates, and write the forward operation candidates, compensation operation candidates, operation parameter list and forward-compensation relationship candidates into the compensation feasibility matrix representing different compensation paths. The matrix element status setting module is used for manual confirmation of the compensation feasibility matrix and setting the matrix element status based on the confirmation result. The compensation operation selection module is used to generate a forward operation link for a new failed service when a new failed service occurs, record the new failure information, identify the operation execution status and mark the operation; match the forward operation link of the new failed service with the compensation feasibility matrix, find the forward-compensation relationship candidates corresponding to the successfully executed forward operations, determine the feasibility and classify the execution level, and select the compensation operation according to the execution level from high to low and the matching score from high to low. The compensation operation verification module is used to prevent duplicate repair verification; it executes the selected compensation operation; it performs a post-verification to check whether the compensation operation is successful. If the post-verification fails, it proceeds to retry, manual confirmation, or freeze the matrix. If the post-verification status is unknown, it proceeds to wait, asynchronous re-verification, or manual confirmation. If the post-verification passes, the compensation operation is marked as successful. The update and optimization module is used to update and optimize the compensation feasibility matrix based on the results of the compensation operation.

[0156] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit them. The scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention.

Claims

1. A distributed transaction compensation method based on a compensation feasibility matrix, characterized in that, Includes the following steps: Step 1: Identify failed business transactions from existing business data; Step 2: Explicitly code the failed business processes and define the business process boundaries; Step 3: Filter and remove maintenance operations from failed services, keeping only service operations; Step 4: Calculate the positive candidate score and compensation candidate score of the business operation, and classify the business operation into positive operation candidates or compensation operation candidates; Step 5: Identify the operation parameters of the business operation, generate an operation parameter list, and identify the post-validation operation; Step 6: Calculate the matching score between the forward operation candidate and the compensation operation candidate to obtain the forward-compensation relationship candidate; Step 7: Write the forward operation candidates, compensation operation candidates, operation parameter list, and forward-compensation relationship candidates into the compensation feasibility matrix representing different compensation paths; Step 8: Manually confirm the compensation feasibility matrix and set the status of matrix elements based on the confirmation results; Step 9: When a new failed service occurs, generate a positive operation link for the new failed service, record the new failure information, identify the operation execution status, and mark the operation. Step 10: Match the forward operation links of the new failed business with the compensation feasibility matrix, find the forward-compensation relationship candidates corresponding to the successfully executed forward operations, determine the feasibility and classify the execution level, and select the compensation operation according to the execution level from high to low and the matching score from high to low. Step 11: Perform anti-duplicate repair verification; Step 12: Perform the selected compensation operation; Step 13: Perform post-verification to check if the compensation operation is successful. If the post-verification fails, proceed to retry, manual confirmation, or freeze the matrix. If the post-verification status is unknown, proceed to wait, asynchronous re-verification, or manual confirmation. If the post-verification passes, mark the compensation operation as successful. Step 14: Update and optimize the compensation feasibility matrix based on the results of the compensation operation.

2. The distributed transaction compensation method based on the compensation feasibility matrix according to claim 1, characterized in that, In step 2, the business process boundaries of failed businesses are defined by calling chain aggregation and business key aggregation.

3. The distributed transaction compensation method based on the compensation feasibility matrix according to claim 1, characterized in that, In step 4, the scoring factors for positive candidate scores and compensation candidate scores include: the path of the operation, whether it is a real business resource operation, whether it affects business objects, whether there is a business primary key, whether there is an interface contract, whether there is a message contract, whether there are idempotent clues, and whether it hits hard exclusion and soft penalty.

4. The distributed transaction compensation method based on the compensation feasibility matrix according to claim 1, characterized in that, In step 7, each matrix element in the compensation feasibility matrix shall contain at least the following: process code, forward action code, compensation operation code, forward-compensation relationship candidate, confirmation source, parameter list, idempotency rule, fallback rule, execution level, risk score, credibility score, historical success rate, post-validation pass rate, and matrix status. In step 8, the matrix element status includes: candidate, confirmed, enabled, confirmation conflict, requires re-verification, frozen, and disabled.

5. The distributed transaction compensation method based on the compensation feasibility matrix according to claim 1, characterized in that, In step 10, by using the forward operation code in the forward operation chain of the new failed business, all candidate compensation relationships corresponding to the forward operation are found from the compensation feasibility matrix. Then, based on the matrix status, pre-verification, parameter completeness and risk strategy, a comprehensive score is given, and the compensation operation with the highest score is selected. The feasibility is determined and the execution level is assigned based on the matrix element status, pre-verification, parameter completeness, risk strategy and execution level.

6. The distributed transaction compensation method based on the compensation feasibility matrix according to claim 1, characterized in that, In step 14, if the compensation operation is successfully executed and the post-verification passes, the failed business, the positive operation information in the business, and the compensation operation information are written into the compensation feasibility matrix. If the compensation operation fails, update the matrix element containing the compensation operation in the compensation feasibility matrix, and downgrade or freeze the matrix relationship.

7. A distributed transaction compensation system based on a compensation feasibility matrix, characterized in that, To implement the distributed transaction compensation method based on the compensation feasibility matrix as described in claim 1, the method includes: The failed service identification module is used to identify failed services from existing service data; The process boundary delineation module is used to explicitly code failed business processes and delineate business process boundaries. The operation candidate generation module is used to filter and remove operation and maintenance operations from failed services, retaining only business operations; it calculates the positive candidate score and compensation candidate score of business operations, and classifies business operations into positive operation candidates or compensation operation candidates. The compensation feasibility matrix construction module is used to identify the operation parameters of business operations, generate an operation parameter list, identify post-verification operations, calculate the matching score between forward operation candidates and compensation operation candidates, obtain forward-compensation relationship candidates, and write the forward operation candidates, compensation operation candidates, operation parameter list and forward-compensation relationship candidates into the compensation feasibility matrix representing different compensation paths. The matrix element status setting module is used for manual confirmation of the compensation feasibility matrix and setting the matrix element status based on the confirmation result. The compensation operation selection module is used to generate a forward operation link for a new failed service when a new failed service occurs, record the new failure information, identify the operation execution status and mark the operation; match the forward operation link of the new failed service with the compensation feasibility matrix, find the forward-compensation relationship candidates corresponding to the successfully executed forward operations, determine the feasibility and classify the execution level, and select the compensation operation according to the execution level from high to low and the matching score from high to low. The compensation operation verification module is used to prevent duplicate repair verification; it executes the selected compensation operation; it performs a post-verification to check whether the compensation operation is successful. If the post-verification fails, it proceeds to retry, manual confirmation, or freeze the matrix. If the post-verification status is unknown, it proceeds to wait, asynchronous re-verification, or manual confirmation. If the post-verification passes, the compensation operation is marked as successful. The update and optimization module is used to update and optimize the compensation feasibility matrix based on the results of the compensation operation.

Images