Financial industry distributed system data consistency automatic test platform and method

Abstract

The invention discloses a financial industry distributed system data consistency automatic test platform and method, and the method comprises the steps: a test data distribution module is mainly used for generating a test data set with financial transaction characteristics, and distributing the data to a plurality of service nodes of a distributed system; the automatic test module is mainly used for testing the data consistency of the distributed system in four aspects of read-write, transaction, abnormity and final consistency; the node agent module is mainly used for collecting data states, operation logs and abnormal events of each service node in real time, and is synchronized with the central control end; and the result analysis module is mainly used for performing comprehensive evaluation analysis based on the test result of each service node to obtain a consistency analysis result. The method has the advantages that through intelligent data distribution, comprehensive consistency testing and real-time monitoring analysis, the stability and reliability of the financial transaction system in a high-concurrency environment are ensured.

Description

Technical Field

[0001] The present invention relates to consistency testing, and in particular to a data consistency automated testing platform and method for distributed systems in the financial industry. Background Art

[0002] System data consistency testing refers to the process of verifying data consistency within a distributed system. With the widespread adoption of cloud computing, big data, and microservices architectures, the complexity of distributed systems is increasing, and data consistency issues have become a key factor affecting system stability and reliability. Data consistency testing encompasses technologies such as distributed databases, message queues, and transaction management. Its goal is to ensure that data across different nodes remains consistent under all operations, preventing data loss or errors.

[0003] The system data consistency testing systems and methods currently available on the market often lack accurate simulation of the unique transaction characteristics of the financial industry, and are unable to comprehensively test system stability in high-concurrency and complex transaction scenarios. Traditional testing systems often only focus on a single consistency test scenario, ignoring multi-dimensional testing such as transaction ACID characteristics, exception recovery, and eventual consistency. As a result, when faced with sudden failures or high-concurrency scenarios, consistency issues cannot be discovered and repaired in a timely manner. In addition, the test data distribution of existing systems is mostly simple and lacks a dynamic adjustment mechanism, which can easily lead to deviations in test results. In contrast, this system intelligently distributes test data through a dynamic load balancing algorithm to ensure that the test pressure is evenly distributed, and comprehensively evaluates data consistency through diversified test units. It can quickly respond to and repair system problems while collecting node status, logs, and abnormal events in real time. Summary of the Invention

[0004] To improve existing system data consistency testing systems and methods, this paper provides an automated data consistency testing platform and method for distributed financial systems. This method comprehensively verifies the consistency and stability of the system through dynamic load balancing and multi-dimensional testing. It also monitors node status and logs in real time, combines quantitative analysis results, optimizes system performance, and ensures the reliability of financial systems in highly concurrent environments.

[0005] In order to achieve the above objects, the technical solution adopted by the present invention is: The automated data consistency testing platform for distributed systems in the financial industry includes: Test data distribution module: The test data distribution module is mainly used to generate a test data set with financial transaction characteristics and distribute the data to multiple service nodes of the distributed system; Automated testing module: The automated testing module is mainly used to test the data consistency of the distributed system through four aspects: reading and writing, transactions, exceptions and final consistency; Node agent module: The node agent module is mainly used to collect the data status, operation logs and abnormal events of individual service nodes in real time, and synchronize them with the central control terminal; Result analysis module: The result analysis module is mainly used to perform comprehensive evaluation and analysis based on the test results of each service node to obtain consistency analysis results.

[0006] Preferably, the test data allocation module specifically includes: Feature data generation unit: The feature data generation unit is mainly used to generate a simulation test data set containing transaction amount, timestamp, and account ID based on the financial business process; Data distribution unit: The data distribution unit is mainly used to automatically adjust the data distribution weight according to the real-time status of the node through a dynamic load balancing algorithm to ensure that the test pressure is evenly distributed.

