Parallel verification method, computer device, medium and program product for system migration

Abstract

The present application relates to the technical field of computers, and more particularly to a parallel verification method for system migration, a computer device implementing the method, a computer readable storage medium and a computer program product. The method comprises: receiving real-time transaction data from a production system; obtaining a flow count of the real-time transaction data based on an asynchronous ticking mechanism, wherein the flow count is obtained by synchronously updating counters of a current time window and a previous time window; dynamically adjusting a size of the time window based on the flow count; dividing the real-time transaction data into ordered data batches using the adjusted time window; executing corresponding tests in a test environment based on the ordered data batches and generating test results; and verifying the test results using corresponding transaction processing results from the production system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a parallel verification method for system migration, a computer device for implementing the method, a computer-readable storage medium, and a computer program product. Background Technology

[0002] During system migration, especially in sectors with extremely high business continuity requirements such as finance and telecommunications, rigorous parallel testing is typically required before the actual switchover to the production system. This involves having the old and new systems simultaneously process real production traffic and comparing the results. However, traditional parallel testing methods often rely on manual pre-analysis of transaction logic and hard-coded pairing rules, resulting in fixed and inflexible test windows. When faced with high-concurrency, time-sensitive online transaction scenarios, this approach struggles to accurately reproduce complex business interaction sequences, easily leading to incorrect or missed transaction pairings. This results in incomplete test coverage, compromised accuracy and reliability of verification results, and ultimately impacts the confidence level of the migration decision and implementation risk.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] To address or at least mitigate one or more of the above problems, embodiments of this application provide a parallel verification method for system migration, a computer device for implementing the method, a computer-readable storage medium, and a computer program product.

[0005] According to a first aspect of this application, a parallel verification method for system migration is provided, comprising the following steps: receiving real-time transaction data from a production system; obtaining a traffic count of the real-time transaction data based on an asynchronous timing mechanism, wherein the traffic count is obtained by synchronously updating the counters of the current time window and the previous time window; dynamically adjusting the size of the time window based on the traffic count; dividing the real-time transaction data into ordered data batches using the adjusted time window; executing corresponding tests in a test environment and generating test results based on the ordered data batches; and verifying the test results using the corresponding transaction processing results from the production system.

[0006] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the asynchronous timing mechanism is executed by a timing counting coroutine independent of the main data processing flow, and the timing counting coroutine updates the counter asynchronously in response to the arrival event of each real-time transaction data.

[0007] As an alternative or supplement to the above solution, a method according to an embodiment of this application further includes: saving the execution state of the dot-counting coroutine in its context environment; and restoring the execution state using its context environment when the dot-counting coroutine is scheduled to switch.

[0008] As an alternative or supplement to the above solutions, a method according to an embodiment of this application further includes: setting a dot marker in the callback function of the dot counting coroutine, the dot marker being used to track and record at least one of the function's start-up, termination, and exception events; and / or allocating an independent stack space for the dot counting coroutine, and monitoring the usage status of the stack space through a dot counting mechanism.

[0009] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, synchronously updating the counters of the current time window and the previous time window includes: incrementing the count value of the current time window each time the asynchronous timing mechanism receives a timing event, and synchronously updating the count value of the previous time window based on a preset smoothing algorithm.

[0010] As an alternative or supplement to the above solution, the method according to an embodiment of this application further includes: monitoring the status of the elastic scaling cache used to cache transaction data, including calculating one or more of the following: cache hit rate, real-time access frequency, and cache space utilization rate; and performing dynamic scaling on the elastic scaling cache based on the monitoring results.

[0011] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the real-time access frequency is calculated using the following sliding time window algorithm: Where F(t) is the access frequency at time t, Ci is the number of times the cache is accessed in the i-th time slice, n is the total number of time slices in the time window, and T is the total length of the time window.

[0012] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, performing dynamic scaling on the elastic scaling cache based on monitoring results includes: triggering a gradient scaling operation of the cache when the cache space utilization rate is higher than its scaling threshold, and at least one of the cache hit rate and the access frequency is also higher than their respective scaling thresholds; and triggering a gradient scaling operation of the cache when the cache space utilization rate is lower than its scaling threshold, and at least one of the cache hit rate and the access frequency is also lower than their respective scaling thresholds.

[0013] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the gradient expansion operation or the gradient shrinkage operation is continuously performed until the cache space utilization rate reaches a preset target range.

[0014] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, dividing the real-time transaction data into ordered data batches using the adjusted time window includes: taking the start and end times of the time window as boundaries, aggregating all transaction data falling within the same window into a logically continuous and ordered data batch, with different batches arranged according to the order of the time window.

[0015] As an alternative or supplement to the above solutions, the method according to an embodiment of this application further includes: monitoring the operating indicators of the test environment, the operating indicators including system throughput, request response time and business processing error rate; when at least one operating indicator is detected to exceed its preset normal range, it is determined that the verification process is abnormal; in response to the abnormality determination, switching from online processing mode to offline processing mode.

[0016] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, switching from online processing mode to offline processing mode includes: pausing the asynchronous tracking mechanism and closing the interface for receiving real-time transaction data; and executing a batch testing process based on historical transaction data read from a distributed file system.

[0017] As an alternative or supplement to the above solutions, the method according to an embodiment of this application further includes: when at least one operating indicator is detected to exceed its preset normal range, recording and persistently storing the status and system context of the data batch that has not yet completed the test.

