Cross-system data maintenance method, apparatus, device, and storage medium

Abstract

The application discloses a cross-system data maintenance method and device, equipment and a storage medium, relates to the technical field of data synchronization, and comprises the following steps: acquiring an asset operation request across systems; performing business semantic analysis on the asset operation request to obtain target business system data, wherein the target business system data is a minimum system set to be involved in a transaction; performing three-phase commitment based on the target business system data, and recording business execution data and performance data in the business process of different systems after commitment, wherein the three-phase commitment comprises a preparation inquiry phase, a pre-commitment phase and a formal commitment phase; when detecting that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy, so that the consistency of data is guaranteed, and the system reliability is improved.

Description

Technical Field

[0001] This application relates to the technical field of data synchronization, and in particular to a cross-system data maintenance method, apparatus, device and storage medium. Background Technology

[0002] In modern enterprise operations, multiple business systems are typically deployed to efficiently manage various assets and business processes, such as fixed asset management systems, financial systems, procurement systems, and office automation systems. These systems require collaborative operation and maintenance around enterprise asset-related data during operation. However, during data interaction, numerous uncertainties, such as inter-system communication delays, system failures, and network interruptions, can easily lead to data inconsistencies. Specifically, on the one hand, each system maintains asset data independently, causing discrepancies in information about the same asset across different systems, creating data silos. On the other hand, unexpected interruptions in the data synchronization process between systems can result in the loss of some update operations. Furthermore, simultaneous modifications to the same asset data by multiple systems can also cause data conflicts. In addition, when cross-system operations fail, it is difficult to consistently roll back all system data to the state before the operation; the recovery process after a system crash is also extremely complex, making it difficult to ensure data consistency between systems.

[0003] Currently, the main technical solutions for solving cross-system data consistency problems have certain limitations: the two-phase commit protocol has the risk of single point of failure of the coordinator, and the failure of participants may lead to long-term blocking; the three-phase commit protocol may still lead to data inconsistency in the case of network partitioning; message queues face problems such as message processing order and duplicate message processing, which make it difficult to meet the strict requirements of enterprise asset management for real-time consistency.

[0004] Therefore, ensuring data consistency across systems is a problem that urgently needs to be solved. Summary of the Invention

[0005] The main purpose of this application is to provide a cross-system data maintenance method, apparatus, device and storage medium, which aims to solve the technical problem of how to ensure cross-system data consistency.

[0006] To achieve the above objectives, this application proposes a cross-system data maintenance method, the method comprising:

[0007] Obtain cross-system asset operation requests;

[0008] Business semantic analysis is performed on the asset operation request to obtain target business system data, which is the minimum set of systems to be involved in the transaction;

[0009] perform a three-phase commit based on the target business system data, and record business execution data and performance data in business process execution of different systems after commit, the three-phase commit including a prepare inquiry phase, a pre-commit phase, and a formal commit phase;

[0010] When detecting that the business execution data in any two systems are different, determine a corresponding repair strategy according to the performance data, and repair the business execution data according to the repair strategy.

[0011] In an embodiment, the step of performing business semantic analysis on the asset operation request to obtain target business system data includes:

[0012] Performing business semantic analysis on the asset operation request to obtain a business type and a business influence range;

[0013] Constructing a system dependency graph according to the business type and the business influence range;

[0014] Performing system node pruning based on the system dependency graph to obtain target business system data.

[0015] In an embodiment, before the step of performing a three-phase commit based on the target business system data, and recording business execution data and performance data in business process execution of different systems after commit, the method further includes:

[0016] Obtaining a transaction coordinator state, the transaction coordinator including a primary coordinator and a shadow coordinator;

[0017] Synchronizing states of the primary coordinator and the shadow coordinator according to a preset coordinator state synchronization mechanism, and when the state of the primary coordinator is a failure state, selecting a target primary coordinator from the shadow coordinator to replace the primary coordinator for transaction coordination according to a preset consensus algorithm.

[0018] In an embodiment, the step of performing a three-phase commit based on the target business system data, and recording business execution data and performance data in business process execution of different systems after commit includes:

[0019] Obtaining a target execution system and a target execution operation set according to the target business system data;

[0020] Sending commit requests in sequence to the target execution system according to an order of the prepare inquiry phase, the pre-commit phase, and the formal commit phase, and obtaining feedback states of the target execution system based on the commit requests in sequence, the commit requests including a prepare inquiry request, a pre-commit request, and a formal commit request;

[0021] When the feedback states are all success states, performing a service according to the target execution operation set, and recording service execution data and performance data of the target execution system during service execution.

[0022] In an embodiment, the step of obtaining the target execution system and the target execution operation set according to the target service system data comprises:

[0023] obtaining the target execution system and the target execution service according to the target service system data;

[0024] decomposing and transforming the target execution service according to preset service priority rules and preset service rules to obtain target execution service priority and target execution service constraint conditions;

[0025] obtaining the target execution operation set according to the target execution service priority and the target execution service constraint conditions.

[0026] In an embodiment, the step of, when detecting that the service execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the service execution data according to the repair strategy comprises:

[0027] when detecting that the service execution data in any two systems are different, obtaining a fault type of a fault system according to the performance data, the fault type comprising a first fault type and a second fault type;

[0028] matching a corresponding repair strategy from a recovery strategy library according to the fault type, the repair strategy comprising a first repair strategy corresponding to the first fault type and a second repair strategy corresponding to the second fault type;

[0029] when the repair strategy is the first repair strategy, performing data retransmission on the service execution data;

[0030] when the repair strategy is the second repair strategy, performing data rollback on the fault system according to a preset rollback strategy, and performing data retransmission on the service execution data after the rollback is completed.

