Consistency verification methods, related devices, and storage media for distributed systems

Abstract

This application discloses a consistency verification method and related apparatus and storage medium for a distributed system. The method includes: constructing a business semantic topology of the distributed system; dynamically identifying key time points of a target distributed transaction based on the business semantic topology; wherein the key time points include the transaction preparation completion time point and the global commit completion time point; determining the critical state window of the target distributed transaction based on the key time points; injecting disturbances into some participating services of the target distributed transaction within the critical state window based on the business semantic topology; collecting the operating indicators of the distributed system in real time based on the business semantic topology; predicting whether the distributed system has an instability risk in real time based on the current operating indicators and historical operating indicators; if an instability risk exists, stopping the disturbance injection and performing state rollback or configuration recovery; and performing consistency verification of the target distributed transaction based on the state change results of the distributed system before and after the exercise.

Description

Technical Field

[0001] This application relates to the field of system testing technology, and in particular to a consistency verification method for distributed systems, as well as related devices and storage media. Background Technology

[0002] In complex business systems such as e-commerce, finance, and internet platforms, business processes such as orders, inventory, points, and gift cards are typically deployed independently as microservices, forming a distributed system. Eventual consistency between different services is achieved through distributed transaction protocols or message brokers.

[0003] To verify the consistency capability of distributed transactions in a distributed system, it is necessary to frequently rehearse scenarios where distributed transactions are disturbed, thus verifying the ability to maintain consistency under disturbances. Current methods for rehearsing and injecting faults into distributed systems primarily involve manual script injection, rule-driven injection, or random disturbance injection, injecting random or full-link disturbances into the service. Consistency verification is then performed subsequently through log analysis or tracing, i.e., post-event diagnostic analysis of defects affecting consistency. Furthermore, passive recovery is implemented after a failure to restore the distributed system.

[0004] However, random or full-link perturbation methods lack precise constraints, easily leading to widespread system anomalies and posing significant risks. Furthermore, they contradict the reality that consistency defects only surface during specific transaction participants and state transition sequences, making it difficult to verify actual situations and obtain accurate results. Moreover, post-event diagnostics cannot pinpoint which time intervals influence the triggering of consistency defects during transaction execution, thus failing to provide accurate results. Passive recovery after a failure occurs cannot predict or proactively reverse the process before the system enters an irreversible and unstable state, thus posing significant production risks. Summary of the Invention

[0005] In view of the shortcomings of the prior art, this application provides a consistency verification method, related apparatus and storage medium for distributed systems, so as to solve the problem that the prior art cannot accurately perform consistency verification while ensuring system security.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] The first aspect of this application provides a consistency verification method for a distributed system, including:

[0008] Construct the business semantic topology of the distributed system;

[0009] Based on the business semantic topology, the key time points of the target distributed transaction in the distributed system are dynamically identified; wherein, the key time points include the transaction preparation completion time point and the global commit completion time point.

[0010] The critical state window of the target distributed transaction is determined based on the key time points;

[0011] Based on the business semantic topology, asymmetric perturbation injection is performed on some participating services of the target distributed transaction within the critical state window;

[0012] Based on the business semantic topology, the operating metrics of the distributed system are collected in real time.

[0013] The system can predict in real time whether the distributed system is at risk of instability based on current and historical operating indicators.

[0014] If the distributed system is predicted to be at risk of instability, the disturbance injection is stopped and a state rollback or configuration recovery is performed.

[0015] Based on the state change results of the distributed system before and after the exercise, the consistency verification of the target distributed transaction is performed to obtain the consistency verification result.

[0016] Optionally, in the above-described method for consistency verification in a distributed system, the step of constructing the business semantic topology of the distributed system includes:

[0017] Collect call information and transaction identification information between various services in the distributed system, and parse the call information and transaction identification information to obtain a globally unique identifier for each distributed transaction in the distributed system;

[0018] Based on the globally unique identifier of each distributed transaction, determine the participation relationship, dependency order, and transaction depth of each service in the same distributed transaction;

[0019] Based on the participation relationships, dependency order, and transaction depth of each service in the same distributed transaction, the business semantic topology of the distributed transaction of the distributed system is constructed.

[0020] Optionally, in the above-described consistency verification method for distributed systems, the step of dynamically identifying the key time points of the target distributed transaction in the distributed system based on the business semantic topology includes:

[0021] For the target distributed transaction in the distributed system, state transition events are monitored in real time during the execution of the target distributed transaction;

[0022] When the initiation service of the target distributed transaction is detected, and the transaction transitions to the exact completion state after completing the local state persistence, the current time point is obtained to obtain the transaction preparation completion time point.

[0023] The global commit completion time is obtained when all participating services of the target distributed transaction have transitioned to the completed state and returned confirmation results.

[0024] Optionally, in the above-described consistency verification method for distributed systems, determining the critical state window of the target distributed transaction based on the key time points includes:

