Method and system for ensuring data consistency between service systems based on bidirectional synchronization

Abstract

This application relates to a method and system for ensuring data consistency between business systems based on bidirectional synchronization, belonging to the field of business data processing technology. The method includes: receiving incremental data events from at least two business systems and generating a vector label for each incremental data event; performing conflict detection on concurrently processed incremental data events based on the vector labels and outputting a conflict type identifier; selecting a corresponding synchronization channel based on the conflict type identifier and current system operating status parameters; transmitting the incremental data events to the target business system through the selected synchronization channel and monitoring the execution status, triggering a compensation transaction when execution fails; receiving response information returned by the target business system and updating the inter-system data flow topology based on the response information; detecting the existence of data loops based on the data flow topology, and performing loop blocking operations when a data loop is detected. This application can improve the collaborative efficiency and stability of multiple business systems.

Description

Technical Field

[0001] This application relates to the field of business data processing technology, and in particular to a method and system for ensuring data consistency between business systems based on bidirectional synchronization. Background Technology

[0002] With the development of enterprise IT infrastructure and the continuous decomposition of business systems, traditional monolithic applications are gradually being replaced by distributed systems based on microservices or SOA architectures. Each business module is deployed independently and runs autonomously, forming multiple heterogeneous or even autonomous subsystems. While this architecture improves the scalability and flexibility of the system, it also brings new challenges, especially in ensuring data consistency between different business systems, which has become one of the key issues that urgently need to be addressed.

[0003] In current technological practices, asynchronous communication and data transfer between systems are typically achieved using methods such as message queues and event-driven mechanisms. However, in high-concurrency scenarios, due to factors such as network latency and differences in system response, multiple systems may simultaneously operate on the same business object, leading to data conflicts. For example, in a typical e-commerce system, order services, inventory services, and payment services may concurrently update the status of the same order. Without an effective coordination mechanism, this could result in a series of chain reactions, such as inconsistent order statuses, overselling of inventory, and payment failures. Furthermore, due to issues such as asynchronous local times and clock drift among different systems, traditional methods relying on physical timestamps struggle to accurately determine the order of events, further complicating conflict detection and resolution.

[0004] Furthermore, current mainstream data synchronization mechanisms often focus on master-slave replication or one-way transmission, lacking support for bidirectional or multidirectional synchronization scenarios. This can easily lead to closed-loop data propagation paths in multi-write-point environments. A closed-loop data system refers to data continuously circulating within a ring-shaped structure composed of multiple business systems. This not only wastes resources but can also cause serious consequences such as state oscillations, transaction-level deadlocks, and even system crashes. Summary of the Invention

[0005] To improve the collaborative efficiency and stability of multiple business systems, this application provides a method and system for ensuring data consistency between business systems based on bidirectional synchronization.

[0006] Firstly, this application provides a method for ensuring data consistency between business systems based on bidirectional synchronization, employing the following technical solution:

[0007] A method for ensuring data consistency between business systems based on bidirectional synchronization, the method comprising:

[0008] Receive incremental data events from at least two business systems, and generate a vector label containing multi-dimensional status information for each incremental data event; wherein, the multi-dimensional status information includes at least a logical timestamp and a business status identifier;

[0009] Based on the vector labels, conflict detection is performed on the incremental data events processed concurrently, and a conflict type identifier is output;

[0010] Based on the conflict type identifier and the current system operating status parameters, the corresponding synchronization channel is selected; wherein, the synchronization channel includes a real-time channel and a batch channel;

[0011] The incremental data events are transmitted to the target business system through the selected synchronization channel, and the execution status is monitored. When the execution fails, a compensation transaction is triggered.

[0012] Receive response information returned by the target business system, and update the data flow topology diagram between systems based on the response information;

[0013] Based on the data flow topology graph, detect whether there is a data loop, and when a data loop is detected, perform a loop blocking operation.

[0014] By adopting the above technical solutions, a complete and adaptive data consistency guarantee system has been constructed. This system can not only effectively deal with common problems such as concurrency conflicts, timing disorder, and closed-loop propagation in distributed environments, but also dynamically adjust the data transmission strategy according to the system's operating status, ensuring good data consistency and system stability even in high-concurrency and multi-system collaboration scenarios.

[0015] Optionally, the step of performing conflict detection on incremental data events processed concurrently based on the vector tags and outputting a conflict type identifier includes:

[0016] Acquire at least two concurrently processed incremental data events, each event carrying a vector marker, the vector marker including a logical timestamp field and a business status identifier field;

[0017] Parse the logical timestamp field, verify whether the timing relationship between events conforms to the preset partial order rule, and output the timing conflict determination result;

[0018] Extract the business status identifier field, match it with a predefined state conflict mapping table, and output the state machine conflict determination result;

[0019] The rule engine is invoked to execute the business verification logic associated with the vector tag, and the rule conflict determination result is output.

[0020] By aggregating the timing conflict determination results, state machine conflict determination results, and rule conflict determination results, a conflict type identifier is generated.

[0021] By adopting the above technical solutions, a complete incremental data event conflict detection process was constructed. This process not only has the ability to independently identify conflicts in three dimensions: event timing, status, and business rules, but also outputs a unified conflict type identifier through a priority-driven aggregation mechanism, thereby significantly improving the security, consistency, and intelligence level of concurrent event processing in distributed systems.

[0022] Optionally, the step of selecting the corresponding synchronization channel based on the conflict type identifier and the current system operating status parameters includes:

[0023] The system collects a set of operational status parameters in real time; these parameters include network latency metrics, message queue backlog, and processor load data.

[0024] Based on the predefined conflict level weight mapping relationship, the conflict type identifier is converted into a numerical conflict weight;

[0025] Calculate the dynamic environment coefficient based on the aforementioned set of operating status parameters;

[0026] The route weight value is generated based on the weighted calculation result of the numerical conflict weight and the dynamic environment coefficient;

[0027] The routing weight value is compared with a preset channel decision threshold to obtain the channel identifier of the selected synchronization channel; wherein, when the routing weight value is lower than the weight threshold, the real-time synchronization channel is selected, otherwise the batch transaction channel is selected.

[0028] The output includes routing instructions containing the identifier of the selected channel.

[0029] By adopting the above technical solution, a highly intelligent solution to the problem of synchronous channel selection is achieved. Compared with the traditional method that relies on human experience or fixed rule matching, this technical solution can make reasonable decisions autonomously in complex heterogeneous environments, significantly improving the data consistency guarantee level and resource utilization efficiency of distributed systems when facing diverse concurrent access scenarios.

[0030] Optionally, the step of receiving response information from the target business system and updating the inter-system data flow topology based on the response information includes:

[0031] The response information returned by the target business system is parsed to obtain the source business system identifier, target business system identifier, and data type identifier preset in the response information;

[0032] Based on the source business system identifier and the target business system identifier, query the pre-built system node graph to locate the corresponding source business system node and target business system node;

[0033] A directed data flow edge is established between the source business system node and the target business system node, and the data type identifier is associated and stored as an edge attribute.

[0034] Output the updated inter-system data flow topology diagram.

