Distributed transaction consistency guarantee system for microservice architecture

Abstract

The application discloses a distributed transaction consistency guarantee system for micro-service architecture, and relates to the technical field of distributed transaction and micro-service architecture, and comprises a transaction execution graph that integrates causal markers and resource states, which is constructed in real time through an event aggregation and analysis module, so that the global visualization of transaction context and resource consumption is realized. Based on this, the system uses a pattern portrait and conflict plan module to identify potential conflicts and generate intervention plans, and then uses a simulation decision module to deduce the global influence of the plan in a transaction outcome simulator, and through iterative optimization until the result meets the consistency standard, and finally outputs an executable scheme. The scheme changes the consistency guarantee of distributed transactions from post-repair to pre-simulation and global optimization, and improves the transaction reliability and resource utilization efficiency in a complex micro-service environment.

Description

Technical Field

[0001] This invention belongs to the field of distributed transaction and microservice architecture technology, specifically a distributed transaction consistency guarantee system for microservice architecture. Background Technology

[0002] In a microservices architecture, business operations are broken down into multiple independent services, and a complete business transaction often requires data updates across multiple services. Ensuring consistency in such distributed transactions is a key challenge. Existing technical solutions mainly rely on the eventual consistency model, using message queues, event-driven architectures, and compensatory transactions or attempted confirmation / cancellation models. Another approach relies on a distributed transaction coordinator, based on a two-phase commit protocol or its variants to guarantee strong consistency. These solutions constitute the mainstream technical means for ensuring transaction consistency.

[0003] Existing solutions have shortcomings. Eventual consistency-based methods typically compensate during or after transaction execution, lacking a global, real-time understanding of the transaction execution process and failing to predict resource contention and causal conflicts between transactions. Coordinator-based solutions focus on the atomic commit of individual transactions, struggling to handle cascading blockages or timeouts caused by resource bottlenecks in complex call chains; their decision-making is isolated and reactive. Existing technologies generally lack a unified real-time view integrating transaction logic topology and underlying resource status, and even more so, lack the ability to perform pre-emptive intervention and deduction based on this view.

[0004] Overcoming the limitations of passive response and localized decision-making to achieve a consistency guarantee mechanism capable of proactively identifying conflicts and simulating optimal intervention paths based on a global situation has become a problem that needs to be solved. This requires the system to not only depict the complete causal graph of transaction execution and resource load in real time, but also to conduct sandbox simulations of potential intervention measures on this graph to ensure the global effectiveness of decisions. Summary of the Invention

[0005] This invention aims to solve at least one of the technical problems existing in the prior art;

[0006] To this end, the present invention proposes a distributed transaction consistency guarantee system for microservice architectures, comprising:

[0007] The event aggregation and parsing module is used to aggregate local logs from the transaction coordinator and various participating services in real time, forming a raw event stream containing transaction execution traces and resource snapshots. The raw event stream is then parsed and reconstructed in multiple stages to extract transaction identifiers and operation sequences, supplement resource occupancy levels based on resource snapshots, and generate a transaction execution graph with causal tags.

[0008] The pattern profiling module is used to build a transaction behavior pattern library and resource pressure profile based on the historical baseline of the transaction execution graph's topology and resource usage levels.

[0009] The conflict contingency plan module is used to match the real-time acquired transaction execution graph fragments with the transaction behavior pattern library to identify potential consistency and resource conflict points. Combined with the resource pressure profile, it generates a preliminary intervention plan for each conflict point, which includes resource allocation instructions and transaction routing suggestions.

[0010] The simulation decision module is used to input the preliminary intervention plan into the transaction outcome simulator, deduce the final state of the entire transaction execution graph after the execution of the preliminary intervention plan, evaluate whether the final state meets the preset eventual consistency or strong consistency criteria, and determine the corresponding preliminary intervention plan as the final execution plan when the criteria are met. If the criteria are not met, the constraints of the preliminary intervention plan are adjusted and the simulation is repeated until a final execution plan that meets the criteria is obtained.

[0011] Preferably, the original event stream is parsed and reconstructed in multiple stages to extract transaction identifiers and operation sequences, supplement resource occupancy levels based on resource snapshots, and generate a transaction execution graph carrying causal markers, specifically including:

[0012] Separate all log entries belonging to the same global transaction identifier from the original event stream and sort them by timestamp to form the original operation chain;

[0013] Analyze the operation type and input / output parameters of each log in the original operation chain, infer the call dependencies between services, and convert the operation chain into a directed acyclic graph structure;

[0014] From the resource snapshot of the original event stream, extract the database lock holding state, message queue offset and cache version number corresponding to each operation execution time, and attach them as resource state labels to the corresponding nodes of the directed acyclic graph structure;

[0015] The directed acyclic graph structure is merged and encoded with the additional resource status labels to generate a graph data object containing node attributes and edge attributes, which is the transaction execution graph with causal labels.

[0016] Preferably, based on the historical baseline of the transaction execution graph's topology and resource consumption levels, a transaction behavior pattern library and resource pressure profile are constructed, specifically including:

[0017] Collect a large number of transaction execution graphs with causal labels generated within the historical period, perform cluster analysis on the topology of the graphs, and group graphs with similar node connection methods and state transition paths into a transaction behavior pattern.

[0018] Key features are extracted for each transaction behavior pattern, including typical service call depth, number of high-frequency concurrent branches, and common rollback trigger points, forming a pattern feature description;

[0019] Statistics are collected on the utilization levels of key resources within the system when each transaction behavior pattern occurs. These key resources include the database connection pool, distributed lock service, and network bandwidth.

[0020] Resource usage data is categorized and aggregated according to transaction behavior patterns. The mean, peak, and distribution patterns of resource usage under each pattern are calculated to create a resource pressure profile.

[0021] Preferably, the real-time acquired transaction execution graph fragments are matched with a transaction behavior pattern library to identify potential consistency and resource conflict points, specifically including:

[0022] The system performs real-time similarity calculations between the transaction execution graph carrying causal labels that is being constructed and the pattern feature descriptions in the transaction behavior pattern library.

[0023] When the similarity exceeds the matching threshold, it is determined that the current transaction is evolving in accordance with a certain known transaction behavior pattern;

[0024] Based on the resource pressure profile corresponding to the matched transaction behavior pattern, predict the resource bottlenecks that will be caused by the subsequent evolution of the current transaction. The resource bottlenecks include connection exhaustion or lock wait timeout.

[0025] At the same time, the existing node attributes in the current transaction execution graph are analyzed to detect whether there are state combinations that violate the preset consistency rules. The state combinations include the coexistence of committed branches and branches to be rolled back.

[0026] The predicted resource bottlenecks are combined with the detected rule-violating states to mark potential consistency and resource conflict points.