[0007] Preferably, the automated testing module specifically includes: Read and write consistency test unit: Generate batch read and write operation requests based on financial transaction scenario processes, including conflicting data; Distribute read and write requests to each node based on a weighted round-robin algorithm, prioritizing low-latency nodes in high-concurrency scenarios. The node agent module captures the timestamp, hash value and operation log of each node data in real time; Compare the final status of the same data item on each node. If there is a version difference, it is determined to be a read-write inconsistency event; The data repair mechanism is triggered based on inconsistencies to verify whether the data is strongly consistent after repair. The transaction and ACID test unit specifically includes: Atomicity test: Initiate a cross-node transaction, randomly suspend operations on some nodes during the transaction commit phase, check whether there is any residual intermediate state data on the uncommitted nodes, and verify whether the data is restored to its initial state after the transaction is rolled back. Isolation testing: Execute multi-version transactions in parallel, set different isolation levels, detect dirty reads, non-repeatable reads, and phantom reads through distributed lock monitoring tools, and compare the actual isolation effect with the consistency rules of the preset isolation level.

[0008] Persistence test: trigger a node crash or disk corruption failure immediately after a transaction is committed. After restarting the node, check the match between the write-ahead log and the data snapshot to verify the persistence integrity. Abnormal recovery test unit: Use chaos engineering tools to randomly disconnect nodes from each other to simulate a network partition. This triggers data writes during the partition. After the network is restored, check for data merging conflicts between nodes on both sides of the partition. Randomly terminate the master node process, check whether the standby node completes the failover within the timeout threshold, and verify whether the new master node data after the switch contains all committed transactions before the failure; Tamper with the node storage file and check the data repair process after restart; Final Conformance Test Unit: Stop all write operations, periodically collect the data status of each node, and record the time when consistency is achieved based on data synchronization; In high-concurrency write scenarios, the system continuously monitors data differences between replicas, calculates the proportion of conflicting data and the time required to resolve conflicts, and generates an eventual consistency convergence curve. Attach a global version vector to each write operation to track the data propagation path and locate blocked nodes.

[0009] Preferably, the node agent module specifically includes: Status collection unit: The status collection unit is mainly used to capture the data status in the node memory, database and cache in real time and add a timestamp mark; Log capture unit: The log capture unit is mainly used to continuously collect node operation logs and filter key events through regular expressions, including data conflicts and lock timeouts; Synchronization control unit: The synchronization control unit is mainly used to maintain a connection with the central control terminal through a duplex communication protocol, and synchronize emergency events and regular data according to priority levels; Local cache module: The local cache module is mainly used to temporarily store collected data during network interruption and re-upload it in chronological order after recovery to ensure data integrity.

[0010] Preferably, the result analysis module specifically includes: Data aggregation unit: The data aggregation unit is mainly used to integrate the test data from each node agent and convert it into a standardized analysis format; Consistency matching unit: The consistency matching unit is mainly used to load the preset consistency rule library and perform pattern matching and compliance verification with the test results; Quantitative scoring unit: The quantitative scoring unit is mainly used to calculate the comprehensive consistency score based on indicators such as the proportion of conflicting data, repair time, and abnormal recovery success rate.

[0011] Furthermore, the automated testing method for data consistency of distributed systems in the financial industry includes: Generate simulation test data sets based on financial business processes and distribute the data to various service nodes in the distributed system; Based on a simulated financial transaction process, the distributed system's read and write consistency is tested through batch read and write requests and conflicting data. Based on cross-node transaction execution, atomicity, isolation, durability and consistency are verified to ensure that the system complies with ACID characteristics; Use chaos engineering tools to simulate abnormal situations such as network partitions and node downtime to test the system's ability to recover under abnormal circumstances. In high-concurrency write scenarios, monitor the node data synchronization process, record the time it takes to achieve consistency and the time it takes to resolve conflicts; Collect data and logs from each node agent, analyze them based on the consistency rule base, and generate a comprehensive consistency score.