[0025] The time range from the transaction preparation completion time plus the target time offset to the global commit completion time minus the safety boundary time is determined as the critical state window of the target distributed transaction; wherein, the target time offset is the minimum stable time offset for filtering system jitter; and the safety boundary time is the reserved safety boundary time for system self-healing and rollback.

[0026] Optionally, in the above-described consistency verification method for distributed systems, the step of implementing asymmetric perturbation injection on some participating services of the target distributed transaction within the critical state window based on the business semantic topology includes:

[0027] Under the constraint of satisfying consistency verification, based on the business semantic topology, a portion of the participating services in the target distributed transaction within the critical state window are selected according to a set priority to implement asymmetric disturbance injection; wherein, the constraint includes that the target distributed transaction has completed local state commit and cannot be rolled back, at least one participating service has not completed state commit, and the global compensation or rollback mechanism has not been triggered.

[0028] Optionally, in the above-described consistency verification method for distributed systems, the step of predicting in real-time whether the distributed system has a risk of instability based on current and historical operating indicators includes:

[0029] By analyzing the trend of indicator changes in real time using current operating indicators and historical operating indicators within the most recent specified time period, the instability risk assessment indicators of the distributed system are obtained.

[0030] Analyze whether the instability risk assessment index of the distributed system exceeds the corresponding threshold;

[0031] If the instability risk assessment index of the distributed system exceeds the corresponding threshold, it is determined that the distributed system has an instability risk.

[0032] Optionally, in the above-described method for verifying the consistency of a distributed system, the step of performing consistency verification on the target distributed transaction based on the state change results of the distributed system before and after the exercise to obtain the consistency verification result includes:

[0033] Based on the business semantic topology, determine each participating service and its target business field of the target distributed transaction;

[0034] Based on the target business fields of each participating service, obtain the actual final business state of each participating service after the exercise;

[0035] Based on the target business fields of each participating service, determine the initial business state of each participating service before the exercise, and based on the initial business state of each participating service, determine the expected final business state of each participating service.

[0036] The consistency verification result of the target distributed transaction is determined by comparing the actual business final state of each participating service with the expected business final state.

[0037] A second aspect of this application provides a consistency verification apparatus for a distributed system, comprising:

[0038] Building units are used to construct the business semantic topology of distributed systems;

[0039] The time recognition unit is used to dynamically identify the key time points of the target distributed transaction in the distributed system based on the business semantic topology; wherein, the key time points include the transaction preparation completion time point and the global commit completion time point;

[0040] A window determination unit is used to determine the critical state window of the target distributed transaction based on the key time points.

[0041] The perturbation injection unit is used to perform asymmetric perturbation injection on some participating services of the target distributed transaction within the critical state window based on the business semantic topology.

[0042] The indicator collection unit is used to collect the operational indicators of the distributed system in real time based on the business semantic topology.

[0043] The risk assessment unit is used to predict in real time whether the distributed system is at risk of instability based on current and historical operating indicators.

[0044] The termination unit is used to terminate the disturbance injection and perform state rollback or configuration recovery when it is predicted that there is a risk of instability in the distributed system.

[0045] The verification unit is used to perform consistency verification on the target distributed transaction based on the state change results of the distributed system before and after the exercise, and obtain the consistency verification result.

[0046] Optionally, in the above-described consistency verification device for a distributed system, the construction unit includes:

[0047] The information acquisition unit is used to collect call information and transaction identification information between various services in the distributed system;

[0048] The parsing unit is used to parse the call information and the transaction identification information to obtain the globally unique identifier of each distributed transaction in the distributed system.

[0049] The information determination unit is used to determine the participation relationship, dependency order and transaction depth of each service in the same distributed transaction based on the globally unique identifier of each distributed transaction.

[0050] The topology construction unit is used to construct the business semantic topology of the distributed transaction of the distributed system based on the participation relationship, dependency order and transaction depth of each service in the same distributed transaction.

[0051] Optionally, in the above-described consistency verification device for a distributed system, the time identification unit includes:

[0052] The event monitoring unit is used to monitor state transition events in real time during the execution of the target distributed transaction in the distributed system.

[0053] The first-time acquisition unit is used to obtain the current time point when the initiation service of the target distributed transaction is detected and the transaction transitions to the accurate completion state after completing the local state persistence, so as to obtain the transaction preparation completion time point.

[0054] The second time acquisition unit is used to obtain the current time point when it is detected that all participating services of the target distributed transaction have transitioned to the completed state and returned the confirmation result, so as to obtain the global commit completion time point.

[0055] Optionally, in the above-described consistency verification device for a distributed system, the window determination unit includes:

[0056] The window determination sub-unit is used to determine the critical state window of the target distributed transaction by the time range from the transaction preparation completion time point plus the target time offset to the global commit completion time point minus the safety boundary time; wherein, the target time offset is the minimum stable time offset for filtering system jitter; and the safety boundary time is the reserved safety boundary time for system self-healing and rollback.