[0018] As an alternative or supplement to the above solution, the method according to an embodiment of this application further includes: when at least one operating indicator is detected to have recovered to a preset normal range and remained stable for a preset duration, switching back from the offline processing mode to the online processing mode.

[0019] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, switching back to the online processing mode includes: synchronizing the test results and system status generated in the offline processing mode to the online environment and completing data consistency verification; restarting the asynchronous tracking mechanism; and opening the receiving interface for the real-time transaction data and resuming data stream processing.

[0020] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, verifying the test results using the corresponding transaction processing results from the production system includes: comparing the test results corresponding to the same data batch with the transaction processing results of the production system item by item, and determining whether the verification passes based on the consistency rate of the comparison results.

[0021] According to a second aspect of this application, a computer device is provided, comprising: a memory; a processor; and a computer program stored on the memory and executable on the processor, the execution of which causes any one of the parallel verification methods according to a first aspect of this application to be performed.

[0022] According to a third aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including instructions that, when executed, perform any one of the parallel verification methods according to a first aspect of this application.

[0023] According to a fourth aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements any one of the parallel verification methods described in the first aspect of this application.

[0024] The parallel verification scheme according to one or more embodiments of this application dynamically acquires real-time transaction flow counts based on an asynchronous point-of-sale mechanism and dynamically adjusts the size of the time window used to organize data based on these counts, achieving adaptive control over highly volatile transaction flows. Using this dynamically adjusted time window, the system can divide the real-time transaction data flow into ordered data batches, thus establishing a clearly structured and time-controllable input foundation for subsequent test execution. Finally, by comparing the test results with the processing results of the production system, efficient verification of the correctness of system migration is achieved. This scheme overcomes the pairing confusion and verification omissions that can easily occur when dealing with peak flow using a fixed time window, significantly improving the accuracy of data processing, timing restoration capability, and overall verification reliability during parallel verification. Attached Figure Description

[0025] The above and / or other aspects and advantages of this application will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. In the drawings: Figure 1 This is a schematic flowchart of a parallel verification method 10 according to one or more embodiments of this application; Figure 2 This is a schematic flowchart of a parallel verification method 20 according to one or more embodiments of this application; Figure 3 This is a schematic block diagram of a computer device 30 according to one or more embodiments of this application. Detailed Implementation

[0026] The following detailed description is merely exemplary in nature and is not intended to limit the disclosed technology or its application and use. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical fields, background art, or the following detailed description.

[0027] In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0028] Terms such as "comprising" and "including" indicate that, in addition to the units and steps that are directly and explicitly described in the specification, the technical solution of this application does not exclude the presence of other units and steps that are not directly or explicitly described. Terms such as "first" and "second" do not indicate the order of the units in terms of time, space, size, etc., but are merely used to distinguish the units.

[0029] In the following, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings.

[0030] It should be noted that the parallel verification method provided in this application can be widely applied to verification and switching assurance scenarios of high-concurrency, high-availability online transaction systems in fields such as finance, telecommunications, and e-commerce during cloud migration or major architectural upgrades. For example, in the core clearing and settlement systems of banks or payment institutions, tens of millions or even higher levels of real-time transactions need to be processed daily. During the migration of such systems to the cloud, it is essential to ensure business continuity, data consistency, and that the functions and performance of the migrated system are fully compatible with the original production environment.

[0031] Please refer to the attached diagram below. Figure 1 This is a schematic flowchart of a parallel verification method 10 according to one or more embodiments of this application.

[0032] like Figure 1 As shown, in step 101, real-time transaction data from the production system is received.

[0033] This step aims to establish a real-time data connection with the production environment, ensuring that the test environment can acquire authentic and complete business traffic, providing a source guarantee for subsequent synchronous testing and comparative verification. The "production system" typically refers to the core business system that is online and actually processes user requests, such as a bank's transaction processing center or payment transfer platform. The "real-time transaction data" refers to the request and response message streams generated and processed in the production system, possessing time-series characteristics and business integrity; its format may conform to specific industry standards or internal protocols.

[0034] In one or more embodiments, real-time transaction data may originate from network packet mirroring distributed by the transaction access layer (such as a front-end server or gateway) of the production system, or from the transaction logs of the database or the real-time message stream in the message middleware. For example, a dedicated distribution device or agent can be deployed on the production system side to losslessly copy each passing transaction request and response message in a bypass manner, forming a real-time data stream. This data stream is then pushed to the parallel verification system through a secure, high-bandwidth network channel.

[0035] In one or more embodiments, the receiving process can be implemented through a traffic splitting access module. This module is responsible for establishing a connection with the data source on the production side and performing preliminary processing such as protocol parsing and data decoding to convert the raw byte stream, which may be encapsulated with specific communication protocols, into structured transaction records that can be recognized by subsequent processing stages. For example, for data packets captured from network mirroring, the traffic splitting access module can perform IP / TCP unpacking, application layer protocol parsing, and extract key transaction elements, such as transaction type, timestamp, unique sequence number, request content, etc.

[0036] In step 103, the flow count of real-time transaction data is obtained based on the asynchronous timing mechanism, wherein the flow count is obtained by synchronously updating the counters of the current time window and the previous time window.

[0037] This step aims to perform high-precision, low-latency traffic statistics and monitoring of continuously flowing real-time transaction data, providing data basis for subsequent dynamic adjustment of the processing window. The "asynchronous counting mechanism" refers to a lightweight counting technology decoupled from the main data processing flow. By separating the counting operation from the actual transaction processing logic, it avoids blocking or delaying the core data processing and verification process due to counting overhead (such as lock contention, I / O wait), thus ensuring the overall throughput of the system under high concurrency.