[0012] Compared with the prior art, the advantages of the present invention are: Combining the unique transaction characteristics of the financial industry with the complexity of distributed systems, it provides a comprehensive and efficient testing solution. Test data is distributed through a dynamic load balancing algorithm to ensure balanced pressure on each node and avoid test deviations. At the same time, the automated testing module conducts multi-dimensional testing on data consistency, including read-write consistency, transaction ACID characteristics, exception recovery, and eventual consistency, to comprehensively verify the stability and reliability of the system. The node agent module monitors node status and logs in real time to ensure that any abnormal events are captured and synchronized to the central control end in a timely manner, effectively improving problem discovery and response speed. The result analysis module can quantitatively evaluate system consistency through data aggregation and consistency rule matching, generating detailed scoring reports and providing a strong basis for system optimization. This platform not only improves the level of testing automation and reduces the need for manual intervention, but also can effectively detect and fix potential system consistency issues, ensuring the stability and reliability of distributed financial systems in high-concurrency and high-complexity environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 A schematic diagram of the system proposed by the present invention; Figure 2 A schematic diagram of the method proposed in the present invention; Figure 3 This is a diagram of the test data allocation module proposed by the present invention; Figure 4 This is the automated test module diagram proposed by the present invention; Figure 5 This is the node agent module diagram proposed by the present invention; Figure 6 This is the result analysis module diagram proposed by the present invention; Figure 7 This is a diagram of the architecture of the electronic equipment in this solution; Figure 8 This is a schematic diagram of the computer-readable storage medium structure in this solution. DETAILED DESCRIPTION

[0014] The following description is intended to disclose the present invention so that those skilled in the art can implement the present invention. The preferred embodiments described below are merely examples, and those skilled in the art may conceive of other obvious variations.

[0015] See Figure 1 As shown in the figure, the automated data consistency testing platform for distributed systems in the financial industry includes: Test data distribution module: The test data distribution module is mainly used to generate a test data set with financial transaction characteristics and distribute the data to multiple service nodes of the distributed system; Automated testing module: The automated testing module is mainly used to test the data consistency of the distributed system through four aspects: reading and writing, transactions, exceptions and final consistency; Node agent module: The node agent module is mainly used to collect the data status, operation logs and abnormal events of individual service nodes in real time, and synchronize them with the central control terminal; Result analysis module: The result analysis module is mainly used to perform comprehensive evaluation and analysis based on the test results of each service node to obtain consistency analysis results.

[0016] See Figure 2 As shown in the figure, the automated testing method for data consistency of distributed systems in the financial industry includes: Generate simulation test data sets based on financial business processes and distribute the data to various service nodes in the distributed system; Based on a simulated financial transaction process, the distributed system's read and write consistency is tested through batch read and write requests and conflicting data. Based on cross-node transaction execution, atomicity, isolation, durability and consistency are verified to ensure that the system complies with ACID characteristics; Use chaos engineering tools to simulate abnormal situations such as network partitions and node downtime to test the system's ability to recover under abnormal circumstances. In high-concurrency write scenarios, monitor the node data synchronization process, record the time it takes to achieve consistency and the time it takes to resolve conflicts; Collect data and logs from each node agent, analyze them based on the consistency rule base, and generate a comprehensive consistency score.

[0017] See Figure 3 As shown, the test data allocation module specifically includes: Feature data generation unit: The feature data generation unit is mainly used to generate a simulation test data set containing transaction amount, timestamp, and account ID based on the financial business process; Data distribution unit: The data distribution unit is mainly used to automatically adjust the data distribution weight according to the real-time status of the node through a dynamic load balancing algorithm to ensure that the test pressure is evenly distributed.

[0018] Specifically, the transaction amount is generated based on the actual business scenario. By setting an amount range and using a uniform distribution or normal distribution as needed to generate a random amount, the timestamp usually refers to the time when the transaction occurred, in milliseconds, and is generated according to the system's time range. The account ID is randomly selected from the existing account pool. Finally, the test dataset is generated, and the above steps are repeated to generate multiple transaction records to form a complete test dataset. When distributing data, we first need to obtain the real-time status of each node. These statuses may include the node's load, processing capacity, and storage resources. The load of each node i is , the maximum load of the node is , the load ratio of the node can be calculated as follows:

[0019] in, Reflects the load level of each node; The data allocation weight is dynamically adjusted according to the node load ratio. The data allocation weight of node i can be calculated by the following formula:

[0020] Among them, n is the number of nodes. The larger the weight value, the more data the node can process. According to weight , distribute data to each node in proportion to ensure balanced distribution of data among nodes; as the node load changes, the load ratio The load will also change, thereby dynamically adjusting the allocation weight of each node to ensure that the test pressure is always evenly distributed.

[0021] See Figure 4 As shown, the automated testing module specifically includes: Read and write consistency test unit: Generate batch read and write operation requests based on financial transaction scenario processes, including conflicting data; Distribute read and write requests to each node based on a weighted round-robin algorithm, prioritizing low-latency nodes in high-concurrency scenarios. The node agent module captures the timestamp, hash value and operation log of each node data in real time; Compare the final status of the same data item on each node. If there is a version difference, it is determined to be a read-write inconsistency event; The data repair mechanism is triggered based on inconsistencies to verify whether the data is strongly consistent after repair. The transaction and ACID test unit specifically includes: Atomicity test: Initiate a cross-node transaction, randomly suspend operations on some nodes during the transaction commit phase, check whether there is any residual intermediate state data on the uncommitted nodes, and verify whether the data is restored to its initial state after the transaction is rolled back. Isolation testing: Execute multi-version transactions in parallel, set different isolation levels, detect dirty reads, non-repeatable reads, and phantom reads through distributed lock monitoring tools, and compare the actual isolation effect with the consistency rules of the preset isolation level.

[0022] Persistence test: trigger a node crash or disk corruption failure immediately after a transaction is committed. After restarting the node, check the match between the write-ahead log and the data snapshot to verify the persistence integrity. Abnormal recovery test unit: Use chaos engineering tools to randomly disconnect nodes from each other to simulate a network partition. This triggers data writes during the partition. After the network is restored, check for data merging conflicts between nodes on both sides of the partition. Randomly terminate the master node process, check whether the standby node completes the failover within the timeout threshold, and verify whether the new master node data after the switch contains all committed transactions before the failure; Tamper with the node storage file and check the data repair process after restart; Final Conformance Test Unit: Stop all write operations, periodically collect the data status of each node, and record the time when consistency is achieved based on data synchronization; In high-concurrency write scenarios, the system continuously monitors data differences between replicas, calculates the proportion of conflicting data and the time required to resolve conflicts, and generates an eventual consistency convergence curve. Attach a global version vector to each write operation to track the data propagation path and locate blocked nodes.

[0023] Specifically, during the read and write consistency test, the load is obtained for each node , and prioritizes the nodes according to their latency, using a weighted round-robin algorithm to distribute read and write requests to each node. In high-concurrency scenarios, requests are preferentially assigned to nodes with lower latency; Use the node agent module to capture the timestamp, hash value, and operation log of each node's data in real time. For each data item, the node will record the operation log and compare the final status of the same data item on each node. If there is a version difference, it is determined to be a read-write inconsistency event; If an inconsistency event is detected, the system will trigger the data repair mechanism. After the repair mechanism, the strong consistency of the repaired data needs to be verified; Transaction and ACID testing includes atomicity testing: initiating cross-node transactions and randomly suspending operations on some nodes during the transaction commit phase. Atomicity is verified by checking whether there is residual intermediate state data on uncommitted nodes. Isolation testing: Execute multi-version transactions and set different isolation levels. Use distributed lock monitoring tools to detect dirty reads, non-repeatable reads, and phantom reads. Persistence test: After a transaction is committed, immediately trigger a node crash or disk failure. After restarting the node, check the consistency of the write-ahead log and data snapshot to verify the persistence integrity. During abnormal recovery testing, chaos engineering tools are used to simulate network partitions, triggering write operations during the partition. After the network is restored, data merge conflicts between nodes on both sides of the partition are checked. Randomly terminate the master node process and check whether the standby node completes the failover within the timeout threshold. If the standby node's switchover time is less than or equal to the set timeout threshold, failover is performed. After the switchover, the new master node's data should contain all committed transactions. After stopping all write operations, the data status of each node is periodically collected and the time it takes to achieve consistency is recorded. In high-concurrency write scenarios, data differences between replicas are continuously monitored, and the proportion of conflicting data and the time it takes to resolve conflicts are calculated. An eventual consistency convergence curve is generated and appended with a global version vector to track data propagation paths and locate blocked nodes.