[0035] By adopting the above technical solution, automated updates to the data flow topology graph between systems are achieved. Its core lies in using structured identifier information to drive the dynamic construction of the graph structure, combining this with a pre-built node graph to improve query efficiency, and enriching the semantic expressive power of the topology graph by introducing edge attributes. The overall solution possesses good scalability and real-time performance, enabling continuous tracking and reflection of the real data flow between systems in complex distributed system environments, thereby providing strong support for system operation and maintenance, fault diagnosis, and data governance.

[0036] Optionally, after updating the inter-system data flow topology graph, the following steps may also be included:

[0037] Analyze the historical transmission frequency and collision rate of each data flow edge in the data flow topology graph;

[0038] Paths with transmission frequencies higher than a first threshold and collision rates lower than a second threshold are identified as hotspot paths.

[0039] Dedicated synchronization channel resources are pre-allocated for the hot path, a cache queue independent of the real-time channel and batch channel is established, and a dedicated thread pool is configured to handle the hot path events;

[0040] When a new incremental data event successfully matches the characteristics of a hotspot path, it is preferentially routed to the dedicated synchronization channel.

[0041] By adopting the above technical solution, the system achieves accurate identification and priority protection of critical data paths. The entire solution starts with in-depth mining of the data flow topology, identifies system bottlenecks and optimization targets through quantitative analysis, and then employs resource decentralization and differentiated service strategies to improve the processing efficiency of critical business processes, ultimately forming a complete data flow optimization management mechanism. This technical solution not only significantly improves the overall performance and response speed of the system but also possesses good scalability and adaptability, dynamically adjusting optimization strategies as business development and data patterns change, providing a scientific and effective solution for data transmission management in complex distributed environments.

[0042] Optionally, the step of detecting whether a data loop exists based on the data flow topology graph, and performing a loop blocking operation when a data loop is detected, includes:

[0043] Obtain the updated data flow topology diagram between systems; the data flow topology diagram includes multiple business system nodes and directed data flow edges between nodes;

[0044] Select any node from the data flow topology graph as the starting point and perform a recursive dependency path search operation.

[0045] When the starting node and ending node coincide in the search path and the path depth is greater than 1, a closed loop existence identifier and a closed loop path structure are generated.

[0046] Based on the attribute data of each edge in the closed-loop path structure, the last active timestamp of each edge in the closed-loop path is extracted, and the time decay coefficient is calculated.

[0047] Calculate the closed-loop hazard level assessment value by analyzing the historical conflict frequency values ​​of all edges on the statistical path.

[0048] Select a blocking strategy that matches the hazard level assessment value, execute the loop blocking operation, and output the blocking execution status code.

[0049] By adopting the above technical solutions, an automated closed-loop detection and blocking framework centered around the data flow topology graph was constructed. Relying on precise graph structure modeling, it effectively captured various feedback loops in a distributed environment. Furthermore, by leveraging multidimensional data analysis, a scientific risk classification mechanism was established. This enabled targeted intervention measures with minimal side effects to be initiated at appropriate times, significantly improving the self-protection capabilities and resilience of large information systems in the face of potential deadlocks, infinite loops, and other malicious failure modes.

[0050] Optionally, after performing the loop blocking operation, the following steps may also be included:

[0051] Collect the vector tag set of synchronized events and the actual data status of the target business system;

[0052] Based on the data flow topology map, locate the data lineage path and trace back to generate the expected data status of the source business system;

[0053] Compare the expected data state with the actual data state. When the difference exceeds the fault tolerance threshold, a cross-system verification transaction is triggered.

[0054] A data correction instruction is sent to the source business system via a reverse channel; the data correction instruction contains patch information for the discrepancies in the data.

[0055] Receive the correction confirmation response from the source service system and update the service status identifier in the vector tag.

[0056] By adopting the above technical solutions, a complete distributed data consistency assurance system was constructed. Through vector-labeled state tracking, data lineage-guided discrepancy analysis, cross-system coordinated verification transactions, and a closed-loop feedback correction mechanism, proactive discovery and automatic repair of data inconsistency issues in complex business scenarios were achieved. This technical solution not only possesses powerful error detection and correction capabilities but also maximizes system performance while ensuring data quality through refined resource control and intelligent decision-making mechanisms, providing scientific and effective technical support for data governance in large-scale distributed environments.

[0057] Secondly, this application provides a data consistency assurance system between business systems based on bidirectional synchronization, employing the following technical solution:

[0058] A data consistency assurance system between business systems based on bidirectional synchronization, characterized in that the system comprises:

[0059] The receiving module is used to receive incremental data events from at least two business systems and generate a vector label containing multi-dimensional status information for each incremental data event; wherein, the multi-dimensional status information includes at least a logical timestamp and a business status identifier;

[0060] The conflict detection module is used to perform conflict detection on concurrently processed incremental data events based on the vector labels and output a conflict type identifier.

[0061] The channel selection module is used to select the corresponding synchronization channel based on the conflict type identifier and the current system operating status parameters; wherein, the synchronization channel includes a real-time channel and a batch channel;

[0062] The transmission monitoring module is used to transmit the incremental data events to the target business system through the selected synchronization channel, monitor the execution status, and trigger a compensation transaction when the execution fails.

[0063] The topology update module is used to receive response information returned by the target business system and update the data flow topology between systems based on the response information.

[0064] The blocking control module is used to detect whether a data loop exists based on the data flow topology graph, and to perform a loop blocking operation when a data loop is detected.

[0065] Thirdly, this application provides a computer device, which adopts the following technical solution:

[0066] A computer device includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform the steps of the method as described in the first aspect.

[0067] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution:

[0068] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect.

[0069] In summary, this application includes at least one of the following beneficial technical effects: by introducing a vector tagging structure based on logical timestamps and business status identifiers, combined with conflict detection, dynamic channel selection, compensation transaction mechanism, and closed-loop detection and blocking strategy of data flow topology graph, while ensuring strong data consistency, it improves the system's ability to identify and handle concurrent conflicts, optimizes the selection strategy of data transmission path and mode, and can proactively prevent and break data closed loops, thereby significantly enhancing the collaborative efficiency and stability between distributed business systems. Attached Figure Description

[0070] Figure 1 This is a first flowchart illustrating a method for ensuring data consistency between business systems based on bidirectional synchronization, according to one embodiment of this application.

[0071] Figure 2 This is a second flowchart illustrating a method for ensuring data consistency between business systems based on bidirectional synchronization, according to one embodiment of this application.

[0072] Figure 3 This is a third flowchart illustrating a method for ensuring data consistency between business systems based on bidirectional synchronization, according to one embodiment of this application.

[0073] Figure 4 This is a schematic diagram of the fourth process of a method for ensuring data consistency between business systems based on bidirectional synchronization, which is one embodiment of this application.

[0074] Figure 5 This is a fifth flowchart illustrating a method for ensuring data consistency between business systems based on bidirectional synchronization, according to one embodiment of this application.

[0075] Figure 6 This is a schematic diagram of the sixth process of a method for ensuring data consistency between business systems based on bidirectional synchronization, which is one embodiment of this application.