[0038] In one or more embodiments, the asynchronous timing mechanism can be executed by a "timing and counting coroutine" independent of the main data processing flow. This timing and counting coroutine continuously listens for transaction arrival events. For example, its specific workflow may include: when real-time transaction data arrives at the system's request processor, the processor, while continuing to process the main transaction flow, asynchronously (i.e., without blocking the main request processing thread) sends a "timing" event to the timing and counting coroutine. This timing and counting coroutine, acting as the counting core, upon receiving the event, performs a synchronous update operation on two time window counters: updating the counter for the "current time window" and the counter for the "previous time window." The updated counter values ​​can then be stored in a high-speed storage unit. The traffic controller can periodically or when a decision needs to be made (e.g., determining whether to trigger cache expansion) query these stored counter values ​​and perform corresponding operations according to preset rules. This design ensures the real-time performance and accuracy of traffic statistics while avoiding impacting the performance of the main transaction processing chain.

[0039] To achieve efficient and accurate counting state management, in one or more embodiments, a dedicated context environment can be allocated to the dot-matrix counting coroutine. Key execution state information (such as the program counter and general-purpose register values) can be stored in CPU (Central Processing Unit) registers. Since CPU registers are high-speed internal storage units, their access speed is much higher than system memory. This makes the saving and restoring of coroutine states extremely fast, greatly reducing the overhead of coroutine switching. Furthermore, the hardware-supported state saving and restoring mechanism ensures that the values ​​in the registers are correctly and atomically saved and restored during coroutine scheduling switching. This allows the coroutine to resume execution precisely from the point of the last interruption when it is scheduled again, guaranteeing the continuity of the counting logic.

[0040] In one or more embodiments, the dot-counting mechanism further assists in managing execution parameters associated with coroutines. Specifically, during coroutine creation, the dot-counting mechanism ensures that parameters to be passed to the coroutine's callback function (such as the initial size of the time window, the memory address of the counter, etc.) are accurately initialized and associated with its context. When the coroutine is scheduled to execute its callback function, these parameters can be correctly read and used, thereby guaranteeing the accurate initialization and execution of the counting logic.

[0041] Beyond basic counting and state management, in one or more embodiments, more granular monitoring and safeguards can be implemented for dot-counting coroutines. For example, "dot markers" can be set in the callback functions corresponding to the dot-counting coroutines. These markers can be placed at key nodes such as function start, termination, and exception handling to track and record critical events in the coroutine's lifecycle, providing detailed information for system operation diagnosis and problem localization. Furthermore, a separate stack space can be allocated to the dot-counting coroutine to store temporary data such as local variables and return addresses during its execution. By monitoring the usage of this independent stack space through the dot-counting mechanism (e.g., setting dots during coroutine creation to determine stack capacity, and setting dots during push and pop operations to track actual usage depth), stack overflow errors and potential memory leaks can be effectively prevented, thereby enhancing program stability and execution efficiency.

[0042] Regarding traffic counting, step 102, "synchronously updating the counters for the current time window and the previous time window," aims to maintain a set of continuous statistical data reflecting recent traffic trends, providing a robust basis for dynamic adjustment decisions. The core of this operation is that for each incoming transaction data event, the system must update the "current time window" counter representing the latest time period and the "previous time window" counter for the immediately preceding time period, in order to simultaneously capture both the instantaneous value and the trend of traffic changes.

[0043] In one implementation, each time a tick event is received, the count value of the current time window can be incremented (e.g., +1), and the count value of the previous time window can be synchronously updated based on a preset smoothing algorithm (e.g., exponentially weighted moving average). In another implementation, the current event count can also be accumulated simultaneously into the counters of the current window and the previous window at a certain ratio.

[0044] In one or more embodiments, the updated counter value can be stored in a CPU register, cache, or specific memory region for low-latency querying by subsequent decision-making components such as the flow controller. The advantage of this design, which simultaneously maintains counts for two consecutive time windows, is that it provides both the latest snapshot of the flow and short-term change trajectories, making subsequent decisions such as dynamic window size adjustments more sensitive and resistant to interference. This improves the system's adaptability and processing accuracy in the face of production flow fluctuations.

[0045] In one or more embodiments, the method further includes status monitoring and dynamic capacity management of an elastically scaling cache used for temporarily caching transaction data to ensure that the system can efficiently handle fluctuating data streams and guarantee the continuity of data processing during parallel verification. The "elastically scaling cache" is a high-speed data buffer that can automatically adjust its storage capacity according to real-time load. It is designed to adapt to dynamic changes in the system's transaction throughput (TPS) and meet the data buffering requirements when online and offline business modes are running in parallel or switched.

[0046] Structurally, an elastic scaling cache can be logically divided into several key areas, collectively supporting its efficient and elastic operation. The data storage area is the core component of the entire cache, typically constructed using memory or other high-speed storage media to enable high-speed read and write operations on transaction data. Considering potential future expansion needs, this area not only meets current performance requirements but also possesses excellent scalability in its architectural design, enabling flexible and seamless increases in storage capacity through elastic scaling mechanisms (such as dynamic memory allocation or the addition of distributed nodes). The metadata area undertakes crucial management functions, storing descriptive information about all cached data within the data storage area, such as the location pointer of each data entry, data size, creation or update timestamp, and access frequency. This metadata improves cache management and access efficiency, especially during cache expansion or data migration operations. The system can quickly locate and reorganize data using metadata, ensuring the continuous and stable operation of the cache system during capacity adjustments. The monitoring area is specifically responsible for recording and summarizing the cache's operational status in real time. Its core tasks include calculating and tracking key performance indicators such as cache hit rate, real-time access frequency, and cache space utilization. These real-time generated performance parameters directly provide data support for subsequent intelligent scaling decisions.