[0057] Optionally, in the above-described consistency verification device for a distributed system, the disturbance injection unit includes:

[0058] The perturbation injection subunit is used to select a portion of the participating services of the target distributed transaction within the critical state window and implement asymmetric perturbation injection based on the business semantic topology and according to a set priority, under the constraint of satisfying consistency verification; wherein, the constraint includes that the target distributed transaction has completed local state commit and cannot be rolled back, at least one participating service has not completed state commit, and the global compensation or rollback mechanism has not been triggered.

[0059] Optionally, in the above-described consistency verification device for a distributed system, the risk assessment unit includes:

[0060] The indicator calculation unit is used to analyze the trend of indicator changes in real time using the current operating indicators and the historical operating indicators within the most recent specified time period to obtain the instability risk assessment indicators of the distributed system.

[0061] The indicator analysis unit is used to analyze whether the instability risk assessment indicators of the distributed system exceed the corresponding thresholds.

[0062] The result determination unit is used to determine that the distributed system has an instability risk if the instability risk assessment index of the distributed system exceeds the corresponding threshold.

[0063] Optionally, in the above-described consistency verification device for a distributed system, the verification unit includes:

[0064] The field determination unit is used to determine each participating service and its target business field of the target distributed transaction based on the business semantic topology.

[0065] The first state acquisition unit is used to acquire the actual final state of each participating service after the exercise based on the target business fields of each participating service.

[0066] The second state acquisition unit is used to determine the initial business state of each participating service before the exercise based on the target business fields of each participating service, and to determine the expected final business state of each participating service based on the initial business state of each participating service.

[0067] The comparison unit is used to determine the consistency verification result of the target distributed transaction by comparing the actual business final state of each participating service with the expected business final state.

[0068] A third aspect of this application provides an electronic device, comprising:

[0069] Memory and processor;

[0070] The memory is used to store programs;

[0071] The processor is used to execute the program, which, when executed, is specifically used to implement the consistency verification method of the distributed system as described in any of the above.

[0072] The fourth aspect of this application provides a computer storage medium for storing a computer program, which, when executed by a processor, is used to implement the consistency verification method of a distributed system as described in any of the preceding claims.

[0073] This application provides a consistency verification method for distributed systems. It constructs a business semantic topology for the distributed system to facilitate precise perturbation injection and consistency verification. Based on the business semantic topology, it dynamically identifies key time points of the target distributed transaction. These key time points include the transaction preparation completion time and the global commit completion time. Then, it determines the critical state window of the target distributed transaction based on the key time points. Using the business semantic topology, it performs asymmetric perturbation injection on some participating services within the critical state window. This dynamically determines the millisecond-level critical time window during the distributed transaction state transition process through online calculation, strictly confining the perturbation injection behavior within this critical window, acting only on transaction participants. This ensures asymmetric perturbation is implemented within a controllable range, stably triggering consistency defects with minimal perturbation intensity. This allows for accurate analysis of the time interval where impact occurs without causing widespread system anomalies. Finally, it collects real-time operational metrics of the distributed system based on the business semantic topology to predict the potential for instability based on current and historical operational metrics. When a risk of instability is predicted in the distributed system, the disturbance injection is stopped and state rollback or configuration recovery is performed. This extracts the predicted risk and allows for timely cessation and recovery of state or configuration, thus controlling the risk and preventing significant consequences. Finally, based on the state changes of the distributed system before and after the exercise, the consistency of the target distributed transaction is verified, yielding the consistency verification result. This demonstrates a method for accurately verifying the consistency of distributed transactions while ensuring system security boundaries. Attached Figure Description

[0074] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0075] Figure 1 A flowchart illustrating a consistency verification method for a distributed system provided in this application embodiment;

[0076] Figure 2 A flowchart illustrating a method for constructing a business semantic topology of a distributed system, as provided in this application embodiment;

[0077] Figure 3 A flowchart illustrating a method for dynamically identifying key time points of a target distributed transaction, as provided in an embodiment of this application;

[0078] Figure 4 A flowchart illustrating a method for predicting the instability risk of a distributed system, as provided in an embodiment of this application;

[0079] Figure 5 A flowchart illustrating a method for consistency verification based on state change results, provided in an embodiment of this application;

[0080] Figure 6 A schematic diagram of the architecture of a consistency verification device for a distributed system provided in this application embodiment;

[0081] Figure 7 This is a schematic diagram of the architecture of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0083] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0084] The first aspect of this application provides a consistency verification method for a distributed system, such as... Figure 1 As shown, it includes:

[0085] S101. Construct the business semantic topology of the distributed system.

[0086] It should be noted that, in order to accurately identify the nodes where the disturbance is implemented, clarify the order of calls between services, determine key time points, and identify the risk impact domain of the exercise, a business semantic topology is constructed based on the information of each service in the distributed system when implementing each distributed transaction. This topology reflects the information of each service participating in the execution of each distributed transaction and the dependencies between each service.