[0024] See Figure 5 As shown, the node agent module specifically includes: Status collection unit: The status collection unit is mainly used to capture the data status in the node memory, database and cache in real time and add a timestamp mark; Log capture unit: The log capture unit is mainly used to continuously collect node operation logs and filter key events through regular expressions, including data conflicts and lock timeouts; Synchronization control unit: The synchronization control unit is mainly used to maintain a connection with the central control terminal through a duplex communication protocol, and synchronize emergency events and regular data according to priority levels; Local cache module: The local cache module is mainly used to temporarily store collected data during network interruption and re-upload it in chronological order after recovery to ensure data integrity.

[0025] Specifically, the system needs to periodically capture the data status in the node's memory, database, and cache, including but not limited to database table data, variables in memory, objects in cache, etc. This information can be extracted through APIs or database query statements, for example: Extract table status from the database: SELECT * FROM table_name WHERE condition; Extract specific data from memory: call the memory monitoring tool API to obtain the current memory status; Get data from the cache: read a specific cache key-value pair through the Redis client; When collecting data, a timestamp is added to each data record to mark the time of collection. All collected data including status and timestamp will be temporarily stored in a buffer or database for subsequent processing; The main function of the log capture unit is to continuously collect node operation logs and filter the logs using regular expressions to extract key events, such as: Data conflict: Regular expressions are used to identify data conflict information in logs, such as "conflictdetected"; Lock timeout: Regular expression used to identify lock timeout errors, such as "lock timeout"; Use this regular expression to extract all conflict information from the log; The synchronization control unit is responsible for maintaining a connection with the central control terminal through a duplex communication protocol and synchronizing emergency events and regular data according to priority. The synchronization control unit maintains a real-time connection with the central control terminal through a duplex communication protocol to ensure timely data transmission. Each data or event is assigned a different priority according to the degree of urgency. According to the priority, the system will synchronize data in batches: Emergency event synchronization: high-priority events will be synchronized to the control terminal immediately; regular data synchronization: low-priority data will be synchronized in batches according to preset time intervals or conditions; The local cache module is used to temporarily store collected data during network interruption and re-upload it in chronological order after the network is restored to ensure data integrity. When the network is restored, the cache module will re-upload the data from the local cache to the central control end in timestamp order. The re-uploaded data is sent in chronological order to ensure data consistency.

[0026] See Figure 6 As shown, the result analysis module specifically includes: Data aggregation unit: The data aggregation unit is mainly used to integrate the test data from each node agent and convert it into a standardized analysis format; Consistency matching unit: The consistency matching unit is mainly used to load the preset consistency rule library and perform pattern matching and compliance verification with the test results; Quantitative scoring unit: The quantitative scoring unit is mainly used to calculate the comprehensive consistency score based on indicators such as the proportion of conflicting data, repair time, and abnormal recovery success rate.