[0031] In an embodiment, after the step of, when detecting that the service execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the service execution data according to the repair strategy, the method further comprises:

[0032] comparing the performance data with a preset performance threshold to obtain a performance bottleneck target;

[0033] When the performance bottleneck target is network delay, a timeout threshold and a retry time interval in a three-phase commit process are adjusted according to a preset optimization strategy to improve network connection status.

[0034] When the performance bottleneck target is coordinator load, a number of shadow coordinators is adjusted according to a preset optimization strategy.

[0035] In addition, to achieve the above object, the present application also provides a cross-system data maintenance device, which comprises:

[0036] A data acquisition module is configured to acquire asset operation requests across systems.

[0037] An operation analysis module is configured to perform business semantic analysis on the asset operation requests to obtain target business system data, the target business system data being a minimum system set to be involved in a transaction.

[0038] A business execution module is configured to execute a three-phase commit based on the target business system data and record business execution data and performance data in a business execution process of different systems after the commit, the three-phase commit including a preparation inquiry phase, a pre-commit phase and a formal commit phase.

[0039] A data repair module is configured to determine a corresponding repair strategy according to the performance data when detecting that the business execution data in any two systems are different, and repair the business execution data according to the repair strategy.

[0040] In addition, to achieve the above object, the present application also provides a cross-system data maintenance device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the cross-system data maintenance method as described above.

[0041] In addition, to achieve the above object, the present application also provides a storage medium, which is a computer readable storage medium, the storage medium storing a computer program, the computer program being executable on a processor to implement the steps of the cross-system data maintenance method as described above.

[0042] In addition, to achieve the above object, the present application also provides a computer program product, which comprises a computer program, the computer program being executable on a processor to implement the steps of the cross-system data maintenance method as described above.

[0043] The application provides a cross-system data maintenance method, which comprises the following steps: acquiring an asset operation request across systems; performing business semantic analysis on the asset operation request to obtain target business system data, wherein the target business system data is a minimum system set to be involved in a transaction; performing a three-phase commit based on the target business system data, and recording business execution data and performance data in the process of executing a business by different systems after the commit, wherein the three-phase commit comprises a preparation inquiry phase, a pre-commit phase and a formal commit phase; when it is detected that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy. As can be seen, the application realizes consistency guarantee of data between different systems by optimizing a three-phase commit protocol, combining business semantic perception and an adaptive fault recovery mechanism, and improves system reliability. BRIEF DESCRIPTION OF DRAWINGS

[0044] The drawings incorporated into the specification and forming a part of the specification, show embodiments consistent with the application, and together with the specification serve to explain the principles of the application.

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0046] Figure 1 A flowchart provided for a first embodiment of the cross-system data maintenance method of the application;

[0047] Figure 2 A flowchart provided for a second embodiment of the cross-system data maintenance method of the application;

[0048] Figure 3 A flowchart provided for a third embodiment of the cross-system data maintenance method of the application;

[0049] Figure 4 A module structure diagram of the cross-system data maintenance device of the embodiment of the application;

[0050] Figure 5 A device structure diagram of a hardware running environment involved in the cross-system data maintenance method in the embodiment of the application.

[0051] The object implementation, functional features and advantages of the application will be further described with reference to the embodiments and the drawings. DETAILED DESCRIPTION

[0052] It should be understood that the specific embodiments described herein are merely intended to explain the technical solutions of the present application, and are not intended to limit the present application.

[0053] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings of the specification and specific embodiments.

[0054] The main solution of the embodiments of the present application is: obtaining a cross-system asset operation request; performing business semantic analysis on the asset operation request to obtain target business system data, the target business system data being a minimum system set to be involved in a transaction; performing a three-phase commit based on the target business system data, and recording business execution data and performance data in the business process of different systems after the commit, the three-phase commit including a preparation inquiry phase, a pre-commit phase and a formal commit phase; when detecting that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy.

[0055] In the modern enterprise operation environment, in order to efficiently manage various assets and business processes, multiple business systems such as fixed asset management systems, financial systems, procurement systems and office automation systems need to be deployed. These systems need to coordinate operation and maintenance around enterprise asset related data during operation. However, in the data interaction link, affected by many uncertain factors such as system communication delay, system failure, network interruption, etc., data inconsistency problems are easily caused. Specifically, on the one hand, each system independently maintains asset data, which causes the information of the same asset in different systems to deviate, forming a data island; on the other hand, if the data synchronization process between systems is interrupted accidentally, part of the update operation will be lost. At the same time, when multiple systems modify the same asset data at the same time, data conflicts will also occur. In addition, when cross-system operation fails, it is difficult to roll back all system data to the state before the operation; the recovery process after system downtime is also very complex, and it is difficult to ensure the data consistency between systems.

[0056] Currently, the main technical solutions to solve the cross-system data consistency problem have certain limitations: the two-phase commit protocol has the risk of coordinator single point failure, and the participant failure may cause long time blocking; the three-phase commit protocol may still cause data inconsistency in the case of network partition; the message queue faces the problems of message processing order and repeated message processing, and it is difficult to meet the strict requirements of enterprise asset management on real-time consistency. Therefore, how to ensure the consistency of cross-system data is a problem that needs to be solved at present.

[0057] The present application optimizes the three-phase commit protocol, combines business semantic perception and adaptive fault recovery mechanism, realizes the consistency guarantee of data between different systems, and improves the system reliability.

[0058] It should be noted that the execution subject of the embodiment can be a cross-system data maintenance system, or a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, or an electronic device capable of realizing the cross-system data maintenance function, and the embodiment is not specifically limited thereto. The following will take the cross-system data maintenance system as an example to describe the embodiment and the following embodiments.