[0027] Preferably, based on the resource pressure profile, a preliminary intervention plan is generated for each conflict point, including resource allocation instructions and transaction routing suggestions, specifically including:

[0028] For each marked potential consistency and resource conflict point, query the resource pressure profile of its corresponding transaction behavior pattern;

[0029] Based on the distribution pattern of resource usage in the resource pressure profile, a set of pre-allocation instructions is generated to alleviate the predicted resource bottleneck. The pre-allocation instructions include pre-expanding database connections or temporarily increasing the lock lease duration.

[0030] Analyze the current progress of the transaction execution graph, calculate alternative routing paths for subsequent service calls that have not yet been executed, in order to avoid service nodes that may cause consistency issues in subsequent evolution, and form transaction routing suggestions;

[0031] The pre-allocation instructions and transaction routing suggestions for the same conflict point are encapsulated to form a complete preliminary intervention plan, with each plan bound to a specific conflict point and transaction phase.

[0032] Preferably, the preliminary intervention plan is input into the transaction outcome simulator to simulate the final state of the entire transaction execution graph after the execution of the preliminary intervention plan, specifically including:

[0033] The transaction outcome simulator maintains a virtual system state environment that replicates the real-time capacity and allocation status of critical resources in the real system.

[0034] The transaction outcome simulator loads the current transaction execution graph carrying causal tags and initializes its state as pending transactions in the virtual environment;

[0035] The event outcome simulator sequentially executes the pre-allocation instructions in the initial intervention plan and updates the availability status of resources in the virtual environment;

[0036] The transaction outcome simulator simulates the subsequent progress of the transaction execution graph in a virtual environment, following the transaction routing suggestions in the initial intervention plan, and records the response and state transition of each virtual service node.

[0037] When a virtual transaction reaches the final state of commit or rollback, the transaction termination simulator collects the final state of all relevant data copies in the entire virtual environment, as well as the final state of all branches of the transaction, as the deduced transaction termination state.

[0038] Preferably, the evaluation of whether the final state meets the preset eventual consistency or strong consistency criteria includes:

[0039] The eventual consistency criterion is defined as follows: at the end of a transaction, all relevant data replicas can reach a consistent state after an acceptable time delay.

[0040] The strong consistency criterion is defined as follows: at the end of a transaction, all relevant data copies and all external observers can immediately read the same latest data.

[0041] Check the transaction termination status output by the transaction termination simulator to verify whether the final values ​​of all data replicas conform to the constraints defined in the business logic.

[0042] For eventual consistency criteria, it is also necessary to inject simulated time delays and subsequent read requests into the virtual environment to verify the data consistency after the delay;

[0043] Output a Boolean evaluation result indicating whether the final state fully satisfies the selected consistency criterion.

[0044] Preferably, if the conditions are not met, the constraints of the initial intervention plan are adjusted and the scenario is re-analyzed until a final implementation plan that meets the criteria is obtained, specifically including:

[0045] When the evaluation result is not met, analyze the virtual simulation process log recorded in the transaction outcome simulator to locate the key decision point that led to the violation of the consistency standard;

[0046] Relax or tighten one or more constraints in the initial intervention plan, including the extent of resource allocation, the priority of routing path selection, or the isolation level of transactions;

[0047] Using the adjusted constraints, modify the initial intervention plan and generate a new candidate intervention plan;

[0048] The new candidate intervention plan will be resubmitted to the event outcome simulator for simulation and its final status will be reassessed.

[0049] The process involves iteratively locating key decision points, adjusting constraints, generating new contingency plans, and re-analyzing and evaluating the results until the final state evaluation result output by the transaction outcome simulator is satisfactory. At this point, the candidate intervention plan used in the last round is determined as the final execution plan.

[0050] Preferably, the step of analyzing the operation type and input / output parameters of each log entry in the original operation chain, inferring the call dependencies between services, and converting the operation chain into a directed acyclic graph structure specifically includes:

[0051] Parse each log record in the original operation chain and extract its operation type field and input / output parameter fields;

[0052] Based on the global transaction identifier and call chain tracing identifier carried in the input and output parameter fields, establish the parent-child call relationship between log entries generated by different services;

[0053] Each independent service call operation is instantiated as a node in a directed acyclic graph, and the node's attributes include the service identifier and the operation type;

[0054] Based on the parent-child call relationship, a directed edge is added to the directed acyclic graph, pointing from the parent call node to the child call node, to represent the call dependency between services;

[0055] By traversing and verifying all nodes and edges, it is ensured that there are no cyclic dependent paths in the graph, thus completing the transformation from the original operation chain to the directed acyclic graph structure.

[0056] Preferably, the step of performing real-time similarity calculation between the transaction execution graph carrying causal tags that is being constructed and the pattern feature descriptions in the transaction behavior pattern library specifically includes:

[0057] From the transaction execution graph currently being constructed, extract its topology feature vector and node attribute feature vector up to the current time. The topology feature vector includes the current depth, number of branches, and node type sequence, and the node attribute feature vector includes the set of operation types involved.

[0058] Read the feature description of each stored pattern from the transaction behavior pattern library and encode it into a standard reference feature vector;

[0059] The cosine similarity algorithm is used to calculate the similarity between the topological feature vector of the current graph and the topological part of each reference feature vector, and at the same time, the similarity between the node attribute feature vector and the attribute part of each reference feature vector is calculated.

[0060] The topological similarity and the node attribute similarity are weighted and fused to obtain the comprehensive similarity score between the current graph and each known transaction behavior pattern;

[0061] A matching threshold is set, and patterns with a comprehensive similarity score exceeding the matching threshold are marked as candidate patterns that match the current transaction execution graph.

[0062] Compared with the prior art, the beneficial effects of the present invention are:

[0063] The event aggregation and parsing module performs multi-stage parsing and reconstruction of the original log stream, generating a transaction execution graph carrying causal markers and resource consumption levels. This technology transforms discrete log events into a structured global topology view, explicitly depicting the dependencies between transaction operations and synchronously linking the real-time resource status of each service node. It achieves deep integration and real-time visibility into the distributed transaction execution context and resource consumption, enabling the system to clearly identify where resource contention or operation timing may cause consistency violations in the transaction chain, providing a high-fidelity data foundation for accurately locating the root cause of conflicts.

[0064] The pattern profiling module constructs a database of transaction behavior patterns and resource pressure profiles, which the conflict contingency plan module matches and generates preliminary intervention plans. The simulation decision-making module inputs the plans into a transaction outcome simulator, simulates the final state of the entire transaction graph after implementing the plans, and iteratively adjusts the plans until the simulation results meet consistency criteria. This technology establishes a closed-loop decision-making process of "simulation-verification-optimization." This allows any intervention measure to be evaluated in a virtual environment for its global impact on the entire transaction ecosystem before actual implementation, thereby selecting the execution plan that truly guarantees consistency goals and optimizes resource allocation, elevating consistency assurance from empirical, passive remediation to predictable, proactive planning. Attached Figure Description