[0047] The monitoring process specifically involves the continuous calculation and analysis of several key performance indicators. Among them, cache hit rate, used to evaluate cache efficiency, is defined as the ratio of cache hits to total data requests. Cache space utilization is the ratio of currently used cache capacity to total cache capacity, directly reflecting the scarcity of storage resources. Access frequency reflects the request pressure on cached data per unit time, and its calculation can rely on a sliding window algorithm. For example, the access frequency F(t) at time t can be calculated using the following formula: Where Ci represents the number of times the cache is accessed within the i-th time slice, n is the total number of time slices contained in the set time window, and T is the total length of the time window (in seconds).

[0048] Based on continuous monitoring of these metrics, the system can trigger dynamic scaling operations on the elastically expandable / shrinkable cache. In one or more embodiments, the dynamic scaling follows an intelligent strategy of joint decision-making based on multiple metrics. Specifically, when the cache space utilization rate is higher than its preset expansion threshold, and at least one of the two metrics, cache hit rate and real-time access frequency, is also higher than its respective expansion threshold, the system can determine that the current load is high and the cache is effective, and thus trigger a gradient scaling operation on the cache. Conversely, when the cache space utilization rate is lower than its shrinkage threshold, and at least one of the cache hit rate and access frequency is also lower than its respective shrinkage threshold, it indicates that the load is decreasing and cache resources may be idle, and the system can trigger a gradient shrinkage operation on the cache. The above-mentioned gradient scaling up or shrinking operation is not adjusted to the limit all at once, but can be carried out gradually according to a preset capacity gradient (e.g., expanding or shrinking the memory space by a fixed percentage each time). This process can be iterated continuously until the joint conditions that trigger the operation are no longer met. Typically, this allows the cache space utilization to return to a preset healthy target range (e.g., maintained between 70% and 80%), thereby achieving an optimal balance between resource utilization and performance. This self-feedback elastic scaling mechanism enables the caching system to intelligently respond to traffic fluctuations, significantly improving operational stability and data processing accuracy in high TPS scenarios.

[0049] In step 105, the size of the time window is dynamically adjusted based on the flow count.

[0050] Step 105 aims to overcome problems such as test data synchronization delays, unreasonable batch division, or insufficient resource utilization that may occur when a fixed time window is used in the face of natural fluctuations in production system traffic. By enabling the size of the time window to intelligently scale with real-time traffic conditions, it ensures that the data processing rhythm of the test environment remains synchronized with the actual load changes in the production environment, thereby maximizing the real-time performance and accuracy of the verification under limited resources.

[0051] In one embodiment, the dynamic adjustment logic is based on continuous analysis and comparison of traffic counts between the current time window and the previous time window. For example, the triggering and magnitude calculation of the adjustment can be based on the following strategy: the system periodically (e.g., every second) or with each window slide, calculates the difference or ratio between the instantaneous traffic count of the current window and the count of the previous window. If the difference exceeds a positive threshold or the ratio is significantly greater than 1, it indicates that traffic is on an upward trend. This can be addressed by appropriately shortening the length of the next time window, thereby creating more data batches with a more balanced data volume per unit time. This allows testing and verification to more closely track high-frequency transactions, reduces data backlog, and improves real-time processing. Conversely, if the difference or ratio shows a significant decrease in traffic, the length of the next time window can be extended. This helps to merge data during low-traffic periods, reduces system scheduling and batch management overhead caused by excessively small windows, and optimizes resource utilization.

[0052] In another embodiment, dynamic adjustment can be achieved based on a preset mapping relationship between traffic range and window size. For example, multiple sets of "traffic range-window duration" mapping tables can be pre-configured, such as: when the traffic count is in the low traffic range of [0, 1000] TPS, the window duration is set to 1 second (small window ensures fine-grained verification); when it is in the medium traffic range of [1001, 5000] TPS, the window duration is set to 3 seconds; when it is in the high traffic range of [5001, +∞] TPS, the window duration is set to 5 seconds (large window reduces batch size and reduces processing pressure).

[0053] In another embodiment, dynamic adjustment can also be based on more complex rules or predictive models. For example, by combining counts from two time windows, a simple moving average or trend extrapolation algorithm can be used to predict the expected traffic for the next period, and the window size can be pre-set accordingly. Regardless of the specific algorithm used, the adjusted window size is usually constrained within a pre-defined reasonable range to avoid performance instability caused by window extremes.

[0054] In step 107, the real-time transaction data is divided into ordered data batches using the adjusted time window.

[0055] Step 107 aims to transform the continuous real-time data stream into discrete, manageable test units that maintain temporal logic, providing structured input for subsequent testing in the test environment. Ordered data batches ensure that the natural order and causal relationships of transaction processing in the production environment are reproduced in the test environment. This is a prerequisite for parallel verification, especially for verifying business logic with state dependencies or strict temporal requirements.