[0076] Figure 7 This is a schematic diagram of the seventh process of a method for ensuring data consistency between business systems based on bidirectional synchronization, according to one embodiment of this application. Detailed Implementation

[0077] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figure 1-7The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0078] This application discloses a method for ensuring data consistency between business systems based on bidirectional synchronization.

[0079] Reference Figure 1 A method for ensuring data consistency between business systems based on bidirectional synchronization, the method includes:

[0080] Step S101: Receive incremental data events from at least two business systems, and generate a vector label containing multi-dimensional state information for each incremental data event;

[0081] Among them, multi-dimensional status information includes at least logical timestamps and business status identifiers;

[0082] Specifically, this vector label is not a simple identifier, but a state description structure with structured semantics. Its core components include a logical timestamp and a business state identifier. The logical timestamp is a time-dimensional information used to represent the order of events. Unlike physical time (such as a system clock), it uses a globally monotonically increasing integer form to ensure consistent causal relationship judgment capabilities across systems and nodes.

[0083] For example, if the logical timestamp of event A is less than that of event B, it can be inferred that event A occurred before event B. This design effectively avoids timing misjudgments caused by the asynchronous local times of different systems. Meanwhile, the business status identifier reflects the current state of the business object corresponding to the data event within its lifecycle, typically expressed in an encoded way, such as "pending review," "published," or "deleted." This helps identify whether there are state transition conflicts during the conflict detection phase. Furthermore, to enhance verification capabilities, a hash identifier can be attached to record the summary value of specific business rules for subsequent rule consistency comparisons.

[0084] Step S102: Detect conflicts in the incremental data events processed concurrently based on vector labels and output conflict type identifiers;

[0085] Specifically, the system first determines whether there are timing conflicts by comparing the logical timestamps of each event. That is, if the logical timestamp of one event is earlier than another, but it is actually processed later, it may indicate a violation of a preset partial order relationship, thus triggering a timing conflict flag. Second, the system checks whether the business status flag appears in a predefined status conflict table. This table defines which status combinations are not allowed to appear simultaneously; for example, "deleted" and "published" cannot coexist on the same object. Once such a conflict is detected, a state machine conflict flag is output. Finally, the system can also use a rule engine to verify hash identifiers to determine whether they meet preset business validation logic, such as field format and access control. If the validation fails, a rule conflict flag is generated. These conflict type flags collectively form the basis for subsequent routing decisions.

[0086] Step S103: Select the corresponding synchronization channel according to the conflict type identifier and the current system operating status parameters; wherein, the synchronization channel includes real-time channel and batch channel;

[0087] Specifically, the current system refers to the coordination layer system that implements consistency guarantee methods. Real-time channels are suitable for data transmission scenarios with high timeliness requirements and low conflict levels. They are characterized by low latency and high priority, but consume more resources. Batch channels, on the other hand, are suitable for scenarios that allow for some latency, have large data volumes, or experience severe conflicts. Their advantages lie in high throughput and good fault tolerance. When selecting a channel, the system comprehensively considers factors such as the conflict weighting coefficient (determined by the conflict type identifier), data volume, and network latency to generate a routing weight value, and makes the channel selection accordingly. For example, when the conflict weighting coefficient is low and network conditions are good, the system tends to choose the real-time channel to accelerate data flow; otherwise, it degrades to the batch channel to avoid performance degradation due to frequent conflicts.

[0088] Step S104: Transmit incremental data events to the target business system through the selected synchronization channel and monitor the execution status. Trigger a compensation transaction when execution fails.

[0089] The target business system refers to the business system receiving data in the current synchronous operation. If an anomaly occurs during transmission or processing, such as timeout failure or the target system refusing to receive data, the system will automatically trigger a compensation transaction mechanism to restore data consistency. For example, in the real-time channel, the system establishes a persistent long connection and starts a response timer. If no acknowledgment response is received within the specified time, it automatically switches to the batch channel to retry transmission. In the batch channel, the system implements asynchronous transmission through a transaction message queue, and a listener monitors the queue status in real time. Once an anomaly is detected, a predefined compensation interface is called to perform data rollback or correction operations.

[0090] Step S105: Receive the response information returned by the target business system and update the data flow topology diagram between systems based on the response information;

[0091] The topology graph is essentially a directed graph model, where nodes represent various business systems and edges represent data flow paths. Each response message carries the source system identifier, the target system identifier, and a newly generated vector label for the target system. The system uses this information to add or update the corresponding directed edges in the topology graph. For example, when system A sends a data event to system B, and system B processes it and returns a response, the system adds a new directed edge from A to B in the topology graph, and uses the new vector label returned by B as one of the attributes of this edge for subsequent loop closure detection and consistency maintenance.

[0092] Step S106: Detect whether there is a data loop based on the data flow topology graph, and perform a loop blocking operation when a data loop is detected.

[0093] Data loop refers to the cyclical flow of data between multiple business systems, forming a closed path. This can lead to problems such as infinite propagation, state oscillation, or even system avalanche. To address this, the system traverses and analyzes all nodes and their dependent paths in the topology graph. If a data loop is detected where a data originates from a system, passes through several intermediate nodes, and ultimately returns to itself, it is determined to exist. In this case, the system will execute a loop-breaking operation. Specific measures include pausing the transmission of events along the current data flow path and forcibly downgrading subsequent events on that path to batch processing, thereby breaking the closed loop and preventing infinite data circulation.

[0094] Furthermore, the system dynamically adjusts the route weight calculation strategy based on the updated topology. For example, for paths with a risk of loop closure, the system introduces a transmission delay penalty coefficient into the route weight to reduce the priority of their real-time channels; while for paths without a risk of loop closure, a real-time channel acceleration factor is enabled to improve their transmission efficiency. This dynamic strategy adjustment mechanism allows the entire system to flexibly optimize data flow based on real-time operating status, improving overall collaborative efficiency.

[0095] In the above implementation, a complete and adaptive data consistency guarantee system is constructed. This system can not only effectively deal with common problems in distributed environments such as concurrency conflicts, timing disorder, and closed-loop propagation, but also dynamically adjust the data transmission strategy according to the system's operating status, ensuring good data consistency and system stability in high-concurrency and multi-system collaboration scenarios.

[0096] Reference Figure 2 As one implementation of step S102, the step of performing conflict detection on incremental data events processed concurrently based on vector labels and outputting conflict type identifiers includes:

[0097] Step S201: Obtain at least two concurrently processed incremental data events, each event carrying a vector tag, the vector tag containing a logical timestamp field and a business status identifier field;

[0098] Incremental data events refer to event units generated in distributed systems or database operations by updating, inserting, or deleting existing data. These events often exhibit real-time, local, and concurrent characteristics, making them prone to conflicts due to the uncertainty of the concurrent execution order during processing. Each event carries a "vector tag" as its metadata carrier, which includes a "logical timestamp field" and a "business status identifier field." A vector tag is a data structure used to describe the semantic context and causal relationships of an event. It not only records the relative time information of the event's occurrence (i.e., the logical timestamp) but also contains key attributes of the business status of the event (i.e., the business status identifier).

[0099] Understandably, this dual-field design allows subsequent conflict detection to be analyzed simultaneously in both time and state dimensions, thereby improving the accuracy and completeness of conflict identification.