[0065] Figure 1 This is a sequence diagram of the distributed transaction consistency guarantee system for microservice architecture described in this invention.

[0066] Figure 2 A flowchart for constructing a profile of transaction behavior patterns and resource pressure.

[0067] Figure 3 A two-bar comparison chart of semantic weights for different operation types;

[0068] Figure 4 A bar chart comparing resource pressure and pre-allocation trigger thresholds for different transaction modes;

[0069] Figure 5 This is a comparison chart of resources before and after the execution of the pre-allocation command. Detailed Implementation

[0070] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0071] See Figure 1The event aggregation and parsing module aggregates local logs from the transaction coordinator and participating services in real time, forming a raw event stream containing transaction execution trajectories and resource snapshots. This raw event stream undergoes multi-stage parsing and reconstruction to extract transaction identifiers and operation sequences. Resource occupancy levels are supplemented based on resource snapshots, generating a transaction execution graph with causal markers. The pattern profiling module constructs a transaction behavior pattern library and a resource pressure profile based on the topology of the transaction execution graph and the historical baseline of resource occupancy levels. The conflict contingency plan module matches the real-time acquired transaction execution graph fragments with the transaction behavior pattern library to identify potential consistency and resource conflict points. Combined with the resource pressure profile, it generates a preliminary intervention plan for each conflict point, including resource allocation instructions and transaction routing suggestions. The simulation decision-making module inputs the preliminary intervention plan into the transaction outcome simulator, simulating the final state of the entire transaction execution graph after executing the preliminary intervention plan. It evaluates whether the final state meets preset eventual consistency or strong consistency criteria. If the criteria are met, the corresponding preliminary intervention plan is determined as the final execution plan. If not, the constraints of the preliminary intervention plan are adjusted and the simulation is repeated until a final execution plan that meets the criteria is obtained.

[0072] In one embodiment of the present invention, the event aggregation and parsing module receives local log streams from the transaction coordinator and various participating service nodes in real time. These local log streams contain transaction identifiers, operation types, timestamps, input / output parameters, and resource snapshot information. The event aggregation and parsing module aggregates and buffers these log streams into a raw event stream. The event aggregation and parsing module performs multi-stage parsing and reconstruction on the raw event stream to generate a transaction execution graph carrying causal markers. The first stage involves separating all log entries belonging to the same global transaction identifier from the raw event stream. The event aggregation and parsing module performs hash grouping based on the global transaction identifier field in the log entries, grouping log entries with the same global transaction identifier into the same temporary set. The event aggregation and parsing module then sorts the entries in the temporary set in ascending order according to the timestamp field of each log entry, forming a raw operation chain arranged in chronological order.

[0073] In some embodiments, the event aggregation and parsing module parses the operation type field and input / output parameter field of each log record in the original operation chain. The operation type field indicates whether the operation corresponding to the log record is a service call start, service call end, resource request, or resource release. The input / output parameter field includes the call chain tracing identifier, service identifier, method name, and parameter values. Based on the global transaction identifier and call chain tracing identifier carried in the input / output parameter fields, the event aggregation and parsing module establishes parent-child call relationships between log entries generated by different services. Specifically, if the call chain tracing identifier of one log is a direct prefix of the call chain tracing identifier of another log, the former is determined to be the parent call and the latter to be the child call. The event aggregation and parsing module instantiates each independent service call operation as a node in a directed acyclic graph. The node's attributes include the service identifier and operation type, and the node also carries the timestamp information from the original log. Based on the established parent-child call relationships, the event aggregation and parsing module adds directed edges from the parent call node to the child call node in the directed acyclic graph to represent the call dependencies between services. The event aggregation and parsing module performs a depth-first traversal and verification of all nodes and edges, checking whether there is a path in the graph that starts from any node, goes through several edges, and returns to that node, to ensure that there are no circular dependency paths in the graph, thus completing the transformation from the original operation chain to the directed acyclic graph structure.

[0074] The event aggregation and parsing module extracts the resource status corresponding to each operation execution moment from the resource snapshot of the original event stream. The resource snapshot is a structured data segment embedded in the log entry, recording the database lock holding status, message queue offset, and cache version number associated with the operation execution. The module then uses these resource statuses as resource status annotations, appending them as key-value pairs to the attribute dictionary of the corresponding node in the directed acyclic graph (DAG) structure. Each node's attribute dictionary thus includes the service identifier, operation type, timestamp, and resource status annotation. The module merges and encodes the DAG structure and the appended resource status annotations. During this encoding process, node attributes, edge attributes, and the global transaction identifier are serialized into a unified graph data object. This graph data object is the transaction execution graph carrying causal markers, which are implicitly reflected through the directed edges and node timestamp attributes in the graph.

[0075] Optionally, after generating the directed acyclic graph structure, the event aggregation and parsing module performs a graph normalization process. This normalization includes merging consecutive linear call nodes into composite nodes and adding virtual concurrent edges to operation nodes that do not have explicit parent-child relationships but have overlapping times. The event aggregation and parsing module uses a combination of adjacency lists and attribute matrices to persistently maintain a transaction execution graph carrying causal markers in memory, supporting efficient querying and traversal by subsequent modules.

[0076] In some embodiments, when processing input and output parameter fields to establish call dependencies, the event aggregation and parsing module applies a deterministic parsing rule. This rule stipulates that a parent-child call relationship is confirmed only when the call chain tracing identifiers of two logs satisfy a prefix inclusion relationship and their timestamp intervals overlap; otherwise, the two logs are considered different branches of the same level. The event aggregation and parsing module assigns a dependency strength weight to each identified call relationship. The dependency strength weight is calculated based on the amount of data passed between the calls and is subsequently encoded as an attribute of the directed edge.

[0077] It's understandable that the event aggregation and parsing module performs resource snapshot extraction and appending incrementally. This module maintains a resource snapshot cache. When processing a log entry containing a resource snapshot, it not only appends it to the current node but also updates the latest state of the corresponding resource in the snapshot cache. This allows subsequent nodes to reference the latest value in the cache when appending resource status annotations, reflecting the causal changes in resource states. The event aggregation and parsing module ultimately outputs a transaction execution graph with causal markers. The graph data objects are serialized using a standard graph exchange format and include a version number to identify the graph's construction batch.