[0056] In one or more embodiments, the logic of the partitioning operation includes: using the start and end times of each dynamic time window as explicit time boundaries, aggregating all real-time transaction data whose timestamps fall within that window to form a logically continuous and ordered data batch. Data items within each batch maintain their original relative order of processing in the production system. Simultaneously, different batches are strictly arranged according to the chronological order of their corresponding time windows; that is, batches generated in earlier windows are always placed before batches generated in later windows, thus maintaining a global time series at the batch level. This partitioning method essentially segments the data stream along the time dimension, transforming an infinite data stream into a finite and ordered batch sequence.

[0057] In practice, different implementation methods are possible. For example, in one or more embodiments, this work can be handled by a component called a "data assembler." This component continuously receives structured transaction data from the traffic distribution access module and maintains the currently active time window. When the system determines that a time window has ended (e.g., triggered by a dynamically adjusted window length timer), the data assembler immediately packages all the transaction data accumulated within that window, appends metadata such as the window ID and start and end times, forming a complete data batch, and sends it to an ordered queue or message topic for consumption by the subsequent test execution module. For data arriving near the window boundary, timestamp comparison can ensure that it is assigned to the correct batch.

[0058] Furthermore, in one or more embodiments, to ensure data consistency during transmission and processing, additional processing may be performed when batches are formed, such as adding a consistency flag to each transaction within the batch, performing lightweight compression, or encryption. This ordered batch partitioning method based on dynamic time windows not only preserves the integrity and temporal order of business data, laying the foundation for high-fidelity test playback, but also, because the window size is dynamically adjusted, the resulting data batches can adapt to changes in traffic volume, avoiding processing delays caused by excessively large batches during peak traffic periods, or system overhead caused by a large number of excessively small batches during low traffic periods, thus achieving a balance between processing efficiency and verification quality.

[0059] In step 109, based on ordered data batches, the corresponding tests are executed in the test environment and test results are generated.

[0060] This step aims to use data synchronized in real-time with the production environment and maintaining business timelines to drive business processing in a simulated or reconstructed target system (i.e., the migrated system to be verified), thereby verifying its functional correctness, performance, and behavioral consistency under real load. The "test environment" is typically an independent deployment isolated from the production environment but with an architecture and configuration as consistent as possible, used to securely host the verification activities.

[0061] In one or more embodiments, the specific process of executing the test is as follows: The test execution engine retrieves a data batch sequentially from an ordered queue. First, the engine can parse the metadata of the batch (such as the corresponding time window range) and may dynamically generate or match corresponding test cases based on the original transaction data within the batch. For example, for a payment transaction request, the test case will instruct the corresponding service in the test environment to process the request and generate a response. Subsequently, the engine can schedule relevant services or components in the test environment to execute these test cases sequentially according to the natural order of the data items within the batch. During execution, the test environment can simulate real production logic to process each transaction and record all key results of its output, including response messages, database state changes, log output, and processing performance data (such as processing time). All these outputs are structured and organized to constitute the test results corresponding to the batch.

[0062] In one or more other embodiments, to improve verification efficiency, test execution can employ a moderate concurrency strategy, but its core must strictly adhere to the global order between data batches and the local order of data within a batch to ensure that the causal consistency of stateful transactions is correctly verified. For example, the system can process multiple different data batches in parallel, but it must guarantee that for any dependent transactions (e.g., dependent on a balance update of a previous transaction), the batches they belong to and the order within those batches are maintained. This can be achieved through dependency analysis and scheduling control.

[0063] When generating test results, the system can create a detailed record for each processed transaction. This record may include a unique identifier of the original transaction, the output after processing in the test environment, the timestamp of the test environment, the processing status (such as success, failure, or exception), and a pointer to benchmark data for subsequent comparison.

[0064] In step 111, the test results are verified using the corresponding transaction processing results from the production system.

[0065] Step 111 is the quality assessment stage of the parallel verification process. Its purpose is to evaluate whether the migrated system is equivalent to the original production system in terms of functionality, performance, and data consistency by accurately comparing the output of the test environment with a verified, real-world production baseline. This verification result is the ultimate basis for determining whether the system's cloud migration was successful and whether a secure switchover can be performed.

[0066] In one or more embodiments, the specific process of performing verification is as follows: The verification engine first needs to obtain the transaction processing results from the production system corresponding to the current test batch. These results are usually captured and stored synchronously when the original transactions are processed on the production side, for example, by collecting response messages through the aforementioned mirroring and diversion mechanism, or by extracting the final state from the production database logs. Subsequently, the verification engine can compare the test results with the production results item by item. The comparison not only focuses on the final output of the business (such as response codes and response message content), but may also delve into the side effects generated during the processing, such as changes to database records, message sending, or key intermediate states. For each transaction, the comparison result can be marked as "consistent" or "inconsistent". Finally, the consistency of the transaction comparison within the entire data batch can be statistically analyzed, the consistency rate can be calculated (e.g., number of consistent transactions / total number of transactions), and a preset threshold (such as 90%) can be used to determine whether the batch test passes verification.

[0067] In one or more other embodiments, the verification process can employ a more flexible strategy. For example, in addition to simple item-by-item comparison, the system can also compare key performance indicators, such as whether the difference in processing time for the same transaction between the test environment and the production environment is within the allowable error range. For complex transactions, verification may involve correlation analysis across the results of multiple related transactions. Furthermore, the verification engine can perform real-time analysis, immediately triggering alarms and suspending subsequent batch processing if a key inconsistency (such as a discrepancy in the amount of a financial transaction) is detected during the comparison process, so as to intervene and investigate in a timely manner.