[0100] Step S202: Parse the logical timestamp field, verify whether the timing relationship between events conforms to the preset partial order rule, and output the timing conflict judgment result;

[0101] The steps for verifying timing relationships include:

[0102] Compare the first logical timestamp of the first event with the second logical timestamp of the second event;

[0103] When the first logical timestamp is greater than the second logical timestamp and the first event arrives later than the second event, a timing conflict flag is triggered.

[0104] It's important to note that logical timestamps differ from physical timestamps. They employ logical clock mechanisms (such as Lamport clocks or vector clocks) to represent the order of events, effectively addressing the unreliability of physical time caused by network latency, node asynchrony, and other factors in distributed systems. By analyzing the logical timestamps of each event, a partial order graph can be constructed. The "partial order rule" refers to a set of temporal constraints set according to business requirements, such as a certain operation must occur after another operation, or two operations that should not have a causal dependency are executed in reverse order.

[0105] For example, during the verification process, if it is found that the logical timestamp of event A is later than that of event B, but the actual receiving order is B before A, it indicates an anomaly that violates the partial order rule, and a "timing conflict flag" will be triggered. This mechanism helps prevent data consistency corruption caused by out-of-order event processing, and is especially suitable for scenarios such as distributed transaction processing and event tracing.

[0106] Step S203: Extract the business status identifier field, match it with the predefined state conflict mapping table, and output the state machine conflict determination result;

[0107] The business status identifier field is used to characterize the state stage of the business object (such as order, user account, inventory, etc.) involved in the current event, such as "pending payment", "shipped", "completed", etc. These states constitute the finite state machine model in the business process, and there may be mutual exclusion, dependency or other constraints between different states.

[0108] To achieve automatic identification of state conflicts, the system pre-builds a "state conflict mapping table," which is essentially a conflict state combination library, storing all state pairs that may cause conflicts (e.g., "cancelled" and "shipped" should not appear simultaneously in different concurrent events of the same order). By extracting the business state identifier field from the event and comparing it with this mapping table, once a state combination of the current concurrent event is found to exist in the conflict library, it is determined to be a "state machine conflict." This method avoids the errors and lags caused by traditional manual rule-based judgments, improving the intelligence level of conflict identification.

[0109] Step S204: Invoke the rule engine to execute the business verification logic associated with the vector tag and output the rule conflict determination result;

[0110] The rule engine is a configurable and extensible business logic processing module that operates based on a series of predefined validation scripts or strategies. In this solution, each event's vector tag contains a "rule index," typically a hash value of the business rule configuration file, used to uniquely identify the corresponding validation logic. The rule engine parses this index to locate the specific validation script and inputs the event's data payload into the script to execute the validation process. The validation script deeply analyzes the key business fields in the event and their interrelationships to determine if there are any violations of preset constraints, such as inconsistent amounts, missing fields, or insufficient permissions. If validation fails, the script returns a conflict flag, which is converted by the system to generate a "rule conflict identifier." This approach decouples business logic from the conflict detection mechanism, improving the system's flexibility and maintainability.

[0111] Step S205: Aggregate the timing conflict determination results, state machine conflict determination results, and rule conflict determination results to generate a conflict type identifier.

[0112] Specifically, the system establishes a "conflict priority mapping relationship," which specifies the order of importance for various types of conflicts: chronological conflicts > state machine conflicts > rule conflicts. This priority setting is based on the assessment results of the impact of conflicts on system stability and data consistency. For example, chronological conflicts may lead to serious consequences such as causal reversal and state rollback; although state machine conflicts are not as direct as chronological conflicts, they may still cause business process disruptions; while rule conflicts are more reflected in issues related to data compliance and integrity.

[0113] Therefore, during the aggregation phase, the system scans each decision result sequentially according to priority. Once a non-empty conflict decision result is detected (i.e., a conflict exists), subsequent scanning is immediately terminated, and that conflict type is taken as the final output. This mechanism ensures the accuracy and efficiency of conflict determination results and avoids the risk of misjudgment caused by multiple conflict stacking.

[0114] In the above implementation, a complete incremental data event conflict detection process was constructed. This process not only has the ability to independently identify conflicts in the three dimensions of event timing, status and business rules, but also outputs a unified conflict type identifier through a priority-driven aggregation mechanism, thereby significantly improving the security, consistency and intelligence of concurrent event processing in the distributed system.

[0115] Reference Figure 3 As one implementation of step S103, the step of selecting the corresponding synchronization channel based on the conflict type identifier and the current system operating status parameters includes:

[0116] Step S301: Collect the current system's operating status parameter set in real time; the parameter set includes network latency indicators, message queue backlog, and processor load data.

[0117] Specifically, network latency reflects the timeliness of communication between nodes and is a crucial factor affecting the speed of distributed transaction processing; message queue backlog reflects task queuing and potential congestion risks; and processor load measures the utilization of core computing resources such as the CPU, directly impacting local task scheduling capabilities. Data acquisition at this stage not only needs high timeliness but should also support periodic sampling or event-triggered update mechanisms to accurately capture transient fluctuations and lay the foundation for subsequent environmental modeling.

[0118] Step S302: Convert the conflict type identifier into a numerical conflict weight according to the predefined conflict level weight mapping relationship;

[0119] The conflict type identifier typically originates from the output of a pre-processor conflict detection module (such as a version conflict identifier or a concurrency control unit). It may be presented as a label, such as "sequence conflict," "state machine conflict," or "rule conflict." To facilitate integration into a unified routing decision model, it must be transformed into numerical weights over a continuous domain. This mapping is not arbitrary but rather a pre-defined hierarchical system based on the severity of the impact of different conflict types on system stability and transaction integrity.

[0120] For example, timing conflicts often occur on non-critical paths and require only low priority processing, thus being assigned the first weight range [0.2, 0.4]. In contrast, rule conflicts involve violations of consistency constraints at the business semantic level, which may lead to irreversible errors if not handled properly, therefore being assigned the highest weight range [0.8, 1.0]. This design enables the system to respond differently based on the inherent attributes of different conflicts, improving strategy flexibility and adaptability.

[0121] Step S303: Calculate the dynamic environment coefficient based on the set of operating status parameters;

[0122] Among them, the dynamic environment coefficient is used to comprehensively characterize the overall situation of the current system's ability to handle external requests and its internal processing pressure.

[0123] The specific implementation includes: First, performing logarithmic scaling on the network latency metric to generate a normalized latency factor. Second, dividing the message queue backlog by its maximum capacity limit to obtain a relative backlog ratio. This method eliminates absolute quantitative biases caused by differences in hardware configuration, making the results more meaningful for horizontal comparison. Third, extracting the sliding window average of processor load data as a load factor helps filter short-term noise interference while retaining long-term trend information. Finally, these three factors are weighted and summed using a set of empirically tuned calibration coefficients α, β, and γ to form an environment score on a unified scale. A higher score indicates a more stressed system, while a lower score indicates a more relaxed system, providing an objective reference for the next step of route weight synthesis.

[0124] Step S304: Generate route weight values ​​based on the weighted calculation results of numerical conflict weights and dynamic environment coefficients;