[0059] Based on this, the embodiment of the application provides a cross-system data maintenance method, which refers to Figure 1 , Figure 1 The flowchart of the first embodiment of the cross-system data maintenance method of the application is shown in FIG. 1.

[0060] In the embodiment, the cross-system data maintenance method comprises steps S10-S40:

[0061] Step S10: Obtain an asset operation request across systems.

[0062] It should be noted that obtaining an asset operation request across systems means receiving an operation instruction for asset data from a business system such as a fixed asset management platform, a financial system, a procurement system or an office automation system of an enterprise. These operation requests can include operations such as adding, deleting, modifying or querying assets.

[0063] Step S20: Perform business semantic analysis on the asset operation request to obtain target business system data, wherein the target business system data is a minimum system set to be involved in a transaction.

[0064] It should be noted that in this step, the system performs business semantic analysis on the asset operation request, that is, by analyzing the business meaning and influence range in the operation request, it determines which business systems the operation needs to involve. The specific process includes: using a business semantic analysis unit in the system to analyze the operation request, constructing a dependency relationship graph between the system and the operation, and determining a minimum system set to be involved in a transaction, i.e., target business system data.

[0065] It can be understood that the purpose of this step is to accurately define the transaction boundary, avoid unnecessary system participation, and improve processing efficiency.

[0066] In one possible implementation, the step S20 specifically comprises:

[0067] Step S201: Perform business semantic analysis on the asset operation request to obtain a business type and a business influence range.

[0068] It should be noted that in this step, the system will analyze the received asset operation request in depth through the business semantic analysis unit to identify the business type and business impact range corresponding to the request. The specific process includes: analyzing the instruction type (such as adding, deleting, modifying, querying, etc.) in the operation request, and combining asset type, operation object and other key information to determine the business type (such as asset procurement, asset allocation, asset depreciation, etc.) to which the request belongs; at the same time, analyze the impact range of the operation on enterprise asset data, including which systems and which data items are involved. For example, the system receives an operation request for asset allocation, which requires a device to be allocated from department A to department B. Through business semantic analysis, the system identifies that the business type of the request is "asset allocation", and the business impact range involves fixed asset management system (records device information), financial system (updates asset accounts), etc.

[0069] Step S202: Constructing a system dependency graph according to the business type and the business impact range.

[0070] It should be noted that in this step, the system will dynamically construct a system dependency graph according to the business type and the business impact range. The specific process includes: determining the system type (such as fixed asset management system, financial system, etc.) that may be involved according to the business type, and analyzing the data interaction relationship and dependency relationship between systems in combination with the business impact range; then, these relationships are displayed in a graphical manner to form a system dependency graph. It can be understood that the system dependency graph is a topological structure that describes the data dependency relationship between systems in business operations, including nodes (subsystems participating in business operations), edges (data transmission paths) and dependency attributes (strong dependency or weak dependency). Strong dependency refers to directly related (i.e. data interaction) systems, and weak dependency refers to indirectly related systems.

[0071] Step S203: System node pruning based on the system dependency graph to obtain target business system data.

[0072] It should be noted that in this step, the system will prune according to the dependency relationship, remove the connection nodes that are weakly dependent (i.e. indirectly related) to the target business, and combine homogenized systems (such as regional financial systems can be combined into a single logical node) to obtain the minimum system set necessary for completing the target business. It can be understood that the role of this step is to reduce unnecessary system participation and performance overhead, optimize transaction processing flow, and improve system reliability.

[0073] Step S30: Based on the target business system data, execute a three-phase commit, and record the business execution data and performance data during the execution of the business process by different systems after the commit, the three-phase commit includes a preparation inquiry phase, a pre-commit phase and a formal commit phase.

[0074] It should be noted that the three-phase commit based on the target business system data refers to initiating the three-phase commit protocol through the transaction coordinator within the system, and sequentially passing through the preparation inquiry phase (CanCommit), the pre-commit phase (PreCommit) and the formal commit phase (DoCommit). In each phase, the business execution data (such as operation results, state changes, etc.) and performance data (such as response time, processing speed, etc.) during the execution of the business process by different systems are recorded. In addition, it should be noted that the three-phase commit refers to a cross-system transaction processing protocol, including the preparation inquiry phase, the pre-commit phase and the formal commit phase, for ensuring the consistency and reliability of cross-system data; the business execution data refers to the operation results, state changes, etc. data generated by the system during the execution of the business process; the performance data refers to the response time, processing speed, etc. indicators of the system when processing the business.

[0075] It can be understood that the role of this step is to ensure the consistency and reliability of cross-system transactions.

[0076] In a feasible implementation, before the step S30, it further includes:

[0077] Step A10: Obtain the transaction coordinator state, including the master coordinator and the shadow coordinator.

[0078] It should be noted that the transaction coordinator state refers to the current working state of the transaction coordinator (including the master coordinator and the shadow coordinator), such as active, failure, initialization, etc. In this step, the system will periodically check the state of the master coordinator and the shadow coordinator through the heartbeat monitoring unit in the transaction coordinator, to ensure that the transaction coordinator is in normal working state. The specific process includes: the master coordinator periodically sends a heartbeat signal to the shadow coordinator, indicating that itself is in an active state; at the same time, the shadow coordinator also monitors the heartbeat signal of the master coordinator, and considers that the master coordinator has failed when it is not received within a timeout. In addition, the system also ensures the consistency of state information between the master coordinator and the shadow coordinator through the coordinator state synchronization mechanism.

[0079] In addition, it should be noted that the master coordinator is the center of transaction processing, responsible for initiating, coordinating and committing transactions; while the shadow coordinator acts as a backup for the master coordinator, synchronizing the state of the master coordinator in real time, and taking over its work when the master coordinator fails, to ensure the continuity and high availability of transaction processing.