[0087] Optionally, in another embodiment of this application, one specific implementation of step S101 is as follows: Figure 2 As shown, it includes the following steps:

[0088] S201. Collect the call information and transaction identification information between various services in the distributed system, and parse the call information and transaction identification information to obtain the globally unique identifier of each distributed transaction in the distributed system.

[0089] Optionally, the call information and physical identification information between various services in the distributed system can be collected in a non-intrusive manner, and this information can be parsed to obtain the globally unique identifier of each distributed transaction in the distributed system. Based on the globally unique identifier of each distributed transaction, the information of each distributed transaction can be located, which is used to construct the business semantic topology of the distributed transactions.

[0090] S202. Based on the globally unique identifier of each distributed transaction, determine the participation relationship, dependency order, and transaction depth of each service in the same distributed transaction.

[0091] Specifically, the globally unique identifier of a distributed transaction is dynamically mapped and associated with the system's thread context, local database branch transactions, and database connection handles in real time. This allows for the location of relevant information about the distributed transaction based on the association, namely, obtaining the participation relationship, dependency order, and transaction depth of each service in the same distributed transaction.

[0092] S203. Based on the participation relationship, dependency order, and transaction depth of each service in the same distributed transaction, construct the business semantic topology of the distributed transaction of the distributed system.

[0093] Specifically, based on the participation relationships, dependency order, and transaction depth of each service in the same distributed transaction, the business semantic topology of each distributed transaction in the distributed system is constructed.

[0094] S102. Based on business semantic topology, dynamically identify the key time points of the target distributed transactions in the distributed system.

[0095] The key time points include the transaction preparation completion time and the global commit completion time. The target distributed transaction is any distributed transaction in the distributed system.

[0096] It should be noted that, in order to accurately locate the time interval that affects consistency defects, ensure that the disturbances conform to the actual occurrence of consistency defects, guarantee the accuracy of the results, and avoid significant risks to the system, the millisecond-level critical time during the state transition of the distributed transaction is dynamically determined in this embodiment of the application to define the critical time window. This allows the disturbance injection behavior to be strictly constrained within the critical window and act only on the transaction participants, thereby stably triggering consistency defects under extremely small disturbance intensity.

[0097] The transaction preparation completion point is the time when the service initiating the distributed transaction completes its local state persistence and sends a commit signal. The global commit completion point is the time when all participating services in the distributed transaction complete their state commits and return confirmation results. Therefore, between these two points in time, the transaction initiator's local state has been persisted and is irreversible, and at least one participating service has not yet completed its final commit. Injecting disturbances between these two critical points can verify the system's ability to guarantee eventual consistency under extreme timing conflicts.

[0098] Optionally, for any distributed transaction, i.e. the target distributed transaction, two key time points can be obtained by jointly judging the propagation sequence of the transaction representation among multiple services, the real-time arrival time of the conditional request and the confirmation, and the transition events of the service's internal state machine.

[0099] Optionally, in another embodiment of this application, one specific implementation of step S102 is as follows: Figure 3 As shown, it includes:

[0100] S301. For the target distributed transaction in the distributed system, monitor state transition events in real time during the execution of the target distributed transaction.

[0101] Since the two key time points are the time points when specific state transitions occur, in order to accurately obtain the key time points, it is necessary to monitor state transition events during the execution of the target distributed transaction.

[0102] S302. When the initiation service of the target distributed transaction is detected, and the transaction transitions to the exact completion state after completing the local state persistence, the current time point is obtained to obtain the transaction preparation completion time point.

[0103] In this context, the service that initiates a distributed transaction is the starting node service for starting a global transaction. For example, in the order placement process, the "order service" is the first service to receive the request and start the distributed transaction.

[0104] Since the event point obtained is the transaction completion event point, when the service initiating the target distributed transaction transitions to the exact completion state after completing the local state persistence, it means that the service initiating the distributed transaction has completed the local state persistence and issued a commit signal.

[0105] S303. When all participating services of the target distributed transaction have transitioned to the completed state and returned confirmation results, obtain the current time point to get the global commit completion time point.

[0106] Similarly, when it is detected that all participating services of the target distributed transaction have transitioned to the completed state and returned the confirmation result, the current time point obtained is the time point when all participating services have completed the completed state and returned the confirmation result.

[0107] S103. Determine the critical state window of the target distributed transaction based on key time points.

[0108] Since the local state of the transaction initiator has been persisted and is irreversible between the two critical time points, and at least one participating service has not yet completed its final commit, this embodiment injects a perturbation between the two critical time points to verify the system's ability to guarantee eventual consistency under extreme timing conflicts. Therefore, based on the critical time points, a critical window is determined for the state of the target distributed transaction at the two critical time points, i.e., the critical state window of the target distributed transaction, so that precise perturbation injection can be performed within this window. Optionally, the time between the two critical time points can be specifically determined as the critical state window of the target distributed transaction.