[0068] In one or more embodiments, method 10 may further include an active monitoring and high-availability guarantee mechanism for the operating status of the test environment itself, to ensure that the entire parallel verification process can continue even when faced with test environment instability or external anomalies, thereby ensuring the continuity of verification work and the integrity of test data. During the verification execution process (e.g., in steps 109 and 111 as described above), the operating indicators of the test environment are continuously monitored. These indicators include, but are not limited to, key parameters reflecting system health, such as system throughput (e.g., TPS), request response time, and business processing error rate. When at least one operating indicator is detected to exceed its preset normal range (e.g., a sudden increase in response time or a surge in error rate), the system can automatically determine that the verification process is abnormal. In response to this abnormal determination, a mode switch can be performed, switching from online processing mode to offline processing mode. This mode switching technology enables the system to continue completing transaction processing verification in the event of a sudden failure, thereby avoiding service interruption and improving the robustness of the entire verification process.

[0069] The online processing mode refers to the verification process described in the preceding steps, which is synchronized with the production data stream in real time. The offline processing mode, on the other hand, is a degraded but guaranteed verification state. Its core is to continue testing and verification using pre-stored historical data without relying on the real-time production data stream. Online / offline switching, as a test process management technology, involves multiple layers in its design and execution. In one or more embodiments, the system processes the production data source in real time during normal online testing and integrates the processing flow with the online test engine. Simultaneously, the system possesses robust monitoring capabilities, enabling real-time monitoring of operational status and performance indicators. Upon detecting anomalies or a decline in performance indicators, an alarm mechanism is immediately triggered, and the switching process is initiated.

[0070] Switching from online to offline mode is a controlled process. In one or more embodiments, the specific operations include: first, pausing the asynchronous tracking mechanism and stopping the counting of real-time traffic; simultaneously, closing the receiving window for real-time transaction data, temporarily cutting off data inflow from the production environment to prevent data accumulation or loss under abnormal conditions. During the switchover, system control is transferred to the offline processing flow. Subsequently, the system switches to a batch testing process based on pre-synchronized historical transaction data read from a distributed file system (such as HDFS) or other big data storage system. In this mode, data processing changes from real-time processing to batch processing. The system performs full processing to reprocess all relevant business data and sends the results to the online engine; simultaneously, incremental processing is performed to update real-time data changes. For incremental data, the system ensures that it is processed at least once and allows for repeated processing to guarantee data integrity and accuracy.

[0071] To support smooth switching, problem fixing, and subsequent recovery, the system incorporates corresponding fault tolerance and state management mechanisms in one or more embodiments. When an anomaly is detected and a switchover is imminent, the current operating state is automatically recorded immediately, and critical data is persistently stored, particularly the state of data batches that have not yet completed testing, along with related system context information. This state snapshot preserves the critical context at the moment of failure, providing a basis for problem diagnosis, system optimization, and continued processing after recovery. The offline testing mode remains always ready, enabling the system to quickly switchover when a failure occurs in the online mode. In offline mode, an extended time window can be used to perform in-depth analysis and batch testing of historical data in the cache or storage, identifying and fixing potential problems.

[0072] In offline mode, operational metrics are continuously monitored. Once all key operational metrics have recovered to the preset normal range and remained stable for a preset period, the system can trigger a switchback from offline to online processing mode. Switching back to online mode is a rigorous recovery and synchronization process. In one or more embodiments, this includes the following steps: First, ensure the data receiving window remains closed before the switchback. Then, synchronize all test results generated in offline mode with the updated system state to the online environment and perform strict data consistency checks to ensure state alignment. After the switchback operation is successfully completed, close the data receiving window and restart the asynchronous tracking mechanism. Finally, reopen the real-time transaction data receiving interface and gradually resume processing the production real-time data stream, thus seamlessly connecting and restoring the entire parallel verification system to a fully synchronized online working state with production. Throughout the online-offline switchover process, the system records detailed operational logs to support subsequent analysis and auditing. This online-offline switchover technology provides robust fault tolerance and business continuity assurance for continuous verification under high TPS, significantly improving the stability and reliability of the entire migration verification process.

[0073] Figure 2 This is a schematic flowchart of a parallel verification method 20 according to one or more embodiments of this application.

[0074] In step 201, real-time transaction data from the production system is received.

[0075] In step 203, the flow count of real-time transaction data is obtained based on the asynchronous timing mechanism, and the size of the time window is dynamically adjusted based on the flow count.

[0076] In step 205, the status of the elastic scaling cache used to cache transaction data is monitored, and dynamic scaling is performed on it based on the monitoring results.

[0077] In step 207, the real-time transaction data is divided into ordered data batches using the adjusted time window.

[0078] In step 209, tests are executed in the test environment based on ordered data batches and test results are generated, while the operating metrics of the test environment are continuously monitored.

[0079] In step 211, the test results are verified using the corresponding transaction processing results from the production system, and when abnormal operating indicators are detected, a switch from online processing mode to offline processing mode is triggered.

[0080] In step 213, a switch from online processing mode to offline processing mode is performed. This step may include pausing the asynchronous tracking mechanism, shutting down the real-time data receiving interface, and performing batch testing and problem localization and repair based on historical transaction data read from the distributed file system, thereby maintaining the continuity of verification work in abnormal situations.

[0081] In step 215, once the operational metrics are detected to have recovered and remained stable, the process switches back from offline processing mode to online processing mode. This step may include synchronizing the test results and system status generated during the offline period to the online environment and performing consistency verification, then restarting the asynchronous tracking mechanism and reopening the real-time data receiving interface, ultimately restoring the entire process of real-time synchronization verification.