[0080] Step A20: Synchronize the state of the master coordinator and the shadow coordinator according to the preset coordinator state synchronization mechanism, and when the state of the master coordinator is a failure state, select a target master coordinator from the shadow coordinator according to the preset consensus algorithm to replace the master coordinator for transaction coordination.

[0081] It should be noted that in this step, the system will use the preset coordinator state synchronization mechanism to ensure the consistency of state information between the primary coordinator and the shadow coordinator, so as to seamlessly switch to the shadow coordinator to continue transaction processing when the primary coordinator fails. The specific process includes: the primary coordinator sends state information to the shadow coordinator through the state synchronization mechanism when the state changes (such as starting a transaction, committing a transaction, etc.); the shadow coordinator receives and updates its own state to maintain consistency with the primary coordinator. When the primary coordinator fails, the system will select one from the shadow coordinators as the new primary coordinator according to the preset consensus algorithm (such as Raft algorithm), and take over the transaction processing work.

[0082] It can be understood that the role of this step is to improve the reliability of the system during transaction processing, and to ensure that the transaction processing capability can be quickly restored when the primary coordinator fails.

[0083] Step S40: When detecting that the business execution data in any two systems is different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy.

[0084] It should be noted that the repair strategy refers to the specific measures and methods for solving the problem of data inconsistency matched from the recovery strategy library according to the performance data. Specifically, in this step, when the system detects that the business execution data in any two systems is different, it will trigger the fault recovery mechanism. The specific process includes: using the fault detection unit of the system to identify the inconsistency, classifying the fault into different fault types through the fault classification unit, then matching the corresponding repair strategy from the recovery strategy library according to the fault type, and adjusting the execution mode and priority of the repair strategy according to the performance data (such as system load, response time, etc.). Finally, the repair strategy is executed through the automatic recovery executor or manual intervention interface of the system to repair the business execution data.

[0085] The embodiment provides a cross-system data maintenance method, and the method of the embodiment comprises the following steps: acquiring an asset operation request across systems; performing business semantic analysis on the asset operation request to obtain target business system data, the target business system data being a minimum system set to be involved in a transaction; performing a three-phase commit based on the target business system data, and recording business execution data and performance data in a business process executed by different systems after the commit, the three-phase commit comprising a preparation inquiry phase, a pre-commit phase and a formal commit phase; when detecting that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy. As can be known from the above, the embodiment realizes consistency guarantee of data between different systems by optimizing a three-phase commit protocol, combining business semantic perception and an adaptive fault recovery mechanism, and improves system reliability.

[0086] Based on the first embodiment of the application, the same or similar contents in the second embodiment of the application as the above-mentioned first embodiment can be referred to the above description, and the subsequent description will not be repeated. On this basis, please refer to Figure 2 , Figure 2 The flowchart of the second embodiment of the cross-system data maintenance method of the application is shown in FIG. 10, and the step S30 specifically comprises the following steps.

[0087] Step S301: obtaining target execution systems and a target execution operation set according to the target business system data.

[0088] It should be noted that in this step, the system further analyzes the target business system data to obtain specific target execution systems and a target execution operation set. The specific process comprises the following steps: analyzing the target business system data, identifying specific operations (such as updating, deleting, inserting, etc.) that need to be executed by each system, and grouping these operations according to systems to form target execution systems and their corresponding target execution operation set. In addition, it should be noted that the target execution system refers to a specific business system that needs to participate in transaction processing according to business requirements and system dependency relationships in cross-system transaction processing. The target execution operation set refers to a specific operation set that needs to be executed by each target execution system.

[0089] In a feasible implementation, the step S301 specifically comprises the following steps.

[0090] Step C10: obtaining target execution systems and target execution business according to the target business system data.

[0091] It should be noted that in this step, the system will analyze the input target business system data through the business semantic analysis unit and the system dependency graph generation unit in the intelligent transaction boundary delineation module. First, the business semantic analysis unit analyzes the specific business meaning and impact range of the asset operation request, and identifies the involved business processes and key data elements. Then, the system dependency graph generation unit dynamically constructs the system dependency graph involved in the operation according to the analysis result, and determines which systems need to participate in the transaction processing, thereby determining the target execution system. At the same time, combined with the results of business semantic analysis, the specific business that each target execution system needs to handle, i.e., the target execution business, is determined. For example, in a transaction scenario involving fixed asset procurement, the target business system data may include data of multiple links such as procurement application, approval, payment, and asset warehousing. Through the business semantic analysis unit, the system identifies that the procurement application needs to be processed by the procurement system, the approval process involves the office automation system, the payment needs to be processed by the financial system, and the asset warehousing needs to be processed by the fixed asset management system. The system dependency graph generation unit further constructs the dependency relationship between these systems, and determines them as target execution systems. At the same time, the specific business that each system needs to execute, i.e., the target execution business, is determined, such as the procurement system processing procurement order generation, the financial system processing payment operation, etc.

[0092] Step C20: decomposing and transforming the target execution business according to the preset business priority rules and the preset business rules to obtain a target execution business priority and a target execution business constraint condition.

[0093] It should be noted that in this step, the system will utilize the business priority matrix and the business rule parser in the asset business semantic perception layer to further process the target execution business. The business priority matrix defines the priority rules in different business scenarios, and assigns a priority to each target execution business according to the urgency, importance, etc. of the business. The business rule parser converts the business rules into transaction constraint conditions, and determines the conditions and restrictions that need to be met during business execution.

[0094] It can be understood that the target execution business priority refers to the relative importance level assigned to each target execution business according to the business priority matrix, which is used to guide the resource allocation and execution order in the transaction processing process. The target execution business constraint condition refers to the conditions and restrictions that must be met during business execution, such as time limit, data consistency requirement, etc.