[0109] Optionally, in another embodiment of this application, one specific implementation of step S103 includes:

[0110] The critical state window of the target distributed transaction is determined by the time range from the transaction preparation completion time plus the target time offset to the global commit completion time minus the safety boundary time.

[0111] The target time offset is the minimum stable time offset of the filtering system jitter. The safety boundary time is the reserved safety boundary time for system self-healing and rollback.

[0112] In other words, this application also considers system jitter and the safety boundary time reserved for system self-healing and rollback capabilities. Therefore, the target time offset is added to the transaction preparation completion time T1, and the safety boundary time is subtracted from the global commit completion time T2. The time range between the two calculated key time points is then determined as the critical state window of the target distributed transaction, thereby obtaining the millisecond-level transaction proximity state window that dynamically changes with the system's running state. That is, the critical state window of the target distributed transaction is:

[0113] .

[0114] in, The target time offset is the minimum stable time offset used to filter system jitter. This is the safety boundary time, which is the safety boundary time reserved for the self-healing and rollback capabilities of minor issues.

[0115] Optionally, the target time offset and safety boundary time map can be dynamically calculated based on at least one of the following: transaction concurrency depth, historical response latency distribution, and resource load status during transaction execution.

[0116] S104. Based on the business semantic topology, implement asymmetric perturbation injection for some participating services of the target distributed transaction within the critical state window.

[0117] To avoid triggering a global timeout and rollback, and to ensure consistency verification and simulate real-world failure scenarios and control system risks, the participating services of the target distributed transaction within the critical state window are determined based on the business semantic topology. These are the services that participate in the target distributed transaction within the adjacent state window. Then, a portion of these participating services are selected for asymmetric perturbation injection. Optionally, relatively critical participating services can be selected, or they can be selected randomly, or according to other rules.

[0118] Optionally, in another embodiment of this application, one specific implementation of step S104 includes:

[0119] Under the constraint of satisfying consistency verification, based on the business semantic topology, a portion of the participating services in the target distributed transaction within the critical state window are selected according to the set priority to implement asymmetric perturbation injection.

[0120] It should be noted that, in order to enable effective consistency verification through dynamic perturbation injection, corresponding constraints are set to allow perturbation injection to proceed under these constraints. These constraints include the following three: 1. The transaction initiating service has completed its local state commit and cannot be rolled back. 2. At least one transaction participating service has not yet completed its state commit. 3. The global compensation or rollback mechanism has not yet been triggered.

[0121] To prioritize the verification of relatively important nodes, this embodiment selects a subset of participating services from the target distributed transaction within the critical state window for asymmetric perturbation injection according to a set priority order. For example, selection is based on the priority of services at critical path nodes, resource-sensitive nodes, and historically risky nodes. Specifically, critical path nodes are selected from participating services downstream of the "core business logic" or "long transaction chain" in the topology. Resource-sensitive nodes are selected from participating services involved in database row locks, cross-database updates, or high-latency cross-regional calls. Historically risky nodes are selected from nodes in specific domains that have experienced timeouts or inconsistencies in historical drills.

[0122] S105. Real-time collection of operating metrics of distributed systems based on business semantic topology.

[0123] In order to predict and proactively withdraw before the system enters an irreversible and unstable state, thereby avoiding significant risks to the system and efficiently discovering distributed transaction consistency defects while ensuring the system's security boundaries, the system collects operational metrics of the participating services of the target distributed transactions in real time based on the business semantic topology, and predicts the instability risk of the distributed system based on these operational metrics.

[0124] S106. Predict the risk of instability in the distributed system in real time based on current and historical operating indicators.

[0125] The current operational indicators are those collected at the current moment. The historical operational indicators are those collected before the current moment during this exercise.

[0126] Specifically, by analyzing changes in operating indicators in real time based on current and historical operating indicators, and by determining whether these changes are in line with normal conditions, the risk of instability in the distributed system can be predicted.

[0127] If an instability risk is predicted for the distributed system, proceed to step S107. If no instability risk is predicted, the exercise can continue, i.e., maintaining the perturbation until the window ends. This means maintaining the current asymmetric perturbation (such as delay or simulated anomalies) until the transaction reaches the preset exercise duration or logical endpoint. This is to ensure that the perturbation can sufficiently trigger potential consistency defects. Then, after the exercise concludes, proceed to step S108.

[0128] Optionally, in another embodiment of this application, one specific implementation of step S106 is as follows: Figure 4 As shown, it includes:

[0129] S401. Analyze the trend of indicator changes in real time using the current operating indicators and the historical operating indicators within the specified time period closest to the current time to obtain the instability risk assessment indicators of the distributed system.