[0125] A conflict sensitivity coefficient, k, can be introduced as an adjustment factor to balance the importance of the two types of input variables: a larger k value indicates a greater emphasis on the nature of the conflict itself, tending towards conservative responses; conversely, a smaller k value emphasizes adapting to changes in the current operating environment, favoring a flexible scheduling mode. This parameter can also be an adaptive variable, automatically adjusting based on the frequency of historical conflicts to enhance the robustness of the algorithm.

[0126] Specifically, the expression for the route weight value is as follows:

[0127] Route weight value = k × numerical collision weight + ×Dynamic environment coefficient;

[0128] Step S305: Compare the routing weight value with the preset channel decision threshold to obtain the channel identifier of the synchronization channel;

[0129] Specifically, when the routing weight value is lower than the weight threshold, the real-time synchronization channel is selected; otherwise, the batch transaction channel is selected.

[0130] Specifically, if the calculated routing weight is less than the weight threshold, the current scenario is determined to be more suitable for using a low-latency but high-overhead real-time synchronization channel to minimize the probability of transaction failure; otherwise, it switches to a high-efficiency, low-cost batch transaction channel, sacrificing some immediate feedback for higher throughput. This binary classification mechanism seems simple, but in reality, it relies on a lot of preliminary training and experimental verification work to determine the optimal segmentation boundary position.

[0131] Step S306: Output a routing instruction containing the identifier of the selected channel.

[0132] The above implementation provides a highly intelligent solution to the problem of selecting synchronization channels. Compared with the traditional method that relies on human experience or fixed rule matching, this technical solution can make reasonable decisions autonomously in complex heterogeneous environments, significantly improving the data consistency guarantee level and resource utilization efficiency of distributed systems when facing diverse concurrent access scenarios.

[0133] Reference Figure 4 As one implementation of step S105, the step of receiving response information returned by the target business system and updating the inter-system data flow topology diagram based on the response information includes:

[0134] Step S401: Parse the response information returned by the target business system to obtain the source business system identifier, target business system identifier, and data type identifier preset in the response information;

[0135] The response information is the feedback message generated by the target business system after processing a request. In some embodiments, the response information can be data encapsulation in different forms, such as HTTP response, RPC call return value, or message body in a message queue. However, regardless of the protocol format of its carrier, its content must follow a unified data structure specification so that the subsequent parsing module can extract it in a standardized manner.

[0136] In practical applications, this parsing process may involve various techniques such as JSON / XML format parsing, binary protocol decoding, and regular expression matching. Its purpose is to transform the raw communication data into structured data objects that can be directly used by subsequent logic. For example, if the response message is in JSON format, the sourceSystemId, targetSystemId, and dataType fields can be extracted using a predefined schema; if a serialization protocol such as Protobuf is used, deserialization relies on the message structure defined in the .proto file. The parsed identification information has clear semantic meaning: the source business system identifier identifies the data initiator, the target business system identifier identifies the data receiver, and the data type identifier describes the specific content category of this data interaction, such as order data, user information, or payment vouchers. This structured parsing method ensures the accuracy and consistency of the subsequent topology graph construction process.

[0137] Step S402: Query the pre-built system node diagram based on the source business system identifier and the target business system identifier to locate the corresponding source business system node and target business system node;

[0138] The pre-built system node graph refers to a static graph model established before or at the initial stage of method execution, containing all system nodes involved in business interactions and their basic attributes. Each node represents a business system and may carry additional information such as IP address, service name, and cluster affiliation. By comparing the parsed source / target system identifier with the node ID in the node graph, the corresponding node object can be quickly located. This process is typically implemented using hash tables, B-tree indexes, or other efficient search algorithms to ensure high query efficiency even in large-scale system environments.

[0139] Step S403: Establish a directed data flow edge between the source business system node and the target business system node, and store the data type identifier as an edge attribute.

[0140] A directed data flow edge is a directional edge connecting two system nodes, representing the directional flow of data from the source node to the target node. This edge not only carries the connection relationship itself but can also be appended with various attribute information to enhance the information density and analytical capabilities of the topology graph. Among these attributes, the data type identifier is used to identify the type of data interaction represented by the edge.

[0141] For example, if an interaction involves order creation, the edge's dataTypeId might be "ORDER.CREATE"; if it involves user login, it might be "USER.LOGIN". Furthermore, other metadata can be attached to the edge, such as path version number, weight value, and active timestamp, which will play a crucial role in subsequent steps. By binding data type identifiers to edges, the topology graph not only displays the connections between systems but also reveals the flow paths of different data types, facilitating a deeper understanding of the system's data flow characteristics.

[0142] Step S404: Output the updated inter-system data flow topology diagram.

[0143] The output can be an in-memory graph data structure or a persistently stored visual chart or database record. The choice of output format depends on the specific application scenario. For example, in an operations and maintenance monitoring scenario, it may be necessary to render the topology graph in real time as a graphical interface for manual viewing; while in a data analysis scenario, it may be more important for it to exist as a graph database node to support subsequent graph computation tasks. Regardless of the output method used, the essence is to expose the latest topology state after this round of updates, enabling upper-layer applications to perform advanced operations such as anomaly detection, dependency analysis, and capacity planning based on the graph.

[0144] The above implementation achieves automated updates to the data flow topology graph between systems. Its core lies in using structured identifier information to drive the dynamic construction of the graph structure, combining this with a pre-built node graph to improve query efficiency, and enriching the semantic expressive power of the topology graph by introducing edge attributes. The overall solution possesses good scalability and real-time performance, enabling continuous tracking and reflection of the real data flow between systems in complex distributed system environments, thereby providing strong support for system operation and maintenance, fault diagnosis, and data governance.

[0145] Reference Figure 5 As one implementation method for ensuring data consistency between business systems, after updating the data flow topology diagram between systems, the method further includes:

[0146] Step S501: Analyze the historical transmission frequency and collision rate of each data flow edge in the data flow topology diagram;

[0147] Transmission frequency reflects the activity level of a specific data path within a unit of time. Its calculation is typically based on the number of data packet transmissions within a time window. This statistical method effectively identifies high-frequency data interaction patterns in the system. Collision rate, on the other hand, is a crucial indicator for measuring contention, congestion, or failures during data transmission. It is usually calculated by monitoring the number of data packet retransmissions, abnormal fluctuations in transmission delay, and system alarm events.

[0148] Understandably, the joint analysis of these two parameters can construct a comprehensive performance profile of the data path, providing a scientific basis for subsequent path classification. From a technical implementation perspective, this analysis relies on a distributed monitoring system, using data collection via embedded points, log analysis, and a real-time computing engine to process large-scale data, ensuring the accuracy and timeliness of the analysis results.

[0149] Step S502: Identify paths with transmission frequencies higher than the first threshold and collision rates lower than the second threshold as hotspot paths;