[0095] Step C30: obtaining a target execution operation set according to the target execution business priority and the target execution business constraint condition.

[0096] It should be noted that in this step, the system will further construct the target execution operation set according to the target execution business priority and the target execution business constraint condition. The specific process includes: determining the execution order of the operation according to the target execution business priority; at the same time, considering the target execution business constraint condition, each target execution business is decomposed into a series of specific and executable operations, and the operations and the execution order of the operations together constitute the target execution operation set.

[0097] Step S302: sequentially sending a submission request to the target execution system according to the order of the preparation inquiry stage, the pre-commitment stage and the formal commitment stage, and sequentially obtaining the feedback state of the target execution system based on the submission request, the submission request including a preparation inquiry request, a pre-commitment request and a formal commitment request.

[0098] It should be noted that in this step, the system will pass through the three-phase commit execution engine, sequentially send the corresponding submission request to the target execution system according to the order of the preparation inquiry stage, the pre-commitment stage and the formal commitment stage, and collect the feedback state of each system. The specific process includes: in the preparation inquiry stage, sending a preparation inquiry request to all target execution systems to inquire whether each system can execute the scheduled operation; after receiving the positive feedback of all systems, entering the pre-commitment stage, sending a pre-commitment request to each system to require each system to execute the scheduled operation but not to commit; finally, after confirming that all systems have successfully executed the scheduled operation, entering the formal commitment stage, sending a formal commitment request to each system to require each system to complete the transaction commitment. At the same time, the system will record the feedback state of each system in each stage for subsequent processing and judgment. It can be understood that the role of this step is to ensure the orderliness and controllability of transaction processing, and to avoid data inconsistency caused by system failure or operation failure.

[0099] Step S303: when the feedback state is a successful state, executing the business according to the target execution operation set and recording the business execution data and performance data in the process of executing the business by the target execution system.

[0100] It should be noted that after confirming that the feedback state of all target execution systems to the formal commitment request is a successful state, the business is executed according to the target execution operation set, and the business execution data and performance data in the process of executing the business are recorded. The specific process includes: executing the business operation in each target execution system according to the operation order and operation steps in the target execution operation set; at the same time, recording the execution time, result, resource consumption and other business execution data and performance data of each operation through the transaction execution statistical unit and the performance monitoring tool. It can be understood that the role of this step is to ensure the integrity and traceability of transaction processing, and to provide basis for subsequent data consistency verification and performance optimization.

[0101] In the embodiment, by converting business semantics into a set of executable operations, coordinating multi-system transaction states based on an improved three-phase commit protocol, and monitoring the execution process in real time, business-driven transaction scheduling and consistency guarantee are realized, the problems of large performance overhead and difficult fault recovery caused by lack of business awareness in traditional solutions are solved, and the cross-system collaboration efficiency and data reliability are improved.

[0102] Based on the first and second embodiments of the present application, in the third embodiment of the present application, the same or similar contents as the above embodiments one and two can be referred to the above introduction, and will not be repeated hereinafter. On this basis, please refer to Figure 3 , Figure 3 is a flowchart of the third embodiment of the cross-system data maintenance method of the present application, and the step S40 specifically comprises:

[0103] Step S401: When it is detected that the business execution data in any two systems are different, the fault type of the fault system is obtained according to the performance data, and the fault type includes a first fault type and a second fault type.

[0104] It should be noted that when the consistency verification and audit module of the system detects that there is a difference between the business execution data of any two systems, the system will immediately start the fault diagnosis process. First, the system locates the fault source by analyzing the performance data (such as response time, error rate, system log, etc.), and further judges the fault type. Among them, the first fault type is temporary fault, such as network instantaneous interruption, temporary error caused by system resource competition; the second fault type is permanent fault, such as hardware damage, data storage medium fault and other irreversible problems. For example, in the data synchronization process between the fixed asset management platform and the financial system, if it is detected that the value of an asset is inconsistent in the two systems, the system analyzes the CPU usage rate, memory occupation condition and network connection state of the financial system server, finds that the financial system has a short response timeout in this period, but then it returns to normal, and thus judges that the fault type is temporary fault (first fault type).

[0105] Step S402: According to the fault type, the corresponding repair strategy is matched from the recovery strategy library, and the repair strategy includes a first repair strategy corresponding to the first fault type and a second repair strategy corresponding to the second fault type.

[0106] It should be noted that the system is built-in with a recovery strategy library, which stores repair strategies for different fault types. The system will automatically match the corresponding repair strategy from the recovery strategy library according to the determined fault type. The first repair strategy is for temporary faults, focusing on fast recovery and retry mechanism; the second repair strategy is for permanent faults, emphasizing data rollback and persistent repair. It can be understood that the recovery strategy library is a knowledge base pre-configured in the system, which contains various practical repair solutions for various known fault types.

[0107] Step S403: When the repair strategy is the first repair strategy, performing data retransmission on the business execution data.

[0108] It should be noted that when the system determines to use the first repair strategy, the data retransmission process is immediately started. The system will try to re-execute the related operation in the target system by re-sending inconsistent data packets or transaction requests to correct the data inconsistency problem. For example, for the financial system data inconsistency caused by temporary faults, the system will resend the value update request of the asset to the financial system through the three-phase commit, and the financial system will reprocess and update the data after receiving the request, thereby solving the data inconsistency problem.

[0109] Step S404: When the repair strategy is the second repair strategy, performing data rollback on the fault system according to the preset rollback strategy, and performing data retransmission on the business execution data after the rollback is completed.