[0078] In one embodiment of the present invention, the pattern profiling module continuously receives generated transaction execution graphs carrying causal tags from the output interface of the event aggregation and parsing module. The pattern profiling module sets a historical period time window, and temporarily stores a large number of transaction execution graphs carrying causal tags collected within this time window in a historical graph repository for analysis. The pattern profiling module performs cluster analysis on the topological structure of all transaction execution graphs carrying causal tags in the historical graph repository. The goal of the cluster analysis is to group graphs with similar node connection methods and state transition paths into a transaction behavior pattern. The pattern profiling module first extracts the graph feature vector of each transaction execution graph carrying causal tags. The graph feature vector includes the sequence of node types, the directionality matrix of edges, and the critical path depth. The pattern profiling module uses a density-based clustering algorithm to group all these graph feature vectors. The core of the density clustering algorithm is to calculate the dissimilarity between feature vectors. Vectors with a dissimilarity less than the neighborhood radius and meeting the minimum number requirement are divided into the same cluster, and each cluster represents a transaction behavior pattern.

[0079] In some embodiments, the pattern profiling module extracts key features for each transaction behavior pattern obtained after cluster analysis. The extraction process is based on statistical summarization of all transaction execution graphs carrying causal labels belonging to that pattern. The pattern profiling module calculates the mode of service call depth in that type of graph as the typical service call depth, statistically analyzes the frequency distribution of the number of concurrent execution branch nodes to determine the number of high-frequency concurrent branches, analyzes the locations of nodes in all graphs that lead to transaction state rollback, and identifies the most common node type and resource state combination as common rollback trigger points. The pattern profiling module structures and organizes these key features—typical service call depth, number of high-frequency concurrent branches, and common rollback trigger points—to form a pattern feature description, which is stored in the transaction behavior pattern library in the form of a configuration file.

[0080] It is understandable that the pattern profiling module performs resource pressure profiling while building the transaction behavior pattern library. The module statistically analyzes the resource occupancy levels of key resources within the system when each transaction behavior pattern occurs. It retrieves historical indicators of key resources before and after the transaction's timestamp from historical monitoring data. Key resources include database connection pool usage counts, distributed lock service wait queue lengths, and network bandwidth throughput. Based on the classification tags of transaction behavior patterns, the module categorizes and aggregates the retrieved resource occupancy data, grouping resource data corresponding to all transaction instances within the same pattern category together. The module calculates the statistical characteristics of the aggregated resource data for each pattern category, including the mean, peak, and distribution patterns of resource occupancy obtained through kernel density estimation. The module associates and maps each transaction behavior pattern with its corresponding mean, peak, and distribution patterns of resource occupancy, and creates a resource pressure profiling in the form of charts and data summaries. This resource pressure profiling is stored for querying by the conflict contingency plan module.

[0081] Optionally, the pattern profiling module uses an improved graph similarity metric during the clustering analysis phase. This method considers not only the topological structure but also the sequence of resource state labels on nodes. The dissimilarity between two transaction execution graphs carrying causal labels is calculated using a composite distance formula, defined as:

[0082] in: Representative map With atlas The overall dissimilarity between them Representation of the spectrum With atlas Edit distance on the topology, Representation of the spectrum With atlas Dynamic time-warped distance on the node resource state sequence and These are preset weighting coefficients used to balance the influence of the two distances. The pattern profiling module uses this comprehensive dissimilarity as the input metric for its clustering algorithm.

[0083] In some embodiments, the transaction behavior pattern library maintained by the pattern profiling module supports dynamic updates. The pattern profiling module periodically starts a new clustering analysis cycle. It matches the transaction execution graphs with causal labels generated in the new cycle with the existing transaction behavior pattern library. If the centroid distance between the graph feature vector of the new graph and the existing pattern exceeds a merging threshold, the pattern profiling module considers it a potential new pattern and verifies it. After successful verification, the pattern profiling module creates new transaction behavior pattern entries and updates the resource pressure profile. The pattern profiling module records the distribution pattern of resource usage in the resource pressure profile using a quantile description method, recording the resource usage values ​​at the 10th, 50th, and 90th percentiles to characterize the distribution pattern.

[0084] It's understandable that the pattern profiling module filters out abnormal resource usage data when creating resource pressure profiles. The module sets a standard deviation-based filtering threshold to remove extreme resource usage levels exceeding three times the standard deviation of the mean, ensuring that the resource pressure profile reflects typical resource pressure characteristics. The transaction behavior pattern library and resource pressure profiles output by the pattern profiling module are persistently stored in relational database tables. Each pattern record is associated with a data pointer to both the pattern feature description and the resource pressure profile.

[0085] In one embodiment of the present invention, the conflict contingency plan module continuously monitors the output of the event aggregation and parsing module. The conflict contingency plan module acquires in real-time fragments of the transaction execution graph being constructed, carrying causal markers. It reads feature descriptions of all stored patterns from the transaction behavior pattern library maintained by the pattern profiling module. The conflict contingency plan module performs real-time similarity calculations between the transaction execution graph being constructed and the pattern feature descriptions in the transaction behavior pattern library. First, the conflict contingency plan module extracts the topology feature vector and node attribute feature vector from the currently constructed transaction execution graph up to the current time. The topology feature vector is obtained by analyzing the current structure of the graph, including the currently reached call depth, the number of concurrent branches, and the sequence of node types arranged in execution order. The node attribute feature vector is obtained by aggregating the attributes of existing nodes in the graph, including the set of operation types involved and the frequency of occurrence of these operation types. The conflict contingency plan module reads feature descriptions of each stored pattern from the transaction behavior pattern library. The pattern feature descriptions constructed by the pattern profiling module are pre-encoded into standard reference feature vectors, which also include topology and node attribute parts.

[0086] In some embodiments, the conflict contingency plan module uses a cosine similarity algorithm to calculate the similarity between the topological feature vector of the current graph and the topological part of each reference feature vector, and simultaneously calculates the similarity between the node attribute feature vector of the current graph and the attribute part of each reference feature vector. The calculation of topological similarity involves treating two topological feature vectors as vectors in a multi-dimensional space and calculating the cosine of their angle. The calculation of node attribute similarity involves first converting the set of operation types in the node attribute feature vector into a Boolean vector or a word frequency vector, and then calculating its cosine with the reference attribute vector. The conflict contingency plan module performs a weighted fusion of the calculated topological similarity and node attribute similarity to obtain a comprehensive similarity score between the current graph and each known transaction behavior pattern. The weighted fusion formula is as follows:

[0087] in: Represents the overall similarity score. Represents topological similarity. Represents the similarity of node attributes. These are the preset weighting coefficients for topological similarity. It is a preset weight coefficient for node attribute similarity, and satisfies The conflict contingency module sets a matching threshold. The module marks patterns with a comprehensive similarity score exceeding the matching threshold as candidate patterns that match the current transaction execution graph.