[0130] Specifically, in this embodiment, current operating indicators and recent historical operating indicators are used to analyze the changes in these indicators and calculate a specified instability risk assessment indicator for the distributed system. This indicator is then used to assess whether instability risk exists. Optionally, multiple instability risk assessment indicators can be used to ensure the accuracy of the risk assessment results.

[0131] S402. Analyze whether the instability risk assessment indicators of the distributed system exceed the corresponding thresholds.

[0132] If all the instability risk assessment indicators of the distributed system exceed the corresponding thresholds, step S403 is executed.

[0133] S403. It is determined that the distributed system has the risk of instability.

[0134] S107, Abort disturbance injection and perform state rollback or configuration recovery.

[0135] Due to the risk of instability at this point, the disturbance injection is immediately terminated to avoid significant and irreversible risks. Simultaneously, state restoration or configuration recovery is performed to control the impact of the exercise. Accordingly, the exercise has now concluded, so step S108 is executed.

[0136] S108. Based on the state change results of the distributed system before and after the exercise, perform consistency verification on the target distributed transaction and obtain the consistency verification result.

[0137] Specifically, after the exercise, based on the state changes of the distributed system before and after the exercise and the expected state changes, the consistency of the target distributed transaction is verified, thereby obtaining the consistency verification result. This may include identifying problems such as transaction hanging, state splitting, or logical deadlock.

[0138] Optionally, in another embodiment of this application, one specific implementation of step S108 is as follows: Figure 5 As shown, it includes:

[0139] S501. Determine the participating services and their target business fields of the target distributed transaction based on the business semantic topology.

[0140] Specifically, based on the business semantic topology, obtain all participating services involved in the target distributed transaction and their corresponding business fields, such as the balance field of service A and the stock field of service B, so as to obtain the key business fields.

[0141] S502. Based on the target business fields of each participating service, obtain the actual final business state of each participating service after the exercise.

[0142] Specifically, after the exercise, the actual final state of each participating service is obtained from the target business fields of each participating service.

[0143] S503. Based on the target business fields of each participating service, determine the initial business state of each participating service before the exercise, and based on the initial business state of each participating service, determine the expected final business state of each participating service.

[0144] Specifically, before the exercise, the initial business state of each participating service can be determined and stored in advance based on the target business fields of each participating service. Subsequently, the initial business state of each participating service before the exercise can be retrieved from the storage based on the target business fields. Under normal circumstances, participating services will theoretically change from a certain initial business state to a certain final business state. Therefore, based on the initial business state of participating services, the expected final business state of each participating service can be obtained.

[0145] S504. By comparing the actual business final state of each participating service with the expected business final state, the consistency verification result of the target distributed transaction is determined.

[0146] This application provides a consistency verification method for a distributed system. It constructs a business semantic topology for the distributed system to facilitate precise perturbation injection and consistency verification. Based on the business semantic topology, it dynamically identifies key time points of the target distributed transaction. These key time points include the transaction preparation completion time and the global commit completion time. Then, it determines the critical state window of the target distributed transaction based on the key time points. Based on the business semantic topology, it performs asymmetric perturbation injection on some participating services within the critical state window. This dynamically determines the millisecond-level critical time window during the distributed transaction state transition through online calculation, strictly confining the perturbation injection behavior within this critical window, acting only on transaction participants. This means implementing asymmetric perturbation within a controllable range, stably triggering consistency defects with minimal perturbation intensity. This allows for accurate analysis of the time interval where impact occurs without causing widespread system anomalies. Finally, it collects real-time operating metrics of the distributed system based on the business semantic topology to predict the potential for instability based on current and historical operating metrics. When a risk of instability is predicted in the distributed system, the disturbance injection is stopped and state rollback or configuration recovery is performed. This extracts the predicted risk and allows for timely cessation and recovery of state or configuration, thus controlling the risk and preventing significant consequences. Finally, based on the state changes of the distributed system before and after the exercise, the consistency of the target distributed transaction is verified, yielding the consistency verification result. This demonstrates a method for accurately verifying the consistency of distributed transactions while ensuring system security boundaries.

[0147] Another embodiment of this application provides a consistency verification device for a distributed system, such as... Figure 6 As shown, it includes:

[0148] Construction unit 601 is used to construct the business semantic topology of the distributed system.

[0149] The time identification unit 602 is used to dynamically identify the key time points of the target distributed transaction in the distributed system based on the business semantic topology. Among them, the key time points include the transaction preparation completion time point and the global commit completion time point.

[0150] The window determination unit 603 is used to determine the critical state window of the target distributed transaction based on key time points.

[0151] The perturbation injection unit 604 is used to perform asymmetric perturbation injection on some participating services of the target distributed transaction within the critical state window based on the business semantic topology.

[0152] The indicator acquisition unit 605 is used to collect operational indicators of the distributed system in real time based on business semantic topology.

[0153] Risk assessment unit 606 is used to predict in real time whether there is a risk of instability in the distributed system based on current and historical operating indicators.