[0150] This identification process employs a dual screening mechanism, requiring the path's transmission frequency to exceed a preset first threshold while the collision rate falls below a second threshold. This design logic reflects a dual consideration of path quality and efficiency. A high transmission frequency indicates that the path carries significant business traffic and has high priority processing needs, while a low collision rate indicates that the path possesses good transmission stability and system compatibility, making it suitable for resource optimization. The threshold setting needs to be based on historical data analysis and business demand assessment, typically using statistical methods such as percentile calculation or machine learning algorithms for dynamic adjustment to ensure the scientific rigor and adaptability of the identification results. This identification mechanism can effectively distinguish key data flows in the system, providing precise targets for subsequent resource allocation.

[0151] Step S503: Pre-allocate dedicated synchronization channel resources for hot paths, establish a cache queue independent of the real-time channel and batch channel, and configure a dedicated thread pool to handle hot path events;

[0152] Pre-allocating dedicated synchronization channel resources means the system needs to reserve independent network bandwidth, storage space, and computing resources for these critical paths. This resource isolation mechanism effectively avoids performance degradation caused by resource contention. Establishing a cache queue independent of the real-time and batch channels involves building a dedicated data buffer area. This queue uses a first-in-first-out (FIFO) or priority scheduling algorithm to ensure that hot data is processed promptly without interference from other types of data. The configuration of a dedicated thread pool further improves processing efficiency. By allocating independent processing threads to hot paths, thread switching overhead and resource contention are avoided. The number of threads and scheduling strategies can be optimized based on path characteristics. This dedicated resource configuration embodies the important concept of Quality of Service (QoS) assurance in modern distributed systems, improving the response speed and stability of critical services through resource isolation and dedicated processing.

[0153] Step S504: When a new incremental data event successfully matches the hotspot path characteristics, it is preferentially routed to the dedicated synchronization channel.

[0154] Feature matching typically involves a comprehensive assessment based on multiple dimensions, including data source address, target address, data type, and business tags. Pattern matching algorithms or machine learning models are employed to achieve high-precision classification and recognition. Once a match is successful, the system prioritizes routing the data to a dedicated synchronization channel. This priority routing mechanism reflects the differentiated service concept in traffic engineering.

[0155] Understandably, priority routing can not only shorten the transmission latency of critical data, but also improve overall transmission efficiency through optimized configuration of dedicated channels. This dynamic routing decision needs to be coordinated with the system's load balancing mechanism to ensure that improving the performance of hot paths does not negatively impact other paths, reflecting the technological development trend of intelligent traffic management in modern network architectures.

[0156] The above implementation achieves accurate identification and priority protection of critical data paths in the system. The entire solution starts with in-depth mining of the data flow topology, identifies system bottlenecks and optimization targets through quantitative analysis, and then adopts resource decentralization and differentiated service strategies to improve the processing efficiency of critical business processes, ultimately forming a complete data flow optimization management mechanism. This technical solution not only significantly improves the overall performance and response speed of the system but also possesses good scalability and adaptability, dynamically adjusting optimization strategies as business develops and data patterns change, providing a scientific and effective solution for data transmission management in complex distributed environments.

[0157] Reference Figure 6As one implementation of step S, the step of detecting whether a data loop exists based on the data flow topology graph, and performing a loop blocking operation when a data loop is detected, includes:

[0158] Step S601: Obtain the updated data flow topology diagram between systems; the data flow topology diagram includes multiple business system nodes and directed data flow edges between nodes;

[0159] The data flow topology graph is essentially a directed graph model. Nodes represent different business systems or service modules, while directed edges represent the data transmission directions and dependencies between different nodes. This graphical representation helps to intuitively reflect the data flow process within a complex distributed system. By periodically collecting the latest communication logs, API call records, and other information sources, a new version of the topology graph that accurately reflects the current system dependencies can be reconstructed.

[0160] Step S602: Select any node from the data flow topology graph as the starting point and perform a recursive dependency path search operation;

[0161] This step employs a typical graph traversal algorithm, which is an application of the depth-first search (DFS) strategy. The purpose of choosing any node as the starting point is to fully cover all possible loop formations, because in a complex network environment, any node may be part of some cyclic structure.

[0162] Specifically, the steps for performing a recursive dependency path search operation include: initializing the path stack and pushing the starting node onto it; traversing all outgoing data flow edges of the current node; performing a depth-first search on the target node for each edge; and triggering a loop closure detection flag when the target node is already in the current path stack.

[0163] To effectively track visited paths and determine if they form closed loops, a "path stack" auxiliary structure is introduced to store the node sequence on the current exploration path. Each time a new child node is entered, it is pushed onto the stack. If the target node to be visited is already in the current path stack, it means a complete closed loop path has been formed, triggering the next processing step. This design cleverly utilizes the inherent backtracking capability of DFS, enabling efficient completion of the task of detecting loop structures across the entire map within a limited time.

[0164] Step S603: When the starting node and the ending node coincide in the search path and the path depth is greater than 1, generate a closed loop existence identifier and a closed loop path structure.

[0165] Among them, "the starting node and the ending node coincide" means that the path expands back to the original starting node. "The path depth is greater than 1" is to avoid misjudging self-loop situations such as A→A. Although such simple cases satisfy the literal meaning of "starting point = ending point", they are not usually considered as feedback loop problems that are truly worth being wary of because no other intermediate nodes are involved.

[0166] Understandably, a path is only formally considered a substantial closed loop when it connects at least two nodes before returning to the origin. Based on this, a corresponding marker signal and specific path description information are generated for subsequent use. This process is essentially a variant application of graph theory's search for strongly connected components, ensuring the accurate capture of critical feedback chains that could lead to system oscillations or even avalanche effects.

[0167] Step S604: Based on the attribute data of each edge in the closed-loop path structure, extract the last active timestamp of each edge in the closed-loop path and calculate the time decay coefficient.

[0168] Attribute data refers to metadata fields attached to each data stream edge, such as the timestamp of the most recent successful transmission, average latency, and error rate. Of particular interest is the last active timestamp, which reflects the specific time of the last valid data exchange on this link. Introducing this parameter measures the activity level of the path over a period of time, thus affecting the estimation of its potential threat level. The time decay coefficient is calculated based on the core assumption that the influence of past anomalies gradually weakens over time. Therefore, older historical data can be assigned lower weights using exponential functions or other reasonable mathematical models to more scientifically reflect the true risk situation of the closed loop in the current state.

[0169] Step S605: Calculate the historical conflict frequency values ​​of all edges on the path and the closed-loop hazard level evaluation value.

[0170] The historical conflict frequency value refers to the total number of times that a corresponding data flow edge has caused problems such as timeouts, failures, and duplicate consumption within a certain period. These negative events are often caused by chain reactions resulting from improper data feedback mechanisms. Therefore, the higher the number and density of these events, the more unstable the related path is and the more likely it is to induce a larger-scale spread of problems. By multiplying the conflict frequency of each edge by its own basic weight and then summing the results, and further combining this with the aforementioned time decay factor for weighted calculation, a comprehensive value is finally obtained to characterize the overall risk level of the closed-loop path. This scoring system takes into account both path activity and timeliness factors, enabling managers to make more objective and reasonable decisions based on unified indicators.

[0171] Step S606: Select a blocking strategy that matches the hazard level assessment value, execute the loop blocking operation, and output the blocking execution status code.