[0088] It is understandable that when the overall similarity score exceeds the matching threshold, the conflict contingency plan module determines that the current transaction is evolving according to a known transaction behavior pattern. Based on the matched transaction behavior pattern, the conflict contingency plan module queries the resource pressure profile drawn by the pattern profiling module. The resource pressure profile describes the distribution pattern of critical resource occupancy under this transaction behavior pattern. Combining the real-time resource level of the current system with the predicted occupancy trend in the resource pressure profile, the conflict contingency plan module predicts resource bottlenecks that the subsequent evolution of the current transaction will cause. The prediction of resource bottlenecks includes predicting the potential exhaustion of the database connection pool based on the peak connection count in the profile, or predicting the potential timeout critical point based on the lock wait time distribution in the profile. Simultaneously, the conflict contingency plan module analyzes the existing node attributes in the current transaction execution graph. It checks whether the node state combinations violate preset consistency rules. These preset consistency rules are defined and pre-configured by the business logic. For example, it checks whether service call nodes with a "committed" status and service call nodes with a "pending rollback" status coexist in the same transaction graph; such a state combination violates atomicity constraints.

[0089] Optionally, when calculating similarity, the conflict contingency module preprocesses the node type sequences in the topological feature vector using an edit distance-based similarity algorithm, converting the sequence similarity into a scalar value between 0 and 1 before participating in the cosine similarity calculation. The conflict contingency module assigns different weights to different types of operation types in the node attribute similarity calculation; for example, the weight of the "write to database" operation is higher than that of the "read from cache" operation, to more accurately reflect the impact of business semantics on pattern matching.

[0090] In some embodiments, the frequency of real-time similarity calculation performed by the conflict contingency module is tied to the update events of the transaction execution graph. Whenever the event aggregation and parsing module adds a new node or updates the state of a node in the current transaction execution graph, the conflict contingency module triggers a new similarity calculation and matching process. The conflict contingency module maintains a matching state machine that records the continuous matching scores and matching trend between the current transaction execution graph and each candidate pattern, used to select the most likely pattern from multiple candidate patterns exceeding the matching threshold. The conflict contingency module marks predicted resource bottlenecks and detected rule-violating states together as potential consistency and resource conflict points. Each conflict point records its type, associated transaction stage, involved service or resource identifier, and severity level.

[0091] Understandably, when predicting resource bottlenecks, the conflict contingency plan module references the distribution pattern of resource usage in the resource pressure profile rather than a single average. For example, if the resource pressure profile shows that database connection usage reaches 85% of the pool capacity at the 90th percentile under a certain mode, the conflict contingency plan module will preemptively mark connection exhaustion as a potential resource conflict point when the current transaction execution graph evolves to a similar stage and real-time connection usage exceeds 70%. The conflict contingency plan module organizes all identified potential consistency and resource conflict points into a list. Each entry in the list is associated with the transaction execution graph node ID that triggered the conflict point identification and the matching transaction behavior pattern ID, providing input for generating an initial intervention plan.

[0092] See Figure 3 This is a two-bar chart comparing the semantic weights of different operation types, clearly showing two key indicators for five core operation types in a distributed transaction scenario. "Write to database" has the highest weight and contribution, indicating that it is the core anchor operation for transaction behavior pattern recognition. This perfectly aligns with the business logic that "write operations are the main source of consistency risk" in distributed transactions. For high-weight, high-contribution operations like "Write to database," its feature dimensions (such as the table name and the number of rows affected by the write operation) can be further refined to improve the accuracy of pattern matching. The contribution of "distributed lock" (approximately 0.79) is higher than its weight (0.2), indicating that it exhibits higher discriminative power in actual pattern matching than its preset weight. Its weight could be appropriately increased to more accurately reflect business semantics.

[0093] In one embodiment of the present invention, the conflict contingency plan module queries the resource pressure profile library constructed by the access pattern profiling module for each marked potential consistency and resource conflict point. The conflict contingency plan module uses the transaction behavior pattern identifier associated with the conflict point as the query key to retrieve the corresponding resource pressure profile data. The conflict contingency plan module analyzes the distribution pattern of resource usage in the resource pressure profile. The distribution pattern is recorded in the form of statistical indicators and percentile values. Based on the distribution pattern, the conflict contingency plan module generates a set of pre-allocation instructions aimed at alleviating predicted resource bottlenecks. For example, when the resource pressure profile shows that the database connection usage is close to the pool capacity limit at the 90th percentile, the conflict contingency plan module generates an instruction to "pre-expand database connections". The instruction includes the target number of connections and the effective time window. When the resource pressure profile shows that the average holding time of the distributed lock increases significantly during peak periods, the conflict contingency plan module generates an instruction to "temporarily increase the lock lease duration". The instruction specifies the new lease duration and the applicable lock type. The logic for generating pre-allocation instructions follows a threshold-based decision function. The decision function compares the historical peak value in the resource pressure profile, the current real-time utilization rate, and the preset safety threshold to trigger different levels of allocation operations. The pre-allocation instructions are formatted into a standardized operation sequence that can be recognized by the system resource management interface.

[0094] In some embodiments, the conflict contingency module analyzes the current progress of the transaction execution graph. It iterates through all service call nodes in the current transaction execution graph, each carrying a causal label, that are in a state of "not executed" or "in progress." Based on the service deployment topology and health status information, the module calculates one or more alternative routing paths for each subsequent service call that has not yet been executed. The calculation aims to avoid service nodes that may cause consistency issues in subsequent evolutions. For example, if a service node has a high historical failure rate or its current dependent data shard is under maintenance, that service node will be marked as a node to be avoided. The module applies a routing cost algorithm to evaluate each alternative path. The routing cost comprehensively considers network latency, service load, and the deviation of the path from the ideal transaction semantics. The module selects the path with the lowest routing cost that does not pass through the avoided node as the recommended transaction routing suggestion. The transaction routing suggestion is specifically represented as an ordered list of service instance accesses or an adjustment parameter for a load balancing strategy.

[0095] Understandably, the conflict contingency plan module encapsulates pre-deployment instructions and transaction routing suggestions for the same conflict point, creating a structured contingency plan object during the encapsulation process. This object contains a unique contingency plan identifier, an associated conflict point identifier, an associated transaction execution graph stage identifier, a list of pre-deployment instructions, and a list of transaction routing suggestions. The module binds each initial intervention contingency plan to a conflict point and transaction stage based on the conflict point's position coordinates in the transaction execution graph and the global state of the graph. For example, a contingency plan might be bound to the specific stage of "level 3 call in the transaction execution graph, before inventory service updates." Initial intervention contingency plans are stored in an in-memory contingency plan pool and assigned a priority score, determined by the severity of the conflict point and the estimated execution cost of the contingency plan.