[0154] The termination unit 607 is used to terminate the disturbance injection and perform state rollback or configuration recovery when the risk of instability in the distributed system is predicted.

[0155] Verification unit 608 is used to perform consistency verification on the target distributed transaction based on the state change results of the distributed system before and after the exercise, and obtain the consistency verification result.

[0156] Optionally, in another embodiment of the distributed system consistency verification apparatus provided in this application, the construction unit includes:

[0157] The information acquisition unit is used to collect call information and transaction identification information between various services in the distributed system.

[0158] The parsing unit is used to parse the call information and transaction identification information to obtain the globally unique identifier of each distributed transaction in the distributed system.

[0159] The information determination unit is used to determine the participation relationship, dependency order, and transaction depth of each service in the same distributed transaction based on the globally unique identifier of each distributed transaction.

[0160] The topology building unit is used to construct the business semantic topology of distributed transactions in a distributed system based on the participation relationships, dependency order, and transaction depth of each service in the same distributed transaction.

[0161] Optionally, in another embodiment of the distributed system consistency verification apparatus provided in this application, the time identification unit includes:

[0162] The event monitoring unit is used to monitor state transition events in real time during the execution of a target distributed transaction in a distributed system.

[0163] The first-time acquisition unit is used to obtain the current time point when the initiation service of the target distributed transaction is detected and the transaction transitions to the accurate completion state after completing the local state persistence, thus obtaining the transaction preparation completion time point.

[0164] The second time acquisition unit is used to obtain the current time point when all participating services of the target distributed transaction have transitioned to the completed state and returned the confirmation result, so as to obtain the global commit completion time point.

[0165] Optionally, in another embodiment of the consensus verification apparatus for a distributed system provided in this application, the window determination unit includes:

[0166] The window definition sub-unit is used to determine the critical state window of the target distributed transaction from the transaction preparation completion time plus the target time offset to the global commit completion time minus the safety boundary time. The target time offset is the minimum stable time offset to filter system jitter. The safety boundary time is the reserved safety boundary time for system self-healing and rollback.

[0167] Optionally, in another embodiment of the consensus verification apparatus for a distributed system provided in this application, the disturbance injection unit includes:

[0168] The perturbation injection subunit is used to select a subset of participating services from the target distributed transaction within the critical state window and implement asymmetric perturbation injection based on the business semantic topology and a set priority, under the constraint of satisfying consistency verification. The constraints include that the target distributed transaction has completed its local state commit and cannot be rolled back, at least one participating service has not completed its state commit, and the global compensation or rollback mechanism has not been triggered.

[0169] Optionally, in another embodiment of the distributed system consistency verification apparatus provided in this application, the risk assessment unit includes:

[0170] The indicator calculation unit is used to analyze the trend of indicator changes in real time using the current operating indicators and the historical operating indicators within the most recent specified time period to obtain the instability risk assessment indicators of the distributed system.

[0171] The indicator analysis unit is used to analyze whether the instability risk assessment indicators of the distributed system exceed the corresponding thresholds.

[0172] The result determination unit is used to determine that the distributed system has an instability risk if the instability risk assessment index of the distributed system exceeds the corresponding threshold.

[0173] Optionally, in another embodiment of the distributed system consistency verification apparatus provided in this application, the verification unit includes:

[0174] The field determination unit is used to determine each participating service and its target business fields in the target distributed transaction based on the business semantic topology.

[0175] The first state acquisition unit is used to obtain the actual final state of each participating service after the exercise, based on the target business fields of each participating service.

[0176] The second state acquisition unit is used to determine the initial business state of each participating service before the exercise based on the target business fields of each participating service, and to determine the expected final business state of each participating service based on the initial business state of each participating service.

[0177] The comparison unit is used to determine the consistency verification result of the target distributed transaction by comparing the actual business final state of each participating service with the expected business final state.

[0178] It should be noted that the specific working process of each unit provided in the above embodiments of this application can be referred to the implementation process of the corresponding steps in the above method embodiments, and will not be repeated here.

[0179] Another embodiment of this application provides an electronic device, such as... Figure 7 As shown, it includes:

[0180] Memory 701 and processor 702.

[0181] The memory 701 is used to store the program.

[0182] The processor 702 is used to execute the program stored in the memory 701. When the program is executed, it is specifically used to implement the consistency verification method of the distributed system provided in any of the above embodiments.

[0183] Another embodiment of this application provides a computer storage medium for storing a computer program, which, when executed by a processor, is used to implement the consistency verification method of a distributed system as provided in any of the above embodiments.