[0110] It should be noted that when the system determines to use the second repair strategy, the fault system will be rolled back according to the preset rollback strategy. The preset rollback strategy defines how to safely restore the system state to a certain known good state before the fault occurs. After completing the rollback, the system will perform the data retransmission process again to try to resynchronize the data. In addition, it should be noted that the preset rollback strategy includes partial rollback and complete rollback, and the specific rollback strategy depends on the severity of the permanent fault, for example, if the permanent fault causes the partial data or system to still cannot solve the problem after individual rollback, complete rollback (i.e. rollback all systems associated with the fault to the latest state before the fault occurs) will be used.

[0111] In one possible implementation, after the step S40, the method further includes:

[0112] Step B10: Comparing the performance data with a preset performance threshold to obtain a performance bottleneck target.

[0113] It should be noted that in this step, the system collects performance data during transaction execution (such as network latency, coordinator CPU usage, memory usage, I / O throughput, etc.) and compares it with preset performance thresholds in real time. The system calculates whether the current performance indicators exceed the normal range through dynamic threshold algorithms (such as sliding window average, exponential weighted moving average, etc.) to locate the performance bottleneck target. In addition, it should be noted that the performance bottleneck target refers to the key data item (such as network, coordinator, storage, etc.) that limits the overall performance of the system.

[0114] Step B20: When the performance bottleneck target is network latency, adjust the timeout threshold and retry time interval in the three-phase commit process according to the preset optimization strategy to improve the network connection state.

[0115] It should be noted that in this step, when the performance bottleneck target is identified as network latency, the system will automatically trigger the network optimization strategy. The network optimization strategy includes: dynamically adjusting the timeout threshold, i.e. according to the historical network latency distribution, extending the timeout time of each phase in the three-phase commit (CanCommit / PreCommit / DoCommit) (for example, from the default 500ms to 800ms) to avoid transaction interruption due to network fluctuations. Optimizing the retry mechanism, i.e. shortening the retry time interval (such as from 1 second to 500ms), and introducing an exponential backoff algorithm to prevent frequent retries from exacerbating network congestion. In addition, it should be noted that the timeout threshold refers to the maximum waiting time allowed for each phase of the transaction. The retry time interval refers to the interval time for trying again after a transaction failure.

[0116] Step B30: When the performance bottleneck target is the coordinator load, adjust the number of shadow coordinators according to the preset optimization strategy.

[0117] It should be noted that in this step, when the performance bottleneck target is identified as high coordinator load, the transaction coordinators within the system will optimize resource allocation through the following strategies: dynamically expanding shadow coordinators, i.e. based on the election mechanism of the Raft algorithm, automatically increasing shadow coordinator nodes (such as from 3 to 5), to disperse the processing pressure of the main coordinator. Load balancing allocation, i.e. the system will evenly distribute transaction requests to the main coordinator and shadow coordinators through the load balancing unit to avoid single-point overload.

[0118] It can be understood that by horizontally expanding the coordinator resources, the overall throughput of the system is improved, ensuring that low-latency transaction processing can still be maintained during peak periods.

[0119] In the embodiment, through the intelligent fault classification and strategy matching mechanism, combined with the performance bottleneck dynamic optimization, the accurate recovery of cross-system faults and the self-adjustment of protocol parameters are realized, the defects of the traditional scheme that is difficult to cope with complex fault scenarios are solved, and the efficiency of cross-system data consistency repair is improved.

[0120] The application also provides a cross-system data maintenance device, please refer to Figure 4 , the cross-system data maintenance device comprises:

[0121] The data acquisition module 10 is used for acquiring asset operation requests across systems.

[0122] The operation analysis module 20 is used for performing business semantic analysis on the asset operation requests to obtain target business system data, wherein the target business system data is a minimum system set to be involved in a transaction.

[0123] The business execution module 30 is used for executing three-phase commit based on the target business system data, and recording business execution data and performance data in the business process of different systems after commit, wherein the three-phase commit comprises a preparation inquiry phase, a pre-commit phase and a formal commit phase.

[0124] The data repair module 40 is used for determining a corresponding repair strategy according to the performance data when detecting that the business execution data in any two systems are different, and repairing the business execution data according to the repair strategy.

[0125] The cross-system data maintenance device provided by the application adopts the cross-system data maintenance method in the above embodiment, and can solve the technical problem of how to guarantee the consistency of cross-system data. Compared with the prior art, the cross-system data maintenance device provided by the application has the same beneficial effects as the cross-system data maintenance method provided by the above embodiment, and other technical features in the cross-system data maintenance device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0126] In an embodiment, the operation analysis module 20 is further used for performing business semantic analysis on the asset operation requests to obtain a business type and a business influence range; constructing a system dependency graph according to the business type and the business influence range; and performing system node pruning based on the system dependency graph to obtain target business system data.

[0127] In an embodiment, the business execution module 30 is further configured to obtain a target execution system and a target execution operation set according to the target business system data; sequentially send a submission request to the target execution system according to an order of the preparation inquiry stage, the pre-commitment stage and the formal commitment stage, and sequentially obtain a feedback state of the target execution system based on the submission request, the submission request including a preparation inquiry request, a pre-commitment request and a formal commitment request; and when the feedback states are all successful states, execute a business according to the target execution operation set, and record business execution data and performance data in a business execution process of the target execution system.

[0128] In an embodiment, the business execution module 30 is further configured to obtain a target execution system and a target execution business according to the target business system data; decompose and transform the target execution business according to a preset business priority rule and a preset business rule to obtain a target execution business priority and a target execution business constraint condition; and obtain a target execution operation set according to the target execution business priority and the target execution business constraint condition.