[0172] Based on the preset risk classification rules, differentiated response measures are taken for different levels of hazard rating: for example, in the case of mild risk, the channel priority is reduced to avoid excessive interference with normal business operations; in the case of moderate risk, the tag injection method is used to guide some traffic to bypass suspicious areas; and in the case of severe and above risks, the critical links are decisively cut off to completely eliminate the source of the hidden danger.

[0173] It should be noted that after each strategy is implemented, a corresponding execution status code must be fed back so that the monitoring system can track and confirm whether it has actually taken effect. This forms a complete closed-loop management system, which ensures both system stability and necessary flexibility.

[0174] In the above implementation, an automated closed-loop detection and blocking framework based on the data flow topology graph was constructed. Relying on precise graph structure modeling, it effectively captured various feedback loops in the distributed environment. Furthermore, a scientific risk classification mechanism was established with the help of multidimensional data analysis. This enabled targeted intervention measures with minimal side effects to be initiated at appropriate times, significantly improving the self-protection capability and resilience of large information systems when facing potential deadlocks, infinite loops, and other malicious failure modes.

[0175] Reference Figure 7 As a further implementation of the method for ensuring data consistency between business systems, after performing the loop blocking operation, it also includes:

[0176] Step S701: Collect the set of vector tags of synchronized events and the actual data status of the target business system;

[0177] Vector tag sets are a commonly used state identification mechanism in distributed systems. They use multi-dimensional vectors to record data version information of different nodes or business modules, with each dimension corresponding to a specific data source or timestamp, accurately reflecting the evolution of data. This vector clock or version vector technology is a core tool for solving data consistency problems in distributed systems, and its advantage lies in its ability to effectively identify causal relationships and concurrent conflicts.

[0178] Meanwhile, the actual data status acquisition of the target business system involves taking snapshots of various storage media such as database tables, cached data, and file systems. This process requires consideration of data acquisition consistency semantics, and typically employs techniques such as snapshot reading and transaction isolation level control to ensure the integrity and accuracy of the data at the time of acquisition. The combination of these two aspects provides reliable basic data support for subsequent status comparisons.

[0179] Step S702: Locate the data lineage path based on the data flow topology map, and backtrack to generate the expected data status of the source business system;

[0180] Data lineage analysis is a crucial technology in data governance. It constructs a clear data dependency graph by tracing the complete flow of data from source to end. This analysis includes not only explicit data transformations and transmission paths but also implicit dependencies such as triggers and stored procedures. The process of generating the expected data state is essentially a reverse reasoning process; the system follows the known lineage path to deduce the theoretical state value of the source system from the target state. This process requires careful consideration of complex factors such as data transformation rules, mapping relationships, and aggregation logic, and may involve specialized techniques such as reverse parsing of ETL (Extract Transform Load) processes and state restoration from business rule engines.

[0181] Step S703: Compare the difference between the expected data state and the actual data state. When the difference exceeds the fault tolerance threshold, trigger a cross-system verification transaction.

[0182] The difference calculation is a multi-dimensional comparison process, which includes not only direct comparison of numerical values, but also verification of data structure integrity, constraint satisfaction, and business logic correctness. Setting the fault tolerance threshold requires comprehensive consideration of factors such as business tolerance, system performance requirements, and false alarm risk, and typically employs statistical methods or machine learning algorithms to dynamically adjust the threshold parameters.

[0183] For example, when the difference exceeds a preset threshold, the triggered cross-system verification transaction embodies the Saga pattern or TCC (Try-Confirm-Cancel) pattern in distributed transaction management. This transaction mechanism can guarantee the eventual achievement of data consistency across multiple business systems. The execution of the verification transaction requires coordination among multiple participants, employing a two-phase commit or compensation mechanism to ensure the atomicity and consistency of the operation. This requires the system to have a robust transaction coordinator and compensation logic design capability.

[0184] Step S704: Send a data correction instruction to the source business system through the reverse channel; the data correction instruction contains patch information for the difference data.

[0185] The design of the reverse channel needs to consider the security, reliability, and real-time requirements of the communication protocol, and typically employs technologies such as asynchronous message queues, RPC calls, or WebSockets to achieve bidirectional communication. Generating patch information is a delicate data repair process that requires constructing a minimal set of data changes based on the difference analysis results. This ensures that existing problems are completely fixed while avoiding the introduction of new side effects.

[0186] This incremental patching strategy is similar to the differential update mechanism in software engineering, generating the optimal patch solution by calculating the minimum edit distance between two data states. Patch information typically includes metadata such as the specific operation type (add, modify, delete), target data identifier, expected value, and related constraints, ensuring that the source system can accurately understand and execute the patching operation.

[0187] Step S705: Receive the correction confirmation response from the source service system and update the service status identifier in the vector tag.

[0188] This state update mechanism embodies the core principle of state machine replication in distributed systems, ensuring the correct operation of the overall system by maintaining the state consistency of all participating nodes. Updating business state identifiers involves more than just simple tag changes; it also encompasses complex version management and conflict resolution mechanisms. Updating vector tags requires adherence to specific merging rules, such as maximum value selection and causal relationship preservation, to ensure the accuracy and consistency of state information in a concurrent environment.

[0189] At the same time, this update operation will also trigger related monitoring alarms, audit log recording and other functions, providing necessary support information for system operation and maintenance management and problem tracing.

[0190] The above implementation constructs a complete distributed data consistency assurance system. Through vector-labeled state tracking, data lineage-guided discrepancy analysis, cross-system coordinated verification transactions, and a closed-loop feedback correction mechanism, it achieves proactive discovery and automatic repair of data inconsistency issues in complex business scenarios. This technical solution not only possesses powerful error detection and correction capabilities but also maximizes system performance while ensuring data quality through refined resource control and intelligent decision-making mechanisms, providing scientific and effective technical support for data governance in large-scale distributed environments.

[0191] This application also discloses a data consistency guarantee system between business systems based on bidirectional synchronization.

[0192] A data consistency assurance system between business systems based on bidirectional synchronization, the system includes:

[0193] The receiving module is used to receive incremental data events from at least two business systems and generate a vector label containing multi-dimensional status information for each incremental data event; wherein, the multi-dimensional status information includes at least a logical timestamp and a business status identifier;

[0194] The conflict detection module is used to detect conflicts in concurrent incremental data events based on vector labels and output conflict type identifiers.

[0195] The channel selection module is used to select the corresponding synchronization channel based on the conflict type identifier and the current system operating status parameters; the synchronization channels include real-time channels and batch channels.

[0196] The transmission monitoring module is used to transmit incremental data events to the target business system through the selected synchronization channel, monitor the execution status, and trigger compensation transactions when execution fails.

[0197] The topology update module is used to receive response information from the target business system and update the data flow topology between systems based on the response information.

[0198] The blocking control module is used to detect whether there is a data loop based on the data flow topology graph, and to perform a loop blocking operation when a data loop is detected.

[0199] The data consistency assurance system between business systems based on bidirectional synchronization in this application embodiment can implement any of the above-mentioned methods for ensuring data consistency between business systems, and the specific working process of each module in the data consistency assurance system between business systems can refer to the corresponding process in the above-mentioned method embodiments.

[0200] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and in actual implementation there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0201] This application also discloses a computer device.