[0096] Optionally, when generating pre-allocation instructions, the conflict contingency plan module will refer to a mapping rule table between resource profiles and instructions. This table defines standard response operations under different resource pressure modes. An example of Table 1 is shown below:

[0097] Table 1: Mapping Rules between Resource Profiles and Commands

[0098] Transaction behavior pattern Resource types Stress characteristics (90th percentile) Pre-configuration instruction type Command parameter examples Mode A (Order Creation) Database connection Occupancy rate > 80% Connection pre-expansion Increase connection count: +20% Mode A (Order Creation) Distributed Locks Waiting time > 200ms Lock-in lease enhancement Lease Length: +150% Mode B (Inventory Deduction) Message Queue Backlog of messages > 1000 Temporary expansion for consumers Added 2 instances

[0099] Based on the table above, the conflict contingency module generates a corresponding "connection pre-expansion" instruction when it identifies that a transaction follows mode A evolution and the current real-time database connection occupancy rate reaches 75%.

[0100] In some embodiments, the conflict contingency plan module uses a path weight formula to quantify the suitability of each candidate path when calculating transaction routing recommendations. The path weight formula is expressed as:

[0101] in: Representative path The overall weight (the smaller the value, the higher the priority). Representative path The estimated normalized value of network latency. Representative path The current load normalization value of the target service instance. Representative path Deviation from the original transaction semantic path These are weighting coefficients for latency, load, and semantic deviation, respectively. The conflict contingency module calculates all feasible paths for each subsequent service call that requires routing. Value, and select The path with the smallest value is included in the transaction routing suggestion.

[0102] It is understandable that the initial intervention plans generated by the conflict contingency plan module are transient and revocable. The conflict contingency plan module sets a time-to-live (TTL) for each plan. If the corresponding transaction phase has safely passed or the conflict point disappears for other reasons within the TTL, the conflict contingency plan module will actively remove the plan from the plan pool. The conflict contingency plan module outputs the encapsulated initial intervention plan to a message bus or directly writes it to shared storage for the simulation decision-making module to subscribe to and pull. The output includes the complete serialized data of the plan object, as well as the plan's generation timestamp and version signature.

[0103] See Figure 4 This is a bar chart comparing resource pressure and pre-allocation trigger thresholds for different transaction modes. It shows the resource pressure characteristics, pre-allocation trigger thresholds, and mitigation effects of four core transaction behavior modes in a distributed transaction scenario. It serves as the core decision-making basis for the conflict contingency plan module to generate pre-allocation instructions. The mitigation effect for all modes is in the range of 0.18–0.25, indicating that the pre-allocation instructions can stably reduce resource pressure by approximately 20%, verifying the feasibility of this strategy. Dynamic trigger thresholds can be configured for different modes based on real-time traffic data, rather than fixed values, to balance resource utilization and system stability. The quantitative data on mitigation effects can be directly used to verify the effectiveness of the pre-allocation plan, providing closed-loop feedback for subsequent plan iterations and automation.

[0104] In one embodiment of the present invention, the simulation decision module incorporates a transaction outcome simulator. This simulator maintains a virtual system state environment that replicates the real-time capacity and allocation status of key resources in the real system, including the number of available connections in the database connection pool, the lock holding status in the distributed lock service, and the backlog depth of the message queue. The transaction outcome simulator receives a preliminary intervention plan from the conflict contingency plan module. It loads the current transaction execution graph with causal tags and initializes the state of the graph to the pending transactions in the virtual environment. This initialization process includes creating the corresponding transaction context and resource snapshot in the virtual environment. The simulator sequentially executes the pre-allocation instructions in the preliminary intervention plan, such as "pre-expanding database connections" or "temporarily increasing lock lease duration." The simulator updates the availability status of resources in the virtual environment to reflect the effects of the instructions. Simultaneously, it records the resource change history in the virtual environment for rollback analysis.

[0105] In some embodiments, the transaction outcome simulator simulates the subsequent progression of the transaction execution graph in a virtual environment according to the transaction routing suggestions in the initial intervention plan. The simulator simulates call requests and responses for each virtual service node, and the behavior of the virtual service nodes is generated based on historical response time distribution and a failure probability model. The simulator records the response and state transitions of each virtual service node, including operation success, operation failure, or operation timeout. Simultaneously, the simulator tracks the intermediate state changes of data replicas in the virtual environment. When the virtual transaction reaches the final state of commit or rollback, the simulator collects the final state of all relevant data replicas in the entire virtual environment, as well as the final state of all branches of the transaction. The simulator integrates these state data into a deduced transaction termination state, which includes the commit or rollback point records of all branches and the final values ​​of the data items.

[0106] In practical implementation, the simulation decision module evaluates whether the transaction termination state meets the preset eventual consistency or strong consistency criteria. The module reads the consistency criterion definition from the configuration. Eventual consistency is defined as all relevant data replicas reaching a consistent state after an acceptable time delay in the transaction termination state. Strong consistency is defined as all relevant data replicas and all external observers being able to immediately read the same latest data in the transaction termination state. The simulation decision module checks the transaction termination state output by the transaction termination simulator. It verifies whether the final values ​​of all data replicas conform to the constraints defined in the business logic, such as verifying that inventory quantities cannot be negative or the total account balance remains unchanged. For eventual consistency, the simulation decision module also injects simulated time delays and subsequent read requests into the virtual environment. It verifies the data consistency after the delay, i.e., whether the read values ​​of all replicas converge to the same state after the specified delay. The simulation decision module outputs a Boolean evaluation result, which directly indicates whether the termination state fully meets the selected consistency criterion. The evaluation result is appended to the simulation report for further processing.

[0107] Understandably, when the evaluation result is unsatisfactory, the simulation decision-making module analyzes the virtual simulation process log recorded in the transaction outcome simulator. This log details the resource status changes and service responses for each simulation step. The simulation decision-making module identifies the key decision points leading to the violation of consistency standards. These key decision points might be due to inappropriate timing of a resource allocation instruction or the selection of a high-latency node for a transaction routing suggestion. The simulation decision-making module relaxes or tightens one or more constraints in the initial intervention plan. These constraints include the magnitude of resource allocation, the priority of routing path selection, or the transaction isolation level. For example, it might increase the database connection expansion from 20% to 30%, or lower the routing priority of a service from high to low. The simulation decision-making module then modifies the initial intervention plan using the adjusted constraints, generating a new candidate intervention plan. This new candidate intervention plan includes updated pre-allocation instructions and transaction routing suggestions.