[0129] In an embodiment, the data repair module 40 is further configured to, when detecting that the business execution data in any two systems are different, obtain a fault type of a fault system according to the performance data, the fault type including a first fault type and a second fault type; match a corresponding repair strategy from a recovery strategy library according to the fault type, the repair strategy including a first repair strategy corresponding to the first fault type and a second repair strategy corresponding to the second fault type; when the repair strategy is the first repair strategy, perform data retransmission on the business execution data; and when the repair strategy is the second repair strategy, perform data rollback on the fault system according to a preset rollback strategy, and perform data retransmission on the business execution data after the rollback is completed.

[0130] In an embodiment, the cross-system data maintenance apparatus further includes a transaction coordination module 50 configured to obtain a transaction coordinator state, the transaction coordinator including a primary coordinator and a shadow coordinator; synchronize states of the primary coordinator and the shadow coordinator according to a preset coordinator state synchronization mechanism, and when the state of the primary coordinator is a fault state, select a target primary coordinator from the shadow coordinator to replace the primary coordinator to perform transaction coordination according to a preset consensus algorithm.

[0131] In an embodiment, the cross-system data maintenance apparatus further comprises a performance optimization module 60 configured to compare the performance data with a preset performance threshold to obtain a performance bottleneck target; when the performance bottleneck target is network latency, adjust a timeout threshold and a retry time interval in a three-phase commit process according to a preset optimization strategy to improve network connection status; when the performance bottleneck target is coordinator load, adjust a number of shadow coordinators according to a preset optimization strategy.

[0132] The present application provides a cross-system data maintenance apparatus, comprising: at least one processor; and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the cross-system data maintenance method in Embodiment One.

[0133] Reference will now be made to the following description Figure 5 which illustrates a structure of the cross-system data maintenance apparatus suitable for implementing the embodiments of the present application. The cross-system data maintenance apparatus in the embodiments of the present application can include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), and car terminals (e.g., car navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The cross-system data maintenance apparatus shown is merely an example and should not impose any limitation on the functions and use range of the embodiments of the present application.

[0134] As Figure 5As shown, the cross-system data maintenance device can include a processing device 1001 (e.g., a central processor, a graphics processor, etc.) that can perform various appropriate actions and processes according to programs stored in a ROM (Read Only Memory) 1002 or programs loaded from a storage device 1003 into a RAM (Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the cross-system data maintenance device are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, an LCD (Liquid Crystal Display), a speaker, a vibrator, etc.; the storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the cross-system data maintenance device to communicate with other devices wirelessly or by wire to exchange data. Although the cross-system data maintenance device with various systems is shown in the figure, it should be understood that all the shown systems are not required to be implemented or possessed. More or fewer systems can be alternatively implemented or possessed.

[0135] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are performed.

[0136] The cross-system data maintenance device provided in the present application adopts the cross-system data maintenance method in the above-mentioned embodiments, and can solve the technical problem of how to guarantee the consistency of cross-system data. Compared with the prior art, the cross-system data maintenance device provided in the present application has the same beneficial effects as the cross-system data maintenance method provided in the above-mentioned embodiments, and other technical features in the cross-system data maintenance device are the same as the features disclosed in the above-mentioned method, which will not be described here.

[0137] It should be understood that various aspects of the disclosure can be implemented in hardware, software, firmware, or combinations thereof, to achieve the various aspects of the disclosure. In the description above, specific features, structures, materials or characteristics can be combined in any suitable manner without necessarily being limited to one or more embodiments or examples.

[0138] The above description is merely illustrative of the application and is not intended to limit the scope of the application. Any modifications or equivalents of the application should be construed as falling within the scope of the application. The scope of the application should be determined by the appended claims.

[0139] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., a computer program) for performing the cross-system data maintenance method in the above-described embodiments.

[0140] The computer readable storage medium provided by the present application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more conductive wires, a portable computer diskette, a hard disk, a RAM (Random Access Memory), a ROM (Read Only Memory), an EPROM (Erasable Programmable Read Only Memory or flash memory), an optical fiber, a CD-ROM (CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted in any suitable medium, including but not limited to electrical wire, optical cable, RF (Radio Frequency), etc., or any suitable combination of the above.

[0141] The above computer readable storage medium can be included in the cross-system data maintenance device, or can exist separately without being assembled into the cross-system data maintenance device.

[0142] The computer readable storage medium carries one or more programs, when the one or more programs are executed by the cross-system data maintenance device, the cross-system data maintenance device is caused to: acquire a cross-system asset operation request; perform business semantic analysis on the asset operation request to obtain target business system data, the target business system data being a minimum system set to be involved in a transaction; perform a three-phase commit based on the target business system data, and record business execution data and performance data in a business process executed by different systems after the commit, the three-phase commit including a preparation inquiry phase, a pre-commit phase, and a formal commit phase; when detecting that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy.

[0143] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0144] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. It is also noted that each block in the block diagrams and / or flow diagrams and combinations of blocks in the block diagrams and / or flow diagrams can be implemented by special-purpose hardware-based systems that perform the specified functions or operations, or combinations of special-purpose hardware and computer instructions.

[0145] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0146] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e. computer programs) for executing the cross-system data maintenance method described above, and can solve the technical problem of how to ensure the consistency of cross-system data. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the cross-system data maintenance method provided by the above embodiments, and will not be described here.

[0147] The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the cross-system data maintenance method as described above.

[0148] The computer program product provided by the present application can solve the technical problem of how to ensure the consistency of cross-system data. Compared with the prior art, the computer program product provided by the present application has the same beneficial effects as the cross-system data maintenance method provided by the above embodiments, and will not be described here.

[0149] The above only describes some embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields based on the technical concept of the present application, and the contents of the present application specification and drawings are included in the patent protection scope of the present application.

Claims