[0027] Specifically, the data aggregation unit integrates the test data from each node agent and converts it into a standardized analysis format to facilitate the subsequent consistency matching and quantitative score calculation; The consistency matching unit's main task is to load the preset consistency rule library and perform pattern matching and compliance verification against the test results. This unit verifies whether the system meets the consistency rules. The consistency rule library defines the different consistency requirements that the system should follow. Common consistency rules include: strong consistency: data on all replicas must be synchronized after each write; eventual consistency: all replicas will eventually reach a consistent state, but there may be temporary inconsistencies; Match the test results with the preset rules for consistency check. Based on the data version, hash value, and timestamp, determine whether consistency requirements are met. For strong consistency, the final value of the data item on all nodes must be the same. For eventual consistency, despite data inconsistencies, the system should ensure that the data on all nodes is eventually consistent. By comparing the rule matching with the test data, verify whether the system follows the consistency rules. If the rules are not met, the inconsistency event is recorded and the repair mechanism is triggered. The quantitative scoring unit calculates a comprehensive consistency score based on indicators such as the conflict data ratio, repair time, and exception recovery success rate. Key indicators include: the conflict data ratio is the proportion of data conflicts during the test, indicating the proportion of inconsistent data between different nodes in the system; the repair time is the time required to repair data consistency issues; and the exception recovery success rate is the system's recovery success rate after encountering anomalies such as node downtime and network partitions. Based on these indicators, the final consistency comprehensive score is calculated, and the score can be calculated and output by the weighted average method.

[0028] Furthermore, the method according to the embodiment of the present application can also be used with the aid of Figure 7 The electronic device architecture shown in FIG. Figure 7 As shown, the electronic device 500 may include a bus 501, one or more CPUs 502, a read-only memory (ROM) 503, a random access memory (RAM) 504, a communication port 505 connected to a network, an input / output component 506, a hard disk 507, etc. The storage device in the electronic device 500, such as the ROM 503 or the hard disk 507, may store the data consistency automated testing platform and method for distributed systems in the financial industry provided in this application. The electronic device 500 may also include a terminal interface 508. Of course, Figure 7 The architecture shown is only exemplary and can be omitted according to actual needs when implementing different devices. Figure 7 One or more components of an electronic device are shown.

[0029] Figure 8 This is a schematic diagram of the computer-readable storage medium structure provided by an embodiment of the present application. Figure 8Figure 6 shows a computer-readable storage medium 600 according to one embodiment of the present application. Computer-readable instructions are stored on the computer-readable storage medium 600. When the computer-readable instructions are executed by a processor, the automated data consistency testing platform and method for distributed financial systems according to the embodiments of the present application described with reference to the above figures can be executed. Storage medium 600 includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and cache memory. Non-volatile memory may include, for example, read-only memory (ROM), a hard disk, and flash memory.

[0030] It should be noted that the order in which the embodiments of the present invention are described above is for illustrative purposes only and does not necessarily represent the superiority or inferiority of the embodiments. Furthermore, the foregoing descriptions of specific embodiments of this specification are provided. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential sequence shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0031] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0032] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. The automated data consistency testing platform for distributed systems in the financial industry is characterized by: include: Test data distribution module: The test data distribution module is mainly used to generate a test data set with financial transaction characteristics and distribute the data to multiple service nodes of the distributed system; Automated testing module: The automated testing module is mainly used to test the data consistency of the distributed system through four aspects: reading and writing, transactions, exceptions and final consistency; Node agent module: The node agent module is mainly used to collect the data status, operation logs and abnormal events of individual service nodes in real time, and synchronize them with the central control terminal; Result analysis module: The result analysis module is mainly used to perform comprehensive evaluation and analysis based on the test results of each service node to obtain consistency analysis results.

2. The automated data consistency testing platform for distributed systems in the financial industry according to claim 1 is characterized in that: The test data allocation module specifically includes: Feature data generation unit: The feature data generation unit is mainly used to generate a simulation test data set containing transaction amount, timestamp, and account ID based on the financial business process; Data distribution unit: The data distribution unit is mainly used to automatically adjust the data distribution weight according to the real-time status of the node through a dynamic load balancing algorithm to ensure that the test pressure is evenly distributed.