[0108] In some embodiments, the simulation decision-making module uses a constraint adjustment function to calculate new constraint values. The constraint adjustment function is optimized based on historical simulation results. For the adjustment of resource allocation magnitude A, the formula is used:

[0109]

[0110] in: This represents the adjusted range of resource allocation. This represents the extent of resource allocation before the adjustment. The preset learning rate parameter is used to control the adjustment step size. This is a sign function of the evaluation result, incrementing by 1 when the evaluation result is satisfied and decrementing by 1 when the evaluation result is not satisfied. The simulation decision module resubmits the new candidate intervention plan to the transaction outcome simulator for simulation and re-evaluates its final state. It iteratively executes the steps of locating key decision points, adjusting constraints, generating new plans, and re-simulating and evaluating until the final state evaluation result output by the transaction outcome simulator is satisfied. At this point, the simulation decision module determines the candidate intervention plan used in the last round as the final execution plan. The final execution plan is formatted into an executable instruction set and distributed to the real resource manager and service routing components through the control channel. The final execution plan guides the real system to perform resource allocation and transaction routing to ensure transaction consistency.

[0111] Optionally, the virtual system state environment of the transaction outcome simulator is driven by a discrete event simulation engine. The time progression and event processing sequence in the virtual system state environment follow a preset simulation clock rule. When simulating the subsequent progression of the transaction execution graph, the transaction outcome simulator introduces random factors to simulate the uncertainty of real networks and services. Random factors include network jitter simulation and random failure of service nodes. The transaction outcome simulator maintains an independent fault injector for each virtual service node. The fault injector determines whether the node returns an error response based on a preset probability distribution.

[0112] Optionally, the simulation decision-making module employs gradient descent when adjusting constraints. It calculates the gradient direction of consistency violations based on the virtual simulation process log and adjusts the constraint values ​​along the direction that reduces violations. The module sets a maximum number of iterations or a threshold for meeting the consistency criterion. It iterates until the final state evaluation result output by the transaction outcome simulator is satisfactory. If the criterion is not met even after reaching the maximum number of iterations, the module initiates a degradation process, which uses a default conservative approach as the final execution plan.

[0113] Understandably, when evaluating the final state, the simulation decision-making module immediately checks the consistency of the data replicas for strong consistency criteria, and initiates an asynchronous verification routine for eventual consistency criteria. This asynchronous verification routine checks the convergence of the data replicas after a virtual time delay. The adjustment and re-deduction loop of the simulation decision-making module can execute the deduction of multiple candidate plans in parallel. The simulation decision-making module uses multi-threading or distributed computing to accelerate the search for the final execution solution that meets the criteria. The simulation decision-making module allocates an independent simulation thread and virtual environment replica for each candidate plan to avoid mutual interference between deductions.

[0114] See Figure 5 This is a resource comparison chart before and after the execution of pre-allocation instructions. It shows the state changes of four core resources and the corresponding simulation error rates in the transaction outcome simulator before and after the execution of pre-allocation instructions. It is a key basis for verifying the effectiveness of pre-allocation instructions. Before the instructions were executed, the message queue backlog reached as high as 1200, which was the most serious bottleneck among all resources. After executing pre-allocation instructions (such as consumer expansion), the backlog dropped to 800, with a significant relief effect (approximately 33%). At the same time, the simulation error rate also reached its peak (0.12), indicating that this scenario had the highest complexity and risk. The peak simulation error rate perfectly matches the highest pressure of the message queue, verifying the business logic that "the higher the resource pressure, the greater the simulation execution risk," and also indicating that the message queue pre-allocation strategy needs to be focused on and continuously optimized.

[0115] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A distributed transaction consistency guarantee system for microservice architecture, characterized in that, include: The event aggregation and parsing module is used to aggregate local logs from the transaction coordinator and various participating services in real time, forming a raw event stream containing transaction execution traces and resource snapshots. The raw event stream is then parsed and reconstructed in multiple stages to extract transaction identifiers and operation sequences, supplement resource occupancy levels based on resource snapshots, and generate a transaction execution graph with causal tags. The pattern profiling module is used to build a transaction behavior pattern library and resource pressure profile based on the historical baseline of the transaction execution graph's topology and resource usage levels. The conflict contingency plan module is used to match the real-time acquired transaction execution graph fragments with the transaction behavior pattern library to identify potential consistency and resource conflict points. Combined with the resource pressure profile, it generates a preliminary intervention plan for each conflict point, which includes resource allocation instructions and transaction routing suggestions. The simulation decision module is used to input the preliminary intervention plan into the transaction outcome simulator, deduce the final state of the entire transaction execution graph after the execution of the preliminary intervention plan, evaluate whether the final state meets the preset eventual consistency or strong consistency criteria, and determine the corresponding preliminary intervention plan as the final execution plan when the criteria are met; if the criteria are not met, the constraints of the preliminary intervention plan are adjusted and the simulation is repeated until a final execution plan that meets the criteria is obtained. The process of performing multi-stage parsing and reconstruction of the original event stream to extract transaction identifiers and operation sequences, supplementing resource occupancy levels based on resource snapshots, and generating a transaction execution graph with causal markers specifically includes: Separate all log entries belonging to the same global transaction identifier from the original event stream and sort them by timestamp to form the original operation chain; Analyze the operation type and input / output parameters of each log in the original operation chain, infer the call dependencies between services, and convert the operation chain into a directed acyclic graph structure; From the resource snapshot of the original event stream, extract the database lock holding state, message queue offset and cache version number corresponding to each operation execution time, and attach them as resource state labels to the corresponding nodes of the directed acyclic graph structure; The directed acyclic graph structure is merged and encoded with the additional resource status labels to generate a graph data object containing node attributes and edge attributes, which is the transaction execution graph with causal labels.

2. The distributed transaction consistency guarantee system for microservice architecture according to claim 1, characterized in that, Based on the historical baseline of the transaction execution graph's topology and resource consumption levels, a transaction behavior pattern library and resource pressure profile are constructed, specifically including: Collect a large number of transaction execution graphs with causal labels generated within the historical period, perform cluster analysis on the topology of the graphs, and group graphs with similar node connection methods and state transition paths into a transaction behavior pattern. Key features are extracted for each transaction behavior pattern, including typical service call depth, number of high-frequency concurrent branches, and common rollback trigger points, forming a pattern feature description; Statistics are collected on the utilization levels of key resources within the system when each transaction behavior pattern occurs. These key resources include the database connection pool, distributed lock service, and network bandwidth. Resource usage data is categorized and aggregated according to transaction behavior patterns. The mean, peak, and distribution patterns of resource usage under each pattern are calculated to create a resource pressure profile.