[0202] Computer equipment includes memory, processor, and computer program stored in memory and executable on the processor. When the processor executes the computer program, it implements the data consistency guarantee method between business systems based on bidirectional synchronization as described above.

[0203] This application also discloses a computer-readable storage medium.

[0204] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as any of the methods described above for ensuring data consistency between business systems based on bidirectional synchronization.

[0205] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0206] It should be noted that the computer device and storage medium in the embodiments of this application are respectively electronic devices and storage media that apply the above-described method for ensuring data consistency between business systems based on bidirectional synchronization. Therefore, all embodiments of the above-described method for ensuring data consistency between business systems are applicable to the computer device and storage medium, and can achieve the same or similar beneficial effects. For the computer device / storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple; relevant details can be found in the descriptions of the method embodiments.

[0207] In this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0208] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce a good effect.

[0209] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for ensuring data consistency between business systems based on bidirectional synchronization, characterized in that, The method includes: Receive incremental data events from at least two business systems, and generate a vector label containing multi-dimensional status information for each incremental data event; wherein, the multi-dimensional status information includes at least a logical timestamp and a business status identifier; Based on the vector labels, conflict detection is performed on the incremental data events processed concurrently, and a conflict type identifier is output; Based on the conflict type identifier and the current system operating status parameters, the corresponding synchronization channel is selected; wherein, the synchronization channel includes a real-time channel and a batch channel; The incremental data events are transmitted to the target business system through the selected synchronization channel, and the execution status is monitored. When the execution fails, a compensation transaction is triggered. Receive response information returned by the target business system, and update the data flow topology diagram between systems based on the response information; Based on the data flow topology graph, detect whether there is a data loop, and when a data loop is detected, perform a loop blocking operation; The steps for selecting the corresponding synchronization channel based on the conflict type identifier and the current system operating status parameters include: The system collects a set of operational status parameters in real time; these parameters include network latency metrics, message queue backlog, and processor load data. Based on the predefined conflict level weight mapping relationship, the conflict type identifier is converted into a numerical conflict weight; Calculate the dynamic environment coefficient based on the aforementioned set of operating status parameters; The route weight value is generated based on the weighted calculation result of the numerical conflict weight and the dynamic environment coefficient; The routing weight value is compared with a preset channel decision threshold to obtain the channel identifier of the selected synchronization channel; wherein, when the routing weight value is lower than the weight threshold, the real-time synchronization channel is selected, otherwise the batch transaction channel is selected. Output routing instructions that include the identifier of the selected channel; The steps of receiving response information from the target business system and updating the inter-system data flow topology diagram based on the response information include: The response information returned by the target business system is parsed to obtain the source business system identifier, target business system identifier, and data type identifier preset in the response information; Based on the source business system identifier and the target business system identifier, query the pre-built system node graph to locate the corresponding source business system node and target business system node; A directed data flow edge is established between the source business system node and the target business system node, and the data type identifier is associated and stored as an edge attribute. Output the updated inter-system data flow topology diagram.

2. The method for ensuring data consistency between business systems based on bidirectional synchronization according to claim 1, characterized in that, The steps of performing conflict detection on incremental data events processed concurrently based on the vector labels and outputting conflict type identifiers include: Acquire at least two concurrently processed incremental data events, each event carrying a vector marker, the vector marker including a logical timestamp field and a business status identifier field; Parse the logical timestamp field, verify whether the timing relationship between events conforms to the preset partial order rule, and output the timing conflict determination result; Extract the business status identifier field, match it with a predefined state conflict mapping table, and output the state machine conflict determination result; The rule engine is invoked to execute the business verification logic associated with the vector tag, and the rule conflict determination result is output. By aggregating the timing conflict determination results, state machine conflict determination results, and rule conflict determination results, a conflict type identifier is generated.

3. The method for ensuring data consistency between business systems based on bidirectional synchronization according to claim 1, characterized in that, Following the step of updating the inter-system data flow topology graph, the following steps are also included: Analyze the historical transmission frequency and collision rate of each data flow edge in the data flow topology graph; Paths with transmission frequencies higher than a first threshold and collision rates lower than a second threshold are identified as hotspot paths. Dedicated synchronization channel resources are pre-allocated for the hot path, a cache queue independent of the real-time channel and batch channel is established, and a dedicated thread pool is configured to handle the hot path events; When a new incremental data event successfully matches the characteristics of a hotspot path, it is preferentially routed to the dedicated synchronization channel.

4. A method for ensuring data consistency between business systems based on bidirectional synchronization according to any one of claims 1 to 3, characterized in that, The steps for detecting the existence of data loops based on the data flow topology graph, and performing loop blocking operations when a data loop is detected, include: Obtain the updated data flow topology diagram between systems; the data flow topology diagram includes multiple business system nodes and directed data flow edges between nodes; Select any node from the data flow topology graph as the starting point and perform a recursive dependency path search operation. When the starting node and ending node coincide in the search path and the path depth is greater than 1, a closed loop existence identifier and a closed loop path structure are generated. Based on the attribute data of each edge in the closed-loop path structure, the last active timestamp of each edge in the closed-loop path is extracted, and the time decay coefficient is calculated. Calculate the closed-loop hazard level assessment value by analyzing the historical conflict frequency values ​​of all edges on the statistical path. Select a blocking strategy that matches the hazard level assessment value, execute the loop blocking operation, and output the blocking execution status code.

5. The method for ensuring data consistency between business systems based on bidirectional synchronization according to claim 4, characterized in that, Following the loop blocking operation, the procedure also includes: Collect the vector tag set of synchronized events and the actual data status of the target business system; Based on the data flow topology map, locate the data lineage path and trace back to generate the expected data status of the source business system; Compare the expected data state with the actual data state. When the difference exceeds the fault tolerance threshold, a cross-system verification transaction is triggered. A data correction instruction is sent to the source business system via a reverse channel; the data correction instruction contains patch information for the discrepancies in the data. Receive the correction confirmation response from the source service system and update the service status identifier in the vector tag.

6. A data consistency guarantee system for inter-system business based on bidirectional synchronization, used to execute the data consistency guarantee method for inter-system business based on bidirectional synchronization as described in any one of claims 1 to 5, characterized in that, The system includes: The receiving module is used to receive incremental data events from at least two business systems and generate a vector label containing multi-dimensional status information for each incremental data event; wherein, the multi-dimensional status information includes at least a logical timestamp and a business status identifier; The conflict detection module is used to perform conflict detection on concurrently processed incremental data events based on the vector labels and output a conflict type identifier. The channel selection module is used to select the corresponding synchronization channel based on the conflict type identifier and the current system operating status parameters; wherein, the synchronization channel includes a real-time channel and a batch channel; The transmission monitoring module is used to transmit the incremental data events to the target business system through the selected synchronization channel, monitor the execution status, and trigger a compensation transaction when the execution fails. The topology update module is used to receive response information returned by the target business system and update the data flow topology between systems based on the response information. The blocking control module is used to detect whether a data loop exists based on the data flow topology graph, and to perform a loop blocking operation when a data loop is detected.

7. A computer device, characterized in that: The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 5.

Images