1. A cross-system data maintenance method, characterized by, The method comprises: acquiring an asset operation request across systems; performing business semantic analysis on the asset operation request to obtain target business system data, the target business system data being a minimum system set to be involved in a transaction; acquiring a transaction coordinator state, the transaction coordinator comprising a primary coordinator and a shadow coordinator; synchronizing the states of the primary coordinator and the shadow coordinator according to a preset coordinator state synchronization mechanism, and when the state of the primary coordinator is a failure state, selecting a target primary coordinator from the shadow coordinator according to a preset consensus algorithm to replace the primary coordinator to coordinate the transaction; obtaining a target execution system and a target execution operation set according to the target business system data; sending a commit request to the target execution system in sequence according to the order of a preparation inquiry stage, a pre-commit stage and a formal commit stage, and acquiring feedback states of the target execution system based on the commit request in sequence, the commit request comprising a preparation inquiry request, a pre-commit request and a formal commit request; when the feedback states are all successful states, performing business according to the target execution operation set, and recording business execution data and performance data in the process of business execution of the target execution system; when detecting that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy; wherein when detecting that the business execution data in any two systems are different, determining a corresponding repair strategy according to the performance data, and repairing the business execution data according to the repair strategy, comprises: when detecting that the business execution data in any two systems are different, obtaining a failure type of a failure system according to the performance data, the failure type comprising a first failure type and a second failure type, wherein the first failure type is a temporary failure, including temporary errors caused by network outage and system resource competition, and the second failure type is a permanent failure, including hardware damage and data storage medium failure; matching a corresponding repair strategy from a recovery strategy library according to the failure type, the repair strategy comprising a first repair strategy corresponding to the first failure type and a second repair strategy corresponding to the second failure type; when the repair strategy is the first repair strategy, performing data retransmission on the business execution data; when the repair strategy is the second repair strategy, performing data rollback on the failure system according to a preset rollback strategy, and performing data retransmission on the business execution data after the rollback is completed; comparing the performance data with a preset performance threshold to obtain a performance bottleneck target; when the performance bottleneck target is network delay, adjusting a timeout threshold and a retry time interval in a three-phase commit process according to a preset optimization strategy to improve the network connection state; when the performance bottleneck target is coordinator load, adjusting the number of shadow coordinators according to a preset optimization strategy.

2. The method of claim 1, wherein, The step of performing business semantic analysis on the asset operation request to obtain target business system data comprises: The business semantic analysis on the asset operation request obtains a business type and a business influence range; A system dependency graph is constructed according to the business type and the business influence range; A target business system data is obtained through system node pruning based on the system dependency graph.

3. The method of claim 1, wherein, The target execution system and the target execution operation set are obtained according to the target business system data, which comprises: The target execution system and the target execution business are obtained according to the target business system data; The target execution business priority and the target execution business constraint condition are obtained through decomposition and transformation of the target execution business according to a preset business priority rule and a preset business rule; The target execution operation set is obtained according to the target execution business priority and the target execution business constraint condition.

4. A cross-system data maintenance apparatus characterized by comprising: The device comprises: A data collection module is configured to collect asset operation requests across systems; An operation analysis module is configured to perform business semantic analysis on the asset operation requests to obtain target business system data, which is a minimum system set to be involved in a transaction; A transaction coordination module is configured to obtain a transaction coordinator state, the transaction coordinator comprising a primary coordinator and a shadow coordinator; the state of the primary coordinator and the shadow coordinator is synchronized according to a preset coordinator state synchronization mechanism, and when the state of the primary coordinator is a failure state, a target primary coordinator is selected from the shadow coordinators according to a preset consensus algorithm to replace the primary coordinator to coordinate the transaction; A business execution module is configured to obtain a target execution system and a target execution operation set according to the target business system data; a submission request is sequentially sent to the target execution system according to the order of a preparation inquiry stage, a pre-commitment stage and a formal commitment stage, and a feedback state of the target execution system based on the submission request is sequentially obtained, the submission request comprising a preparation inquiry request, a pre-commitment request and a formal commitment request; when the feedback state is a success state, a business is executed according to the target execution operation set, and business execution data and performance data in the business execution process of the target execution system are recorded. The data repair module is configured to determine a corresponding repair strategy according to the performance data when detecting that the business execution data in any two systems is different, and repair the business execution data according to the repair strategy; wherein when detecting that the business execution data in any two systems is different, the corresponding repair strategy is determined according to the performance data, and the business execution data is repaired according to the repair strategy, including: when detecting that the business execution data in any two systems is different, the fault type of the fault system is obtained according to the performance data, the fault type includes a first fault type and a second fault type, wherein the first fault type is a temporary fault, including network instantaneous interruption, temporary error caused by system resource competition, and the second fault type is a permanent fault, including hardware damage, data storage medium fault; the corresponding repair strategy is matched from the recovery strategy library according to the fault type, the repair strategy includes a first repair strategy corresponding to the first fault type and a second repair strategy corresponding to the second fault type; when the repair strategy is the first repair strategy, the data retransmission is performed on the business execution data; when the repair strategy is the second repair strategy, the data rollback is performed on the fault system according to a preset rollback strategy, and the data retransmission is performed on the business execution data after the rollback is completed. The performance optimization module is configured to compare the performance data with a preset performance threshold to obtain a performance bottleneck target; when the performance bottleneck target is network delay, adjust the timeout threshold and retry time interval in the three-phase commit process according to a preset optimization strategy to improve the network connection state; when the performance bottleneck target is coordinator load, adjust the number of shadow coordinators according to a preset optimization strategy.

5. A cross-system data maintenance device characterized by comprising: The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the cross-system data maintenance method according to any one of claims 1 to 3.

6. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the cross-system data maintenance method according to any one of claims 1 to 3.

Images