3. The distributed transaction consistency guarantee system for microservice architecture according to claim 2, characterized in that, The real-time acquired transaction execution graph fragments are matched with a transaction behavior pattern library to identify potential consistency and resource conflict points, specifically including: The system performs real-time similarity calculations between the transaction execution graph carrying causal labels that is being constructed and the pattern feature descriptions in the transaction behavior pattern library. When the similarity exceeds the matching threshold, it is determined that the current transaction is evolving in accordance with a certain known transaction behavior pattern; Based on the resource pressure profile corresponding to the matched transaction behavior pattern, predict the resource bottlenecks that will be caused by the subsequent evolution of the current transaction. The resource bottlenecks include connection exhaustion or lock wait timeout. At the same time, the existing node attributes in the current transaction execution graph are analyzed to detect whether there are state combinations that violate the preset consistency rules. The state combinations include the coexistence of committed branches and branches to be rolled back. The predicted resource bottlenecks are combined with the detected rule-violating states to mark potential consistency and resource conflict points.

4. The distributed transaction consistency guarantee system for microservice architecture according to claim 3, characterized in that, Based on resource pressure profiles, a preliminary intervention plan is generated for each conflict point, including resource allocation instructions and transaction routing suggestions. Specifically, this includes: For each marked potential consistency and resource conflict point, query the resource pressure profile of its corresponding transaction behavior pattern; Based on the distribution pattern of resource usage in the resource pressure profile, a set of pre-allocation instructions is generated to alleviate the predicted resource bottleneck. The pre-allocation instructions include pre-expanding database connections or temporarily increasing the lock lease duration. Analyze the current progress of the transaction execution graph, calculate alternative routing paths for subsequent service calls that have not yet been executed, in order to avoid service nodes that may cause consistency issues in subsequent evolution, and form transaction routing suggestions; The pre-allocation instructions and transaction routing suggestions for the same conflict point are encapsulated to form a complete preliminary intervention plan, with each plan bound to a specific conflict point and transaction phase.

5. The distributed transaction consistency guarantee system for microservice architecture according to claim 4, characterized in that, The preliminary intervention plan is input into the transaction outcome simulator to simulate the final state of the entire transaction execution graph after the preliminary intervention plan is executed, specifically including: The transaction outcome simulator maintains a virtual system state environment that replicates the real-time capacity and allocation status of critical resources in the real system. The transaction outcome simulator loads the current transaction execution graph carrying causal tags and initializes its state as pending transactions in the virtual environment; The event outcome simulator sequentially executes the pre-allocation instructions in the initial intervention plan and updates the availability status of resources in the virtual environment; The transaction outcome simulator simulates the subsequent progress of the transaction execution graph in a virtual environment, following the transaction routing suggestions in the initial intervention plan, and records the response and state transition of each virtual service node. When a virtual transaction reaches the final state of commit or rollback, the transaction termination simulator collects the final state of all relevant data copies in the entire virtual environment, as well as the final state of all branches of the transaction, as the deduced transaction termination state.

6. The distributed transaction consistency guarantee system for microservice architecture according to claim 5, characterized in that, Evaluate whether the final state meets the preset eventual consistency or strong consistency criteria, specifically including: The eventual consistency criterion is defined as follows: at the end of a transaction, all relevant data replicas can reach a consistent state after an acceptable time delay. The strong consistency criterion is defined as follows: at the end of a transaction, all relevant data copies and all external observers can immediately read the same latest data. Check the transaction termination status output by the transaction termination simulator to verify whether the final values ​​of all data replicas conform to the constraints defined in the business logic. For eventual consistency criteria, it is also necessary to inject simulated time delays and subsequent read requests into the virtual environment to verify the data consistency after the delay; Output a Boolean evaluation result indicating whether the final state fully satisfies the selected consistency criterion.

7. The distributed transaction consistency guarantee system for microservice architecture according to claim 6, characterized in that, If the conditions are not met, the constraints of the initial intervention plan will be adjusted and the scenario re-analyzed until a final implementation plan that meets the criteria is obtained, specifically including: When the evaluation result is not met, analyze the virtual simulation process log recorded in the transaction outcome simulator to locate the key decision point that led to the violation of the consistency standard; Relax or tighten one or more constraints in the initial intervention plan, including the extent of resource allocation, the priority of routing path selection, or the isolation level of transactions; Using the adjusted constraints, modify the initial intervention plan and generate a new candidate intervention plan; The new candidate intervention plan will be resubmitted to the event outcome simulator for simulation and its final status will be reassessed. The process involves iteratively locating key decision points, adjusting constraints, generating new contingency plans, and re-analyzing and evaluating the results until the final state evaluation result output by the transaction outcome simulator is satisfactory. At this point, the candidate intervention plan used in the last round is determined as the final execution plan.

8. The distributed transaction consistency guarantee system for microservice architecture according to claim 7, characterized in that, The analysis of the operation type and input / output parameters of each log entry in the original operation chain, inferring the call dependencies between services, and converting the operation chain into a directed acyclic graph structure specifically includes: Parse each log record in the original operation chain and extract its operation type field and input / output parameter fields; Based on the global transaction identifier and call chain tracing identifier carried in the input and output parameter fields, establish the parent-child call relationship between log entries generated by different services; Each independent service call operation is instantiated as a node in a directed acyclic graph, and the node's attributes include the service identifier and the operation type; Based on the parent-child call relationship, a directed edge is added to the directed acyclic graph, pointing from the parent call node to the child call node, to represent the call dependency between services; By traversing and verifying all nodes and edges, it is ensured that there are no cyclic dependent paths in the graph, thus completing the transformation from the original operation chain to the directed acyclic graph structure.

9. The distributed transaction consistency guarantee system for microservice architecture according to claim 8, characterized in that, The step of performing real-time similarity calculation between the transaction execution graph carrying causal labels that is being constructed and the pattern feature descriptions in the transaction behavior pattern library specifically includes: From the transaction execution graph currently being constructed, extract its topology feature vector and node attribute feature vector up to the current time. The topology feature vector includes the current depth, number of branches, and node type sequence, and the node attribute feature vector includes the set of operation types involved. Read the feature description of each stored pattern from the transaction behavior pattern library and encode it into a standard reference feature vector; The cosine similarity algorithm is used to calculate the similarity between the topological feature vector of the current graph and the topological part of each reference feature vector, and at the same time, the similarity between the node attribute feature vector and the attribute part of each reference feature vector is calculated. The topological similarity and the node attribute similarity are weighted and fused to obtain the comprehensive similarity score between the current graph and each known transaction behavior pattern; A matching threshold is set, and patterns with a comprehensive similarity score exceeding the matching threshold are marked as candidate patterns that match the current transaction execution graph.

Images