[0082] Figure 3 This is a schematic block diagram of a computer device 30 according to one or more embodiments of this application. The computer device 30 includes a memory 310, a processor 320, and a computer program 330 stored on the memory 310 and executable on the processor 320, the execution of which causes the methods 10 or 20 described above to be performed.

[0083] Furthermore, as described above, this application can also be implemented as a computer-readable storage medium storing a program for executing the process described in method 10 or 20 above. Here, various types of computer-readable storage media can be used, such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memories (e.g., ROM, non-volatile memory, etc.), and tapes (e.g., magnetic tape, cassette tape, etc.).

[0084] This application can also be implemented as a computer program product comprising a computer program that, when executed by a processor, performs the steps of method 10 or 20 as described above.

[0085] Where applicable, the various embodiments provided in this application may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be combined into composite components comprising software, hardware, and / or both. Where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be divided into sub-components comprising software, hardware, or both. Additionally, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0086] The software (such as program code and / or data) according to this application may be stored on one or more computer-readable storage media. It is also contemplated that the software identified herein may be implemented using one or more networked and / or otherwise general-purpose or special-purpose computers and / or computer systems. Where applicable, the order of the various steps described herein may be changed, combined into compound steps, and / or divided into sub-steps to provide the features described herein.

[0087] The embodiments and examples presented herein are provided to best illustrate embodiments of this application and its particular applications, thereby enabling those skilled in the art to implement and use this application. However, those skilled in the art will understand that the above description and examples are provided for ease of illustration and example only. The descriptions presented are not intended to cover all aspects of this application or to limit this application to the precise forms disclosed.

Claims

1. A parallel verification method for system migration, characterized in that, Includes the following steps: Receive real-time transaction data from the production system; The flow count of the real-time transaction data is obtained based on an asynchronous timing mechanism, wherein the flow count is obtained by synchronously updating the counters of the current time window and the previous time window; Based on the traffic count, the size of the time window is dynamically adjusted; The real-time transaction data is divided into ordered data batches using the adjusted time window; Based on the ordered data batches, the corresponding tests are executed in the test environment and test results are generated. as well as The test results are verified using the corresponding transaction processing results from the production system.

2. The method according to claim 1, wherein, The asynchronous timing mechanism is executed by a timing counting coroutine independent of the main data processing flow. The timing counting coroutine updates the counter asynchronously in response to the arrival event of each real-time transaction data.

3. The method according to claim 2, wherein, The method further includes: The execution state of the dot counting coroutine is saved in its context. When the dot counting coroutine is scheduled and switched, its execution state is restored using its context.

4. The method according to claim 2, wherein, The method further includes: In the callback function of the dot-counting coroutine, dot markers are set to track at least one of the function's start, termination, and exception events; and / or An independent stack space is allocated to the dot-counting coroutine, and the usage status of the stack space is monitored through the dot-counting mechanism.

5. The method according to claim 1, wherein, Synchronously updating the counters for the current time window and the previous time window includes: When the asynchronous timing mechanism receives a timing event, it increments the count value of the current time window and synchronously updates the count value of the previous time window based on a preset smoothing algorithm.

6. The method according to claim 1, wherein, The method further includes: Monitor the status of the elastic scaling cache used to cache transaction data, including calculating one or more of the following: cache hit rate, real-time access frequency, and cache space utilization. Based on the monitoring results, the elastic scaling cache is dynamically expanded or reduced.

7. The method according to claim 6, wherein, The real-time access frequency is calculated using the following sliding time window algorithm: Where F(t) is the access frequency at time t, Ci is the number of times the cache is accessed in the i-th time slice, n is the total number of time slices in the time window, and T is the total length of the time window.

8. The method according to claim 6, wherein, Based on monitoring results, dynamic scaling of the elastic scaling cache includes: When the cache space utilization rate is higher than its expansion threshold, and at least one of the cache hit rate and the access frequency is also higher than their respective expansion thresholds, the cache gradient expansion operation is triggered. When the cache space utilization rate is lower than its shrinkage threshold, and at least one of the cache hit rate and the access frequency is also lower than its respective shrinkage threshold, the cache gradient shrinkage operation is triggered.

9. The method according to claim 8, wherein, The gradient expansion or the gradient shrinkage operation continues until the cache space utilization rate reaches a preset target range.

10. The method according to claim 1, wherein, The real-time transaction data is divided into ordered data batches using the adjusted time window, including: Using the start and end times of the time window as boundaries, all transaction data falling within the same window are aggregated into a logically continuous and ordered data batch, with different batches arranged according to the order of the time window.

11. The method according to claim 1, wherein, The method further includes: Monitor the operational metrics of the test environment, including system throughput, request response time, and business processing error rate; When at least one operational indicator is detected to be outside its preset normal range, the verification process is deemed abnormal. In response to an anomaly detection, switch from online processing mode to offline processing mode.

12. The method according to claim 11, wherein, Switching from online processing mode to offline processing mode includes: Suspend the asynchronous tracking mechanism and close the interface for receiving real-time transaction data; A batch testing process is executed based on historical transaction data read from a distributed file system.

13. The method according to claim 11, wherein, The method further includes: When at least one operational metric is detected to be outside its preset normal range, the status and system context of the data batch for which the test is not yet completed are recorded and persistently stored.

14. The method according to claim 11, wherein, The method further includes: Once at least one operational indicator is detected to have returned to the preset normal range and remained stable for a preset duration, the system switches back from the offline processing mode to the online processing mode.