3. The automated data consistency testing platform for distributed systems in the financial industry according to claim 1 is characterized in that: The automated testing module specifically includes: Read and write consistency test unit: Generate batch read and write operation requests based on financial transaction scenario processes, including conflicting data; Distribute read and write requests to each node based on a weighted round-robin algorithm, prioritizing low-latency nodes in high-concurrency scenarios. The node agent module captures the timestamp, hash value and operation log of each node data in real time; Compare the final status of the same data item on each node. If there is a version difference, it is determined to be a read-write inconsistency event; The data repair mechanism is triggered based on inconsistencies to verify whether the data is strongly consistent after repair. The transaction and ACID test unit specifically includes: Atomicity test: Initiate a cross-node transaction, randomly suspend operations on some nodes during the transaction commit phase, check whether there is any residual intermediate state data on the uncommitted nodes, and verify whether the data is restored to its initial state after the transaction is rolled back. Isolation testing: Execute multi-version transactions in parallel, set different isolation levels, detect dirty reads, non-repeatable reads, and phantom reads through distributed lock monitoring tools, and compare the actual isolation effect with the consistency rules of the preset isolation level.

4. Persistence test: Immediately after a transaction is committed, a node crash or disk corruption failure is triggered. After the node is restarted, the consistency between the write-ahead log and the data snapshot is checked to verify the persistence integrity. Abnormal recovery test unit: Use chaos engineering tools to randomly disconnect nodes from each other to simulate a network partition. This triggers data writes during the partition. After the network is restored, check for data merging conflicts between nodes on both sides of the partition. Randomly terminate the master node process, check whether the standby node completes the failover within the timeout threshold, and verify whether the new master node data after the switch contains all committed transactions before the failure; Tamper with the node storage file and check the data repair process after restart; Final Conformance Test Unit: Stop all write operations, periodically collect the data status of each node, and record the time when consistency is achieved based on data synchronization; In high-concurrency write scenarios, the system continuously monitors data differences between replicas, calculates the proportion of conflicting data and the time required to resolve conflicts, and generates an eventual consistency convergence curve. Attach a global version vector to each write operation to track the data propagation path and locate blocked nodes.

5. The automated data consistency testing platform for distributed systems in the financial industry according to claim 1 is characterized in that: The node agent module specifically includes: Status collection unit: The status collection unit is mainly used to capture the data status in the node memory, database and cache in real time and add a timestamp mark; Log capture unit: The log capture unit is mainly used to continuously collect node operation logs and filter key events through regular expressions, including data conflicts and lock timeouts; Synchronization control unit: The synchronization control unit is mainly used to maintain a connection with the central control terminal through a duplex communication protocol, and synchronize emergency events and regular data according to priority levels; Local cache module: The local cache module is mainly used to temporarily store collected data during network interruption and re-upload it in chronological order after recovery to ensure data integrity.

6. The automated data consistency testing platform for distributed systems in the financial industry according to claim 1 is characterized in that: The result analysis module specifically includes: Data aggregation unit: The data aggregation unit is mainly used to integrate the test data from each node agent and convert it into a standardized analysis format; Consistency matching unit: The consistency matching unit is mainly used to load the preset consistency rule library and perform pattern matching and compliance verification with the test results; Quantitative scoring unit: The quantitative scoring unit is mainly used to calculate the comprehensive consistency score based on indicators such as the proportion of conflicting data, repair time, and abnormal recovery success rate.

7. The automated testing method for data consistency of distributed systems in the financial industry is characterized by: include: Generate simulation test data sets based on financial business processes and distribute the data to various service nodes in the distributed system; Based on a simulated financial transaction process, the distributed system's read and write consistency is tested through batch read and write requests and conflicting data. Based on cross-node transaction execution, atomicity, isolation, durability and consistency are verified to ensure that the system complies with ACID characteristics; Use chaos engineering tools to simulate abnormal situations such as network partitions and node downtime to test the system's ability to recover under abnormal circumstances. In high-concurrency write scenarios, monitor the node data synchronization process, record the time it takes to achieve consistency and the time it takes to resolve conflicts; Collect data and logs from each node agent, analyze them based on the consistency rule base, and generate a comprehensive consistency score.

8. An electronic device, characterized in that: include: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the automated data consistency testing method for distributed systems in the financial industry as described in any one of claims 1-7.

9. A computer-readable storage medium storing computer-readable instructions, characterized in that: When the computer-readable instructions are executed by a processor, the automated testing method for data consistency of a distributed system in the financial industry according to any one of claims 1 to 7 is implemented.

Images