[0184] Computer storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0185] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0186] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for consistency verification of a distributed system, characterized in that, include: Construct the business semantic topology of the distributed system; Based on the business semantic topology, the key time points of the target distributed transaction in the distributed system are dynamically identified; wherein, the key time points include the transaction preparation completion time point and the global commit completion time point. The critical state window of the target distributed transaction is determined based on the key time points; Based on the business semantic topology, asymmetric perturbation injection is performed on some participating services of the target distributed transaction within the critical state window; Based on the business semantic topology, the operating metrics of the distributed system are collected in real time. The system can predict in real time whether the distributed system is at risk of instability based on current and historical operating indicators. If the distributed system is predicted to be at risk of instability, the disturbance injection is stopped and a state rollback or configuration recovery is performed. Based on the state change results of the distributed system before and after the exercise, the consistency verification of the target distributed transaction is performed to obtain the consistency verification result.

2. The method according to claim 1, characterized in that, The business semantic topology for constructing the distributed system includes: Collect call information and transaction identification information between various services in the distributed system, and parse the call information and transaction identification information to obtain a globally unique identifier for each distributed transaction in the distributed system; Based on the globally unique identifier of each distributed transaction, determine the participation relationship, dependency order, and transaction depth of each service in the same distributed transaction; Based on the participation relationships, dependency order, and transaction depth of each service in the same distributed transaction, the business semantic topology of the distributed transaction of the distributed system is constructed.

3. The method according to claim 1, characterized in that, The process of dynamically identifying key time points of the target distributed transaction in the distributed system based on the business semantic topology includes: For the target distributed transaction in the distributed system, state transition events are monitored in real time during the execution of the target distributed transaction; When the initiation service of the target distributed transaction is detected, and the transaction transitions to the exact completion state after completing the local state persistence, the current time point is obtained to obtain the transaction preparation completion time point. The global commit completion time is obtained when all participating services of the target distributed transaction have transitioned to the completed state and returned confirmation results.

4. The method according to claim 1, characterized in that, Determining the critical state window of the target distributed transaction based on the key time points includes: The time range from the transaction preparation completion time plus the target time offset to the global commit completion time minus the safety boundary time is determined as the critical state window of the target distributed transaction; wherein, the target time offset is the minimum stable time offset for filtering system jitter; and the safety boundary time is the reserved safety boundary time for system self-healing and rollback.

5. The method according to claim 1, characterized in that, The asymmetric perturbation injection, based on the business semantic topology, for some participating services of the target distributed transaction within the critical state window, includes: Under the constraint of satisfying consistency verification, based on the business semantic topology, a portion of the participating services in the target distributed transaction within the critical state window are selected according to a set priority to implement asymmetric disturbance injection; wherein, the constraint includes that the target distributed transaction has completed local state commit and cannot be rolled back, at least one participating service has not completed state commit, and the global compensation or rollback mechanism has not been triggered.

6. The method according to claim 1, characterized in that, The real-time prediction of whether the distributed system has an instability risk based on current and historical operating indicators includes: By analyzing the trend of indicator changes in real time using current operating indicators and historical operating indicators within the most recent specified time period, the instability risk assessment indicators of the distributed system are obtained. Analyze whether the instability risk assessment index of the distributed system exceeds the corresponding threshold; If the instability risk assessment index of the distributed system exceeds the corresponding threshold, it is determined that the distributed system has an instability risk.

7. The method according to claim 1, characterized in that, Based on the state change results of the distributed system before and after the exercise, the consistency verification of the target distributed transaction is performed to obtain the consistency verification result, including: Based on the business semantic topology, determine each participating service and its target business field of the target distributed transaction; Based on the target business fields of each participating service, obtain the actual final business state of each participating service after the exercise; Based on the target business fields of each participating service, determine the initial business state of each participating service before the exercise, and based on the initial business state of each participating service, determine the expected final business state of each participating service. The consistency verification result of the target distributed transaction is determined by comparing the actual business final state of each participating service with the expected business final state.

8. A consistency verification device for a distributed system, characterized in that, include: Building units are used to construct the business semantic topology of distributed systems; The time recognition unit is used to dynamically identify the key time points of the target distributed transaction in the distributed system based on the business semantic topology; wherein, the key time points include the transaction preparation completion time point and the global commit completion time point; A window determination unit is used to determine the critical state window of the target distributed transaction based on the key time points. The perturbation injection unit is used to perform asymmetric perturbation injection on some participating services of the target distributed transaction within the critical state window based on the business semantic topology. The indicator collection unit is used to collect the operational indicators of the distributed system in real time based on the business semantic topology. The risk assessment unit is used to predict in real time whether the distributed system is at risk of instability based on current and historical operating indicators. The termination unit is used to terminate the disturbance injection and perform state rollback or configuration recovery when it is predicted that there is a risk of instability in the distributed system. The verification unit is used to perform consistency verification on the target distributed transaction based on the state change results of the distributed system before and after the exercise, and obtain the consistency verification result.

9. An electronic device, characterized in that, include: Memory and processor; The memory is used to store programs; The processor is used to execute the program, which, when executed, is specifically used to implement the consistency verification method for a distributed system as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, Used to store a computer program, which, when executed by a processor, is used to implement the consistency verification method for a distributed system as described in any one of claims 1 to 7.

Images