15. The method according to claim 14, wherein, Switching back to the online processing mode includes: The test results generated in the offline processing mode will be synchronized with the system status to the online environment, and data consistency verification will be completed. Restart the asynchronous tracking mechanism; and Open the interface for receiving the real-time transaction data and resume data stream processing.

16. The method according to claim 1, wherein, Verifying the test results using the corresponding transaction processing results from the production system includes: The test results corresponding to the same data batch are compared item by item with the transaction processing results of the production system, and the verification is determined based on the consistency rate of the comparison results.

17. A computer device, wherein, It includes: a memory; a processor; and a computer program stored in the memory and executable on the processor, the execution of which causes the following operations: Receive real-time transaction data from the production system; The flow count of the real-time transaction data is obtained based on an asynchronous timing mechanism, wherein the flow count is obtained by synchronously updating the counters of the current time window and the previous time window; Based on the traffic count, the size of the time window is dynamically adjusted; The real-time transaction data is divided into ordered data batches using the adjusted time window; Based on the ordered data batches, the corresponding tests are executed in the test environment and test results are generated. as well as The test results are verified using the corresponding transaction processing results from the production system.

18. The computer device according to claim 17, wherein, The execution of the computer program results in the following operations: The asynchronous timing mechanism is executed by a timing counting coroutine independent of the main data processing flow. The timing counting coroutine updates the counter asynchronously in response to the arrival event of each real-time transaction data.

19. The computer device according to claim 18, wherein, The execution of the computer program also results in the following operations: The execution state of the dot counting coroutine is saved in its context. When the dot counting coroutine is scheduled and switched, its execution state is restored using its context.

20. The computer device according to claim 18, wherein, The execution of the computer program also results in the following operations: In the callback function of the dot-counting coroutine, dot markers are set to track at least one of the function's start, termination, and exception events; and / or An independent stack space is allocated to the dot-counting coroutine, and the usage status of the stack space is monitored through the dot-counting mechanism.

21. The computer device according to claim 17, wherein, Synchronously updating the counters for the current time window and the previous time window includes: When the asynchronous timing mechanism receives a timing event, it increments the count value of the current time window and synchronously updates the count value of the previous time window based on a preset smoothing algorithm.

22. The computer device according to claim 17, wherein, The execution of the computer program also results in the following operations: Monitor the status of the elastic scaling cache used to cache transaction data, including calculating one or more of the following: cache hit rate, real-time access frequency, and cache space utilization. Based on the monitoring results, the elastic scaling cache is dynamically expanded or reduced.

23. The computer device according to claim 22, wherein, The real-time access frequency is calculated using the following sliding time window algorithm: Where F(t) is the access frequency at time t, Ci is the number of times the cache is accessed in the i-th time slice, n is the total number of time slices in the time window, and T is the total length of the time window.

24. The computer device according to claim 22, wherein, Based on monitoring results, dynamic scaling of the elastic scaling cache includes: When the cache space utilization rate is higher than its expansion threshold, and at least one of the cache hit rate and the access frequency is also higher than their respective expansion thresholds, the cache gradient expansion operation is triggered. When the cache space utilization rate is lower than its shrinkage threshold, and at least one of the cache hit rate and the access frequency is also lower than its respective shrinkage threshold, the cache gradient shrinkage operation is triggered.

25. The computer device according to claim 24, wherein, The gradient expansion or the gradient shrinkage operation continues until the cache space utilization rate reaches a preset target range.

26. The computer device according to claim 17, wherein, The real-time transaction data is divided into ordered data batches using the adjusted time window, including: Using the start and end times of the time window as boundaries, all transaction data falling within the same window are aggregated into a logically continuous and ordered data batch, with different batches arranged according to the order of the time window.

27. The computer device according to claim 17, wherein, The execution of the computer program also results in the following operations: Monitor the operational metrics of the test environment, including system throughput, request response time, and business processing error rate; When at least one operational indicator is detected to be outside its preset normal range, the verification process is deemed abnormal. In response to an anomaly detection, switch from online processing mode to offline processing mode.

28. The computer device according to claim 27, wherein, Switching from online processing mode to offline processing mode includes: Suspend the asynchronous tracking mechanism and close the interface for receiving real-time transaction data; A batch testing process is executed based on historical transaction data read from a distributed file system.

29. The computer device according to claim 27, wherein, The execution of the computer program also results in the following operations: When at least one operational metric is detected to be outside its preset normal range, the status and system context of the data batch for which the test is not yet completed are recorded and persistently stored.

30. The computer device according to claim 27, wherein, The execution of the computer program also results in the following operations: Once at least one operational indicator is detected to have returned to the preset normal range and remained stable for a preset duration, the system switches back from the offline processing mode to the online processing mode.

31. The computer device according to claim 30, wherein, Switching back to the online processing mode includes: The test results generated in the offline processing mode will be synchronized with the system status to the online environment, and data consistency verification will be completed. Restart the asynchronous tracking mechanism; and Open the interface for receiving the real-time transaction data and resume data stream processing.

32. The computer device according to claim 17, wherein, Verifying the test results using the corresponding transaction processing results from the production system includes: The test results corresponding to the same data batch are compared item by item with the transaction processing results of the production system, and the verification is determined based on the consistency rate of the comparison results.

33. A computer-readable storage medium, wherein, The computer-readable storage medium includes instructions that, when executed, perform the method according to any one of claims 1-16.

34. A computer program product, wherein, The computer program product includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1-16.

Images