State data capturing method and device and computer program product

Abstract

The invention discloses a state data capturing method and device and a computer program product. The method comprises the following steps: acquiring a memory snapshot and a transaction log of a host system, adding a first time sequence stamp to the memory snapshot, and adding a second time sequence stamp to the transaction log; collecting a container state and a database log of the distributed system, adding a third time sequence stamp to the container state, and adding a fourth time sequence stamp to the database transaction log; matching the first time sequence stamp, the second time sequence stamp, the third time sequence stamp and the fourth time sequence stamp through a sliding window algorithm to obtain successfully matched state data; and constructing a state chain based on the successfully matched state data, verifying the state chain, and determining that the state data is successfully captured under the condition that the verification of the state chain is passed. Through the method and the device, the problem of inconsistent state data during parallel operation of the host system and the distributed system in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more specifically, to a state data capture method, apparatus, and computer program product. Background Technology

[0002] Against the backdrop of digital transformation, financial institutions, telecom operators, and other large organizations are increasingly adopting hybrid architectures, where primary architecture systems (such as mainframes) coexist with distributed architectures (such as container clouds and microservice clusters) to meet the diverse and complex needs of their businesses. However, capturing and synchronizing cross-architectural states has become a major challenge in hybrid architecture environments.

[0003] In related technologies, cross-architecture state capture is mainly divided into three categories: host-side one-way state capture, which ignores the operational status of the distributed system, leading to inconsistencies between the host state and the distributed system state during fault recovery (rollback), increasing the risk of rollback, especially in scenarios requiring precise coordination between the states of both ends. Distributed-side one-way state capture focuses on monitoring the state of container instances and collecting database transaction logs. However, this method does not capture the transaction context information on the host side, causing a disconnect between the business logic of the host and the data state of the distributed system, affecting the overall recovery capability of the system. Asynchronous batch state synchronization uses periodic scheduled tasks (such as executing once per hour) to simultaneously collect state snapshots of both the host and distributed ends in order to achieve cross-architecture state synchronization. However, this method is limited by low timing accuracy (usually at the second level), making it difficult to capture state changes in high-frequency trading environments, especially those transactions that differ by only a few milliseconds or even microseconds. This loss of detail disrupts the integrity of the business processing chain, increasing the difficulty of fault location and rollback.

[0004] There is currently no effective solution to the problem of inconsistent state data between host systems and distributed systems during parallel operation in related technologies. Summary of the Invention

[0005] The main objective of this application is to provide a state data capture method, apparatus, and computer program product to solve the problem of inconsistent state data during the parallel operation of host systems and distributed systems in related technologies.

[0006] To achieve the above objectives, according to one aspect of this application, a state data capture method is provided. The method includes: collecting memory snapshots and transaction logs of a host system; adding a first time stamp to the memory snapshot and a second time stamp to the transaction logs, wherein the memory snapshot and transaction logs are correlated by transaction numbers; collecting container states and database logs of a distributed system; adding a third time stamp to the container states and a fourth time stamp to the database transaction logs, wherein the distributed system and the host system are used to process the same business, and the container states and database logs are correlated by service call chain numbers; matching the first, second, third, and fourth time stamps using a sliding window algorithm to obtain successfully matched state data, wherein the state data includes at least one of the following: memory snapshots, transaction logs, container states, and database logs; constructing a state chain based on the successfully matched state data, and verifying the state chain; if the state chain verification passes, determining that the state data capture is successful.

[0007] Optionally, matching the first, second, third, and fourth time stamps using the sliding window algorithm includes: determining a filtering window based on the host system's time stamps, wherein the host system's time stamps include either the first or second time stamp, and the filtering window contains all times within the target time period; determining whether a time in the third time stamp belongs to the filtering window, and determining whether a time in the fourth time stamp belongs to the filtering window; if a time in the third time stamp does not belong to the filtering window, determining that the container state and the host system's state data do not match; if a time in the fourth time stamp does not belong to the filtering window, determining that the database log and the host system's state data do not match; wherein the host system's state data includes at least one of the following: memory snapshots and transaction logs; if a time in the third time stamp belongs to the filtering window, determining the container state as the first candidate data; if a time in the fourth time stamp belongs to the filtering window, determining the database log as the second candidate data; determining at least one of the first and second candidate data as candidate data; and matching the candidate data with the host system's state data.

[0008] Optionally, determining the filtering window based on the time stamp of the host system includes: determining an initial sliding window, determining the earliest time in the first or second time stamp as the intermediate time; calculating the difference between the intermediate time and the length of the initial sliding window to obtain the start time, calculating the sum of the lengths of the intermediate time and the initial sliding window to obtain the end time; determining the time period between the start time and the end time as the target time period, and determining the target time period as the filtering window.

[0009] Optionally, determining the initial sliding window includes: obtaining the service load of the host system and determining whether the service load is greater than or equal to a first load threshold; if the service load is greater than or equal to the first load threshold, determining a first duration as the initial sliding window; if the service load is less than the first load threshold, determining whether the service load is greater than or equal to a second load threshold; if the service load is greater than or equal to the second load threshold, determining a second duration as the initial sliding window, wherein the second duration is less than the first duration; if the service load is less than the second load threshold, determining a third duration as the initial sliding window, wherein the third duration is less than the second duration.

[0010] Optionally, matching candidate data with the host system's state data includes: calculating the difference between the time and the intermediate time in the timestamp corresponding to the candidate data; if the difference is less than or equal to a difference threshold, determining that the candidate data and the host system's state data are successfully matched; if the difference is greater than the difference threshold, determining whether there is a correlation between the service call chain number and the transaction number of the candidate data, wherein the service call chain number contains transaction numbers of multiple transactions; if there is a correlation between the service call chain number and the transaction number, determining that the candidate data and the host system's state data are successfully matched; if there is no correlation between the service call chain number and the transaction number, determining that the candidate data and the host system's state data are not matched.

[0011] Optionally, constructing a state chain based on successfully matched state data includes: extracting the timestamp of each type of data from the successfully matched state data to obtain multiple timestamps; starting from the smallest timestamp among the multiple timestamps, concatenating the successfully matched state data in parallel according to time order to obtain a state chain.

[0012] Optionally, verifying the state chain includes: if the state chain does not contain the first state data of the host system corresponding to the transaction number, or the second state data of the distributed system corresponding to the transaction number, determining that the state data corresponding to the transaction number is missing, and determining that the state chain verification fails; if the state chain contains the first state data of the host system corresponding to the transaction number and the second state data of the distributed system corresponding to the transaction number, determining that the state data corresponding to the transaction number is not missing, and performing data consistency verification on the state chain; if the data consistency verification of the state chain fails, determining that the state chain verification fails; if the data consistency verification of the state chain succeeds, determining that the state chain verification passes.

[0013] Optionally, data consistency verification of the state chain includes: if the state chain contains a memory snapshot and a database log, calculating a first hash value of the target variable in the memory snapshot and calculating a second hash value of the data corresponding to the target variable in the database log; if the first hash value and the second hash value are the same, determining that the data consistency verification of the state chain is successful; if the first hash value and the second hash value are different, determining that the data consistency verification of the state chain fails.

[0014] To achieve the above objectives, according to another aspect of this application, a state data capture device is provided. The device includes: a first acquisition unit, configured to acquire memory snapshots and transaction logs of a host system, add a first time stamp to the memory snapshot, and add a second time stamp to the transaction log, wherein the memory snapshot and transaction log are correlated through transaction numbers; a second acquisition unit, configured to acquire container states and database logs of a distributed system, add a third time stamp to the container states, and add a fourth time stamp to the database transaction logs, wherein the distributed system and the host system are used to process the same business, and the container states and database logs are correlated through service call chain numbers; a matching unit, configured to match the first, second, third, and fourth time stamps using a sliding window algorithm to obtain successfully matched state data, wherein the state data includes at least one of the following: memory snapshot, transaction log, container state, and database log; and a verification unit, configured to construct a state chain based on the successfully matched state data and verify the state chain, determining that state data capture is successful if the state chain verification is successful.

[0015] In this embodiment, memory snapshots and transaction logs of the host system are collected. A first time stamp is added to the memory snapshot, and a second time stamp is added to the transaction log. The memory snapshot and transaction log are associated with each other through transaction numbers. Container status and database logs of the distributed system are collected. A third time stamp is added to the container status, and a fourth time stamp is added to the database transaction log. The distributed system and the host system are used to process the same business, and the container status and database log are associated with each other through service call chain numbers. The first, second, third, and fourth time stamps are matched using a sliding window algorithm to obtain successfully matched status data. The status data includes at least one of the following: memory snapshot, transaction log, container status, and database log. A status chain is constructed based on the successfully matched status data, and the status chain is verified. If the status chain verification is successful, the method of successful status data capture is determined. Nanosecond-level time stamp mapping ensures data consistency between the host and distributed ends during rollback. The construction of the dual-end status chain restores the complete business processing chain, supporting fault location and accurate identification of rollback nodes. State chain verification avoids split failures and significantly reduces the probability of rollback failure. Nanosecond-level timing accuracy and the sliding window algorithm can adapt to high-frequency trading scenarios of more than 100,000 transactions per second, achieving the goal of overcoming state fragmentation. This ensures the consistency of state data between the host system and the distributed system during rollback, thereby solving the technical problem of inconsistent state data during parallel operation of the host system and the distributed system. Attached Figure Description

[0016] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a state data capture method is shown.

[0018] Figure 2 This is a flowchart of a state data capture method provided according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of the construction state chain provided according to an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of a status data capture system provided according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of a status data capture device provided according to an embodiment of this application;

[0022] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0026] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0027] Cross-architecture state capture: The technical process of synchronously collecting runtime state data of host systems (such as mainframes and minicomputers) and distributed systems (such as container clouds and microservice clusters) when they run in parallel.

[0028] Time stamp mapping: A technical means of establishing causal relationships between discrete state data (such as memory snapshots and transaction logs) on the host side and the distributed side through a unified high-precision timestamp (nanosecond level).

[0029] Dual-end state chain: A time-series associated data set consisting of "memory snapshot + transaction log" on the host side and "container state + database transaction log" on the distributed side, which achieves accurate tracing of the state at both ends through time stamp mapping.

[0030] Memory snapshot: An incremental copy of the application process's memory space by the host system at a specific point in time. It only records the memory changes since the last snapshot (such as changes to the page table markers), including runtime states such as the program counter, registers, and stack pointer.

[0031] Container status: Metadata of container instances in a distributed system at runtime, including CPU (Central Processing Unit) / memory utilization, network connection count, mounted volume data, etc., reflecting the real-time health status of the container.

[0032] Sliding window algorithm: A basic algorithm for time series data matching. It maintains a fixed-size time window that slides along the time axis to find matching items within the window that meet association conditions (such as consistent association IDs and time series difference ≤ threshold). It is suitable for accurate alignment of state data across architectures.

[0033] Example 1

[0034] According to an embodiment of this application, a method embodiment for capturing state data is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a state data capture method is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, processing devices such as MCU (Microcontroller Unit) or FPGA (Field-Programmable Gate Array), memory 104 for storing data, and transmission device 106 for communication functions. In addition, it may also include: a display, input / output interfaces (I / O interfaces), a USB (Universal Serial Bus) port (which may be included as one of the ports of a BUS (Business Bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0036] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the state data capture method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned state data capture method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0038] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0039] The display may be, for example, a touchscreen LCD display that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0040] In the above operating environment, this application provides a state data capture method. Figure 2 This is a flowchart of a state data capture method provided according to an embodiment of this application, such as... Figure 2 As shown, the method includes:

[0041] Step S201: Collect memory snapshots and transaction logs of the host system, add a first time stamp to the memory snapshot, and add a second time stamp to the transaction log. The memory snapshot and the transaction log are linked to each other through transaction numbers.

[0042] In step S201, during the execution of the host application process, memory snapshots and transaction logs are synchronously collected using memory dumping technology and database log hooks, and a nanosecond-level timestamp is appended to each data entry. This can be achieved by intercepting memory access events of the application process based on the operating system kernel module, triggering incremental memory snapshots (recording only changed areas), and adding a first timestamp; real-time reading of transaction logs via a database plugin, and adding a timestamp indicating the completion time of the write operation to each log entry, i.e., a second timestamp; and association of the memory snapshots and transaction logs using the same transaction ID (Identifier), i.e., the transaction number, and storing them in the host state cache queue.

[0043] For example, when the host executes a transaction operation of "deducting funds from account A → adding funds to account B": the memory dump module captures the balance pointers of accounts A and B in the application process's memory at the beginning of the transaction; the database plugin records the transaction log and attaches a time stamp (e.g., T1=16:00:00.123456789ns, T2=16:00:00.123456795ns) at the COMMIT (the control statement in the database that formally ends a transaction) moments of deduction (UPDATE account A) and addition (UPDATE account B); the memory snapshot and the transaction log are associated through the transaction ID (TXN-001) and stored in the host state cache queue, waiting to be mapped with the distributed data.

[0044] Step S202: Collect the container status and database logs of the distributed system, add a third time stamp to the container status, and add a fourth time stamp to the database transaction logs. The distributed system and the host system are used to process the same business, and the container status and database logs are related to each other through the service call chain number.

[0045] In step S202, during the operation of the containerized service and database, container status and database logs are synchronously collected through a container monitoring agent and a database transaction tracker, and a nanosecond-level timestamp is appended to each data entry. A lightweight agent can be deployed on the container management cluster node to monitor the container's CPU / memory usage, network connection count, and other statuses, sampling every 100μs and appending a third timestamp; transaction logs are captured through a database driver (such as MySQL's binlog connector), parsing out the transaction ID-operation type-data change triplet and appending a fourth timestamp indicating operation completion; the container status and transaction logs are associated by service call chain ID, i.e., service call chain number, and stored in a distributed state cache queue.

[0046] For example, when the distributed end executes database update operations for accounts A and B in the aforementioned transfer transaction: the lightweight agent samples the container's CPU utilization (e.g., increasing from 10% to 30%) and memory usage (e.g., increasing by 5MB) every 100μs during the container's request processing, and appends a timestamp (e.g., T1=16:00:00.123456800ns, T2=16:00:00.123556800ns); the database transaction tracker captures the binlog event "UPDATE account A SET balance=balance-100", parses out the transaction ID (TXN-001), operation type (deduction), and changed data (balance decreased by 100), and appends a timestamp (T2=16:00:00.123456795ns); the container state and transaction log are associated through the service call chain ID (TRACE-001) and stored in the distributed state cache queue.

[0047] Step S203: The first time stamp, the second time stamp, the third time stamp, and the fourth time stamp are matched using a sliding window algorithm to obtain successfully matched status data. The status data includes at least one of the following: memory snapshot, transaction log, container status, and database log.

[0048] In step S203, the state data of the host and distributed ends are time-aligned using a unified time stamp to construct a dual-end state chain containing the complete transaction context. A dual-end state data index table is designed, containing fields such as time stamp, data type (memory snapshot / transaction log / container state / database log), and association ID (transaction ID / call chain ID). Distributed database hash partitioning storage is used to ensure that data within the same time window is distributed across the same storage node. Based on the host-end time stamp, a range query (T±50ns) is used to locate candidate records within the overlapping time interval of the distributed end, laying the foundation for subsequent sliding window matching. Records in the host-end cache queue (time stamp T=16:00:00.123456795ns, transaction ID=TXN-001, type=memory snapshot) are located within the same overlapping time interval through a time stamp range query (T±50ns) in the index table. Candidate records within this window on the distributed end include:

[0049] Record A: Time stamp T_dist_A=16:00:00.123456790ns, Transaction ID=TXN-001, Type=Database log;

[0050] Record B: Time stamp T_dist_B=16:00:00.123456800ns, call chain ID=TRACE-001, type=container state.

[0051] Step S204: Construct a state chain based on the successfully matched state data, and verify the state chain. If the state chain verification is successful, determine that the state data was successfully captured.

[0052] In step S204, based on the timestamp mapping results, successfully matching state data records are filtered out, including memory snapshots and transaction logs on the host side, and container states and database transaction logs on the distributed side. All successfully matching state data are sorted according to their timestamps to ensure the data is arranged in true chronological order, which is a prerequisite for constructing an ordered state chain. A state chain ID is generated, with the format CHAIN-[Transaction ID]-[Start Timestamp], for example, CHAIN-TXN-001-160000123456790. The state chain ID is generated based on the earliest timestamp and the common transaction ID in the matching data, forming a globally unique identifier.

[0053] State chain verification includes integrity verification: checking for any missing state data at either end of the state chain related to a specific transaction ID. If a missing value is found, a data re-sampling mechanism is triggered, attempting up to three times to ensure all relevant state data is captured. Verifying the completeness of all state data in the state chain, without any missing critical states, is the most basic requirement for state chain construction. Consistency verification: comparing the values ​​of key variables (such as account balances) in the state chain in the host-side memory snapshot with those in the distributed database logs. Hash value verification ensures consistency between host-side variable states and distributed-side data changes. If the hash values ​​do not match, the state chain is marked as "awaiting manual verification." If the state chain has neither missing data nor consistency issues, it can be considered successfully constructed, and state data capture is successful.

[0054] The state data capture method provided in this application collects memory snapshots and transaction logs from the host system, adds a first time stamp to the memory snapshot, and a second time stamp to the transaction log, wherein the memory snapshot and transaction log are correlated by transaction number; it also collects container status and database logs from the distributed system, adds a third time stamp to the container status, and a fourth time stamp to the database transaction log, wherein the distributed system and the host system are used to process the same business, and the container status and database log are correlated by service call chain number; it matches the first, second, third, and fourth time stamps using a sliding window algorithm to obtain successfully matched state data, wherein the state data includes at least one of the following: memory snapshot, transaction log, container status, and database log; it constructs a state chain based on the successfully matched state data, and verifies the state chain; if the state chain verification is successful, it is determined that the state data capture is successful, and nanosecond-level time stamp mapping ensures data consistency between the host and distributed ends during rollback. The construction of the dual-end state chain restores the complete business processing link, supporting fault location and accurate identification of rollback nodes. State chain verification avoids split failures and significantly reduces the probability of rollback failure. Nanosecond-level timing accuracy and the sliding window algorithm can adapt to high-frequency trading scenarios of more than 100,000 transactions per second, achieving the goal of overcoming state fragmentation. This ensures the consistency of state data between the host system and the distributed system during rollback, thereby solving the technical problem of inconsistent state data during parallel operation of the host system and the distributed system.

[0055] Aligning state data through timestamp matching: Optionally, in the state data capture method provided in this application embodiment, matching the first, second, third, and fourth timestamps using a sliding window algorithm includes: determining a filtering window based on the timestamp of the host system, wherein the timestamp of the host system includes either the first or second timestamp, and the filtering window contains all times within the target time period; determining whether the timestamp in the third timestamp belong to the filtering window, and determining whether the timestamp in the fourth timestamp belong to the filtering window; if the timestamp in the third timestamp does not belong to the filtering window, determining that the container state and the state data of the host system fail to match; if the timestamp in the fourth timestamp does not belong to the filtering window, determining that the database log and the state data of the host system fail to match, wherein the state data of the host system includes at least one of the following: memory snapshot and transaction log; if the timestamp in the third timestamp belongs to the filtering window, determining the container state as the first candidate data; if the timestamp in the fourth timestamp belongs to the filtering window, determining the database log as the second candidate data; determining at least one of the first and second candidate data as candidate data; and matching the candidate data with the state data of the host system.

[0056] In some embodiments, a sliding window algorithm is used to precisely match data within overlapping time intervals. Candidate records whose timestamps fall within the window are queried in the distributed index table, with priority given to records with consistent associated IDs (e.g., if the host transaction ID is TXN-001, records with the distributed transaction ID TXN-001 are matched first). A timestamp from the host system is selected as the baseline (either the first or second timestamp), and the latest memory snapshot or transaction log timestamp is chosen. An initial window size is set, for example, a default of 1 millisecond, with a window coverage of [TW, T+W], where T is the selected timestamp and W is the window size. All records whose timestamps fall within the window are queried in the distributed system's index table, such as the third and fourth timestamps. It is determined whether the third timestamp (container status timestamp) and the fourth timestamp (database transaction log timestamp) belong to the filtering window. If the timestamp in the third timestamp is not within the filtering window, the container status is considered to have failed to match the host system's status data. Similarly, if the timestamp in the fourth timestamp is not within the filtering window, the database log is considered to have failed to match the host system's status data.

[0057] For the timestamps that fall within the filtering window, the corresponding records are determined (the container status record corresponding to the third timestamp is determined as the first candidate data, and the database log record corresponding to the fourth timestamp is determined as the second candidate data). Further filtering is performed based on the transaction ID or service call chain ID, and candidate data with the same transaction ID or service call chain ID as the host-side status data (memory snapshot or transaction log) are determined as the final matching objects.

[0058] This embodiment ensures high-precision matching of state data at both ends through nanosecond-level time stamp mapping, avoiding the problem of state fragmentation. Using a sliding window algorithm for time stamp matching enables the construction of a complete and accurate two-end state chain, providing a solid data foundation for subsequent intelligent fault location and rapid rollback.

[0059] Optionally, in the state data capture method provided in this application embodiment, determining the filtering window based on the time stamp of the host system includes: determining an initial sliding window, determining the earliest time in the first time stamp or the second time stamp as the intermediate time; calculating the difference between the intermediate time and the length of the initial sliding window to obtain the start time, calculating the sum of the lengths of the intermediate time and the initial sliding window to obtain the end time; determining the time period between the start time and the end time as the target time period, and determining the target time period as the filtering window.

[0060] In some embodiments, the intermediate time is determined based on the earliest of the first time stamp (e.g., the time stamp of a memory snapshot) or the second time stamp (e.g., the time stamp of a transaction log) of the host system. The most recent host system state data time stamp is selected as the reference point. The length (W) of the initial sliding window is determined, which is preset according to business requirements and reflects the system's tolerance for time differences in matching data. The time period between the start and end times forms a filtering window used to capture distributed system state data that is close in time to the host system state data. The target time period is the time range of the filtering window, which is defined by the start and end times. The selection of the target time period directly affects the matching efficiency and accuracy of the state data.

[0061] For example, based on the host-side timestamp, set the initial window size W (default 1ms), and the window coverage range is [TW, T+W] (e.g., when T=16:00:00.123456795ns, the window covers 16:00:00.122456795ns to 16:00:00.124456795ns).

[0062] This embodiment captures distributed system status data that is close to the time of the host system status data by defining a filtering window.

[0063] The window size is dynamically adjusted according to the service load. Optionally, in the state data capture method provided in this application embodiment, determining the initial sliding window includes: obtaining the service load of the host system and determining whether the service load is greater than or equal to a first load threshold; if the service load is greater than or equal to the first load threshold, determining a first duration as the initial sliding window; if the service load is less than the first load threshold, determining whether the service load is greater than or equal to a second load threshold; if the service load is greater than or equal to the second load threshold, determining a second duration as the initial sliding window, wherein the second duration is less than the first duration; if the service load is less than the second load threshold, determining a third duration as the initial sliding window, wherein the third duration is less than the second duration.

[0064] In some embodiments, the current workload of the host system is monitored or acquired. This includes metrics such as CPU utilization, memory consumption, network traffic, or the number of transactions processed. If the workload is greater than or equal to a first load threshold, a larger window length (first duration) is selected as the initial sliding window. This helps ensure that no critical state data is missed during high-concurrency transactions, but may increase the complexity of data processing. If the workload is less than the first load threshold but greater than or equal to a second load threshold, a medium window length (second duration) is selected as the initial sliding window. The second duration is shorter than the first duration, which reduces the consumption of computing resources while ensuring matching efficiency. If the workload is less than the second load threshold, a smaller window length (third duration) is selected as the initial sliding window. The third duration is shorter than the second duration, which is suitable for environments with low business processing pressure, such as nighttime batch processing. In this case, the smaller window can accurately match state data while reducing system operating overhead.

[0065] For example, in low-load scenarios (such as nighttime batch processing), the window is reduced to 0.5ms to reduce computational redundancy; in high-load scenarios (such as peak transaction periods), the window is expanded to 2ms to avoid matching failures.

[0066] This embodiment automatically adjusts the size of the sliding window based on the current workload, ensuring efficient and accurate matching of status data under different workloads. Under low load, the system uses a smaller window to reduce unnecessary data processing and computational resource consumption; under high load, a larger window is used to increase the matching range and avoid data loss or matching failures due to an excessively small window.

[0067] After determining the candidate data, matching is performed based on the time stamp difference and the associated number. Optionally, in the state data capture method provided in this application embodiment, matching the candidate data with the state data of the host system includes: calculating the difference between the time and the intermediate time in the time stamp corresponding to the candidate data; if the difference is less than or equal to the difference threshold, it is determined that the candidate data and the state data of the host system are successfully matched; if the difference is greater than the difference threshold, it is determined whether there is an association between the service call chain number and the transaction number of the candidate data, wherein there are transaction numbers of multiple transactions in the service call chain number; if there is an association between the service call chain number and the transaction number, it is determined that the candidate data and the state data of the host system are successfully matched; if there is no association between the service call chain number and the transaction number, it is determined that the candidate data and the state data of the host system are unmatched.

[0068] In some embodiments, the distributed index table is queried for candidate records whose timestamps fall within the window. Records with the same associated ID are prioritized (e.g., if the host transaction ID is TXN-001, the distributed transaction ID is prioritized for matching). The timestamp difference ΔT between the candidate record and the host data is calculated, which is the difference between the time in the timestamp and the intermediate time. If ΔT ≤ the difference threshold τ (default 50ns), it is considered a successful match. If the associated ID is the same but ΔT slightly exceeds τ (e.g., 55ns), it is still considered a successful match (ensuring that the state of the same transaction is not split).

[0069] For example, the host-side memory snapshot (T=16:00:00.123456795ns, TXN-001) matches successfully with the distributed record A (T_dist_A=16:00:00.123456790ns, TXN-001) with a ΔT=5ns; it also matches successfully with the record B (T_dist_B=16:00:00.123456800ns, TRACE-001) with a ΔT=5ns and associated with the call chain ID.

[0070] This embodiment ensures the temporal accuracy of the matched data through difference threshold matching, avoiding mismatches of irrelevant data. The service call chain and transaction number association matching mechanism takes into account the slight deviation of time stamps in a high-frequency trading environment, increasing the flexibility of matching and avoiding the omission of important data.

[0071] The state chain is obtained by splicing together the timestamps in chronological order. Optionally, in the state data capture method provided in this application embodiment, constructing a state chain based on the successfully matched state data includes: extracting the timestamp of each type of data from the successfully matched state data to obtain multiple timestamps; starting from the smallest timestamp among the multiple timestamps, splicing the successfully matched state data in parallel according to the time order to obtain the state chain.

[0072] In some embodiments, based on the successfully matched state data, a globally unique state chain is generated by concatenating them in chronological order and then performing consistency verification: starting from the smallest timestamp in the matching result, the state data (memory snapshot, transaction log, container state, database log) of the host end and the distributed end are associated and concatenated in chronological order to generate a state chain ID (format: CHAIN-[transaction ID]-[starting timestamp], such as CHAIN-TXN-001-160000123456790). Figure 3 This is a schematic diagram of the construction state chain provided according to the embodiments of this application, such as... Figure 3 As shown, the system is structured around a horizontal timeline, divided into three layers: "host-side data," "distributed-side data," and "dual-end state chain." All timestamps are in the nanosecond range. Data is associated between the host and distributed ends, with the time difference ΔT (each ≤ 50ns threshold) annotated to ensure matching validity.

[0073] Association rules: T2 (host transaction log) and T4 (distributed database log) are directly matched by "transaction ID=TXN-001+ΔT=0ns"; T1 (host memory snapshot) and T3 (distributed container state) are matched by "call chain ID=TRACE-001 associated with TXN-001+ΔT=5ns"; state chain integrity: contains two types of data from the host side and two types of data from the distributed side, with no missing data, which meets the definition of "dual-end state chain".

[0074] This embodiment constructs a state chain encompassing the entire business process, from memory operations on the host side to data changes on the distributed side, ensuring the integrity of the business process. The state chain verifies the consistency of state data between the host and distributed sides, preventing data fragmentation or inconsistency and guaranteeing overall system stability. The state chain provides clues for intelligent fault location and also provides the necessary data foundation for second-level rollback, enabling rapid problem location and precise rollback when system anomalies occur, improving the system's fault recovery capabilities.

[0075] Optionally, in the state data capture method provided in this application embodiment, verifying the state chain includes: if the state chain does not contain the first state data of the host system corresponding to the transaction number, or the second state data of the distributed system corresponding to the transaction number, determining that the state data corresponding to the transaction number is missing, and determining that the state chain verification fails; if the state chain contains the first state data of the host system corresponding to the transaction number and the second state data of the distributed system corresponding to the transaction number, determining that the state data corresponding to the transaction number is not missing, and performing data consistency verification on the state chain; if the data consistency verification of the state chain fails, determining that the state chain verification fails; if the data consistency verification of the state chain succeeds, determining that the state chain verification passes.

[0076] In some embodiments, it is checked whether the state chain contains all state data associated with a specific transaction ID or service call chain ID. If any host-side first state data (such as a memory snapshot) or distributed-side second state data (such as container state or database transaction log) associated with a transaction ID is missing from the state chain, the state chain verification is marked as failing. Missing data can be detected using the transaction ID or service call chain ID as an index, ensuring that the state chain covers all associated state data. After the integrity verification passes, data consistency verification is performed, comparing the logical consistency between the host-side state data and the distributed-side state data.

[0077] If the integrity or consistency verification of the state chain fails, the state chain needs to be marked as "pending manual verification" or "invalid," and a data re-sampling mechanism may be initiated to attempt to reacquire missing data or update inconsistent data. If the state chain verification passes, it means that the state data at both ends is complete and consistent. The state chain can be stored in a cross-architecture state storage engine for subsequent fault location and rollback operations.

[0078] This embodiment ensures the reliability of the cross-architecture state capture method through state chain verification. Integrity verification helps detect and prevent data fragmentation, preventing inconsistencies between the host and distributed states during rollback operations. Consistency verification ensures logical synchronization of state data, avoiding system failures or data anomalies caused by state inconsistencies. Effective state chain verification provides a precise state data foundation for second-level rollback, ensuring the efficiency and accuracy of rollback operations.

[0079] Optionally, in the state data capture method provided in this application embodiment, the data consistency verification of the state chain includes: when the state chain contains a memory snapshot and a database log, calculating a first hash value of the target variable in the memory snapshot and calculating a second hash value of the data corresponding to the target variable in the database log; if the first hash value and the second hash value are the same, determining that the data consistency verification of the state chain is successful; if the first hash value and the second hash value are different, determining that the data consistency verification of the state chain fails.

[0080] In some embodiments, key variables (such as account balance pointers) in the host-side memory snapshot are compared with data changes in the distributed-side database logs. Logical consistency is ensured through hash value verification. If the host-side hash value H_host and the distributed-side hash value H_dist are inconsistent, the status chain is marked as "pending manual verification".

[0081] For example, the state chain of a transfer transaction includes: Host-side: Memory snapshot (balance pointers for accounts A and B, T=16:00:00.123456795ns); Distributed-side: Database log (UPDATE account A, T=16:00:00.123456790ns), container state (CPU 30%, T=16:00:00.123556800ns). The state chain ID is CHAIN-TXN-001-160000123456790. Consistency verification: If the hash value of the host-side account A balance decreasing by 100 matches the hash value of the distributed-side database log, the state chain is marked as "valid" and stored in the cross-architecture state storage engine.

[0082] This embodiment ensures a high degree of consistency of state data at both ends in cross-architecture state capture by verifying the data consistency of the state chain, reducing the possibility of failures caused by data inconsistency and improving the overall stability and security of the system.

[0083] According to another embodiment of this application, a state data acquisition system is also provided. Figure 4 This is a schematic diagram of a status data capture system provided according to an embodiment of this application, such as... Figure 4 As shown, the system includes: a host system, a distributed system, a time-series mapping engine, and a cross-architecture state storage engine.

[0084] Specifically, the arrows indicate the data flow: the state data of the host / distributed system is first cached in a local queue, and then input into the time-series mapping engine; within the engine, candidate data is queried through an index table, matched by a sliding window, and then the state chain construction module generates a complete state chain, which is finally stored in the storage engine. The time-series mapping engine is the hub, connecting the two-end cache queues and the storage engine, and its internal sub-modules work together to complete the "query-match-build" logic.

[0085] During the runtime of the host application process, "memory snapshots" and "transaction logs" are synchronously collected using memory dump technology and database log hooks, with nanosecond-level timestamps appended to each data entry. During containerized service and database operation, "container status" and "database transaction logs" are synchronously collected using a container monitoring agent and database transaction tracker, with nanosecond-level timestamps appended to each data entry. The state data on the host and distributed ends are time-aligned using a unified timestamp, and a sliding window algorithm is used to precisely match data within overlapping time intervals, constructing a two-end state chain containing the complete transaction context. Based on the successfully matched state data, a globally unique state chain is generated by concatenating the data in chronological order, and consistency and integrity verifications are performed before storage in a cross-architecture state storage engine.

[0086] The state data capture system in this embodiment enables cross-architecture state synchronization: nanosecond-level time stamp mapping resolves state fragmentation, ensuring data consistency at both ends during rollback. The dual-end state chain restores the complete business context, supporting precise location of rollback nodes. State consistency avoids split failures, achieving a rollback success rate of ≥99.9%. Nanosecond precision and a sliding window match 100,000 transactions per second, meeting core financial requirements.

[0087] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0088] Example 2

[0089] This application also provides a state data capture device. It should be noted that the state data capture device of this application can be used to execute the state data capture method provided in this application. The state data capture device provided in this application is described below.

[0090] According to an embodiment of this application, an apparatus for implementing the above-described state data capture method is also provided. Figure 5 This is a schematic diagram of a status data capture device provided according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0091] The first acquisition unit 501 is used to acquire memory snapshots and transaction logs of the host system, add a first time stamp to the memory snapshot, and add a second time stamp to the transaction log. The memory snapshot and the transaction log are associated with each other through transaction numbers.

[0092] The second collection unit 502 is used to collect the container status and database logs of the distributed system, add a third time stamp to the container status, and add a fourth time stamp to the database transaction logs. The distributed system and the host system are used to process the same business, and the container status and database logs are associated with each other through the service call chain number.

[0093] The matching unit 503 is used to match the first time stamp, the second time stamp, the third time stamp and the fourth time stamp using a sliding window algorithm to obtain successfully matched status data, wherein the status data includes at least one of the following: memory snapshot, transaction log, container status and database log;

[0094] The verification unit 504 is used to construct a state chain based on the successfully matched state data and verify the state chain. If the state chain verification is successful, it is determined that the state data was successfully captured.

[0095] The state data capture device provided in this application embodiment includes a first acquisition unit 501 that acquires memory snapshots and transaction logs of the host system, adds a first time stamp to the memory snapshot, and adds a second time stamp to the transaction log, wherein the memory snapshot and transaction log are associated with each other through transaction numbers; a second acquisition unit 502 that acquires container status and database logs of the distributed system, adds a third time stamp to the container status, and adds a fourth time stamp to the database transaction log, wherein the distributed system and the host system are used to process the same business, and the container status and database log are associated with each other through service call chain numbers; a matching unit 503 that matches the first, second, third, and fourth time stamps using a sliding window algorithm to obtain successfully matched state data, wherein the state data includes at least one of the following: memory snapshot, transaction log, container status, and database log; and a verification unit 504 that constructs a state chain based on the successfully matched state data and verifies the state chain. If the state chain verification is successful, it is determined that the state data capture was successful. Nanosecond-level time stamp mapping ensures data consistency between the host and distributed ends during rollback. The construction of a dual-end state chain recreates the complete business processing chain, supporting fault location and accurate identification of rollback nodes. State chain verification avoids split failures, significantly reducing the probability of rollback failure. Nanosecond-level timing accuracy and the sliding window algorithm can adapt to high-frequency transaction scenarios of over 100,000 transactions per second, achieving the goal of overcoming state fragmentation. This ensures the consistency of state data between the host system and the distributed system during rollback, thereby solving the technical problem of inconsistent state data during parallel operation of the host system and the distributed system.

[0096] Optionally, in the state data capture device provided in this application embodiment, the matching unit 503 includes: a first determining module, used to determine a filtering window based on the timestamp of the host system, wherein the timestamp of the host system includes a first timestamp or a second timestamp, and the filtering window includes all times within the target time period; a first judging module, used to judge whether the time in the third timestamp belongs to the filtering window, and to judge whether the time in the fourth timestamp belongs to the filtering window; a second determining module, used to determine that the container state and the state data of the host system fail to match if the time in the third timestamp does not belong to the filtering window, and to determine that the database log and the state data of the host system fail to match if the time in the fourth timestamp does not belong to the filtering window, wherein the state data of the host system includes at least one of the following: memory snapshot and transaction log; a third determining module, used to determine the container state as the first candidate data if the time in the third timestamp belongs to the filtering window, and to determine the database log as the second candidate data if the time in the fourth timestamp belongs to the filtering window, and to determine at least one of the first candidate data and the second candidate data as candidate data, and to match the candidate data with the state data of the host system.

[0097] Optionally, in the state data capture device provided in this application embodiment, the first determining module includes: a first determining submodule, used to determine an initial sliding window and determine the earliest time in the first time stamp or the second time stamp as the intermediate time; a first calculation submodule, used to calculate the difference between the intermediate time and the length of the initial sliding window to obtain the start time, and calculate the sum of the lengths of the intermediate time and the initial sliding window to obtain the end time; and a second determining submodule, used to determine the time period between the start time and the end time as the target time period and determine the target time period as the filtering window.

[0098] Optionally, in the state data capture device provided in this application embodiment, the first determining submodule includes: an acquisition module, used to acquire the service load of the host system and determine whether the service load is greater than or equal to a first load threshold; a fourth determining module, used to determine a first duration as an initial sliding window when the service load is greater than or equal to the first load threshold; a second determining module, used to determine whether the service load is greater than or equal to a second load threshold when the service load is less than the first load threshold; a fifth determining module, used to determine a second duration as an initial sliding window when the service load is greater than or equal to the second load threshold, wherein the second duration is less than the first duration; and a sixth determining module, used to determine a third duration as an initial sliding window when the service load is less than the second load threshold, wherein the third duration is less than the second duration.

[0099] Optionally, in the state data capture device provided in this application embodiment, the third determining module includes: a second calculation submodule, used to calculate the difference between the time and the intermediate time in the timestamp corresponding to the candidate data, and determine that the candidate data and the state data of the host system are successfully matched if the difference is less than or equal to the difference threshold; a judging submodule, used to determine whether there is an association between the service call chain number and the transaction number of the candidate data if the difference is greater than the difference threshold, wherein there are transaction numbers of multiple transactions in the service call chain number; a third determining submodule, used to determine that the candidate data and the state data of the host system are successfully matched if there is an association between the service call chain number and the transaction number; and a fourth determining submodule, used to determine that the candidate data and the state data of the host system are not matched if there is no association between the service call chain number and the transaction number.

[0100] Optionally, in the state data capture device provided in this application embodiment, the verification unit 504 includes: an extraction module, used to extract the timestamp of each type of data from the successfully matched state data to obtain multiple timestamps; and a splicing module, used to splice the successfully matched state data in parallel according to the time order, starting from the smallest timestamp among the multiple timestamps, to obtain a state chain.

[0101] Optionally, in the state data capture device provided in this application embodiment, the verification unit 504 includes: a seventh determining module, used to determine that the state data corresponding to the transaction number is missing and the state chain verification fails when the state chain does not contain the first state data of the host system corresponding to the transaction number or the second state data of the distributed system corresponding to the transaction number; an eighth determining module, used to determine that the state data corresponding to the transaction number is not missing and to perform data consistency verification on the state chain when the state chain contains the first state data of the host system corresponding to the transaction number and the second state data of the distributed system corresponding to the transaction number; and a ninth determining module, used to determine that the state chain verification fails when the data consistency verification of the state chain fails and to determine that the state chain verification passes when the data consistency verification of the state chain succeeds.

[0102] Optionally, in the state data capture device provided in this application embodiment, the eighth determining module includes: a third calculation submodule, used to calculate a first hash value of the target variable in the memory snapshot and a second hash value of the data corresponding to the target variable in the database log when the state chain includes a memory snapshot and a database log; a fifth determining submodule, used to determine that the data consistency verification of the state chain is successful when the first hash value and the second hash value are the same; and a sixth determining submodule, used to determine that the data consistency verification of the state chain fails when the first hash value and the second hash value are different.

[0103] It should be noted that the first acquisition unit 501, the second acquisition unit 502, the matching unit 503, and the verification unit 504 mentioned above correspond to steps S201 to S204 in Embodiment 1. The four units and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules or units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0104] Example 3

[0105] Embodiments of this application may provide an electronic device. Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) Processor 602, memory 604, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0106] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0107] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Collect a memory snapshot and transaction logs from the host system; add a first time stamp to the memory snapshot and a second time stamp to the transaction logs, wherein the memory snapshot and transaction logs are correlated by transaction numbers; collect container status and database logs from the distributed system; add a third time stamp to the container status and a fourth time stamp to the database transaction logs, wherein the distributed system and the host system are used to process the same business, and the container status and database logs are correlated by service call chain numbers; match the first, second, third, and fourth time stamps using a sliding window algorithm to obtain successfully matched status data, wherein the status data includes at least one of the following: memory snapshot, transaction logs, container status, and database logs; construct a state chain based on the successfully matched status data, and verify the state chain; if the state chain verification is successful, it is determined that the status data capture was successful.

[0108] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: determining a filtering window based on the host system's timestamp, wherein the host system's timestamp includes a first timestamp or a second timestamp, and the filtering window includes all times within the target time period; determining whether a time in a third timestamp belongs to the filtering window, and determining whether a time in a fourth timestamp belongs to the filtering window; if a time in the third timestamp does not belong to the filtering window, determining that the container state and the host system's state data do not match; if a time in the fourth timestamp does not belong to the filtering window, determining that the database log and the host system's state data do not match; wherein the host system's state data includes at least one of the following: memory snapshot and transaction log; if a time in the third timestamp belongs to the filtering window, determining the container state as the first candidate data; if a time in the fourth timestamp belongs to the filtering window, determining the database log as the second candidate data; determining at least one of the first and second candidate data as candidate data; and matching the candidate data with the host system's state data.

[0109] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: determine the initial sliding window, and determine the earliest time in the first time stamp or the second time stamp as the intermediate time; calculate the difference between the intermediate time and the length of the initial sliding window to obtain the start time, calculate the sum of the length of the intermediate time and the length of the initial sliding window to obtain the end time; determine the time period between the start time and the end time as the target time period, and determine the target time period as the filtering window.

[0110] The processor can also invoke information and applications stored in the memory via the transmission device to perform the following steps: obtain the service load of the host system and determine whether the service load is greater than or equal to a first load threshold; if the service load is greater than or equal to the first load threshold, determine a first duration as the initial sliding window; if the service load is less than the first load threshold, determine whether the service load is greater than or equal to a second load threshold; if the service load is greater than or equal to the second load threshold, determine a second duration as the initial sliding window, wherein the second duration is less than the first duration; if the service load is less than the second load threshold, determine a third duration as the initial sliding window, wherein the third duration is less than the second duration.

[0111] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: calculate the difference between the time and the intermediate time in the timestamp corresponding to the candidate data; if the difference is less than or equal to a difference threshold, determine that the candidate data matches the status data of the host system successfully; if the difference is greater than the difference threshold, determine whether there is a correlation between the service call chain number and the transaction number of the candidate data, wherein the service call chain number contains the transaction numbers of multiple transactions; if there is a correlation between the service call chain number and the transaction number, determine that the candidate data matches the status data of the host system successfully; if there is no correlation between the service call chain number and the transaction number, determine that the candidate data fails to match the status data of the host system.

[0112] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: extract the timestamp of each type of data from the successfully matched state data to obtain multiple timestamps; starting from the smallest timestamp among the multiple timestamps, concatenate the successfully matched state data in parallel according to the time order to obtain a state chain.

[0113] The processor can also invoke information and applications stored in the memory via the transmission device to perform the following steps: if the state chain does not contain the first state data of the host system corresponding to the transaction number, or the second state data of the distributed system corresponding to the transaction number, determine that the state data corresponding to the transaction number is missing, and determine that the state chain verification fails; if the state chain contains the first state data of the host system corresponding to the transaction number and the second state data of the distributed system corresponding to the transaction number, determine that the state data corresponding to the transaction number is not missing, and perform data consistency verification on the state chain; if the data consistency verification of the state chain fails, determine that the state chain verification fails; if the data consistency verification of the state chain succeeds, determine that the state chain verification passes.

[0114] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: if the state chain includes a memory snapshot and a database log, calculate the first hash value of the target variable in the memory snapshot and calculate the second hash value of the data corresponding to the target variable in the database log; if the first hash value and the second hash value are the same, determine that the data consistency verification of the state chain is successful; if the first hash value and the second hash value are different, determine that the data consistency verification of the state chain fails.

[0115] This application provides a method for collecting memory snapshots and transaction logs from a host system. A first time stamp is added to the memory snapshot, and a second time stamp is added to the transaction logs. The memory snapshot and transaction logs are correlated through transaction numbers. It also collects container status and database logs from a distributed system. A third time stamp is added to the container status, and a fourth time stamp is added to the database transaction logs. The distributed system and host system process the same business logic, and the container status and database logs are correlated through service call chain numbers. A sliding window algorithm is used to match the first, second, third, and fourth time stamps to obtain successfully matched status data. The status data includes at least one of the following: memory snapshot, transaction log, container status, and database log. A status chain is constructed based on the successfully matched status data, and the status chain is verified. If the status chain verification is successful, the scheme for successfully capturing status data is determined. Nanosecond-level time stamp mapping ensures data consistency between the host and distributed ends during rollback. The construction of the dual-end status chain restores the complete business processing chain, supporting fault location and accurate identification of rollback nodes. State chain verification avoids split failures and significantly reduces the probability of rollback failure. Nanosecond-level timing accuracy and the sliding window algorithm can adapt to high-frequency trading scenarios of more than 100,000 transactions per second, achieving the goal of overcoming state fragmentation. This ensures the consistency of state data between the host system and the distributed system during rollback, thereby solving the technical problem of inconsistent state data during parallel operation of the host system and the distributed system.

[0116] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0117] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0118] Example 4

[0119] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the state data capture method provided in Embodiment 1.

[0120] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0121] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of a state data capture method.

[0122] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0123] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0124] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0127] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0128] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for capturing state data, characterized in that, include: Collect memory snapshots and transaction logs of the host system, add a first time stamp to the memory snapshot, and add a second time stamp to the transaction log, wherein the memory snapshot and the transaction log are associated with each other through transaction numbers; Collect container status and database logs of the distributed system, add a third time stamp to the container status, and add a fourth time stamp to the database transaction logs. The distributed system and the host system are used to process the same business, and the container status and the database logs are associated with each other through service call chain numbers. The first time stamp, the second time stamp, the third time stamp, and the fourth time stamp are matched using a sliding window algorithm to obtain successfully matched status data, wherein the status data includes at least one of the following: the memory snapshot, the transaction log, the container status, and the database log; A state chain is constructed based on the successfully matched state data, and the state chain is verified. If the state chain is verified successfully, it is determined that the state data was successfully captured.

2. The method according to claim 1, characterized in that, Matching the first time stamp, the second time stamp, the third time stamp, and the fourth time stamp using a sliding window algorithm includes: The filtering window is determined based on the time stamp of the host system, wherein the time stamp of the host system includes the first time stamp or the second time stamp, and the filtering window includes all times within the target time period; Determine whether the time in the third time stamp belongs to the filtering window, and determine whether the time in the fourth time stamp belongs to the filtering window; If the time in the third timestamp does not belong to the filtering window, it is determined that the container status fails to match the status data of the host system. If the time in the fourth timestamp does not belong to the filtering window, it is determined that the database log fails to match the status data of the host system. The status data of the host system includes at least one of the following: the memory snapshot and the transaction log. If the time in the third time stamp belongs to the filtering window, the container status is determined as the first candidate data. If the time in the fourth time stamp belongs to the filtering window, the database log is determined as the second candidate data. At least one of the first candidate data and the second candidate data is determined as candidate data, and the candidate data is matched with the status data of the host system.

3. The method according to claim 2, characterized in that, Determining the filtering window based on the timestamp of the host system includes: Determine the initial sliding window and set the earliest time among the first time stamp or the second time stamp as the intermediate time. Calculate the difference between the intermediate time and the length of the initial sliding window to obtain the start time; calculate the sum of the intermediate time and the length of the initial sliding window to obtain the end time. The time period between the start time and the end time is determined as the target time period, and the target time period is determined as the filtering window.

4. The method according to claim 3, characterized in that, Determining the initial sliding window includes: Obtain the service load of the host system and determine whether the service load is greater than or equal to a first load threshold. If the service load is greater than or equal to the first load threshold, the first duration is determined as the initial sliding window; If the service load is less than the first load threshold, determine whether the service load is greater than or equal to the second load threshold. If the business load is greater than or equal to the second load threshold, the second duration is determined as the initial sliding window, wherein the second duration is less than the first duration; If the business load is less than the second load threshold, the third duration is determined as the initial sliding window, wherein the third duration is less than the second duration.

5. The method according to claim 3, characterized in that, Matching the candidate data with the status data of the host system includes: Calculate the difference between the time in the timestamp corresponding to the candidate data and the intermediate time. If the difference is less than or equal to the difference threshold, determine that the candidate data is successfully matched with the status data of the host system. If the difference is greater than the difference threshold, it is determined whether there is a correlation between the service call chain number and the transaction number of the candidate data, wherein the service call chain number contains the transaction numbers of multiple transactions; If the service call chain number is associated with the transaction number, it is determined that the candidate data successfully matches the status data of the host system; If the service call chain number and the transaction number are not associated, it is determined that the candidate data fails to match the status data of the host system.

6. The method according to claim 1, characterized in that, Constructing a state chain based on the successfully matched state data includes: Extract the timestamp of each data type from the successfully matched status data to obtain multiple timestamps; Starting with the smallest timestamp among the multiple timestamps, the successfully matched state data are concatenated in parallel according to time order to obtain the state chain.

7. The method according to claim 1, characterized in that, Verification of the state chain includes: If the state chain does not contain the first state data of the host system corresponding to the transaction number, or the second state data of the distributed system corresponding to the transaction number, it is determined that the state data corresponding to the transaction number is missing, and the state chain verification fails. If the state chain contains the first state data of the host system corresponding to the transaction number and the second state data of the distributed system corresponding to the transaction number, it is determined that there is no missing state data corresponding to the transaction number, and the state chain is verified for data consistency. If the data consistency verification of the state chain fails, it is determined that the state chain verification is unsuccessful; if the data consistency verification of the state chain succeeds, it is determined that the state chain verification is successful.

8. The method according to claim 7, characterized in that, Data consistency verification of the state chain includes: If the state chain includes the memory snapshot and the database log, calculate the first hash value of the target variable in the memory snapshot, and calculate the second hash value of the data corresponding to the target variable in the database log; If the first hash value and the second hash value are the same, it is determined that the data consistency verification of the state chain is successful; If the first hash value is different from the second hash value, the data consistency verification of the state chain is determined to have failed.

9. A state data acquisition device, characterized in that, include: The first acquisition unit is used to acquire memory snapshots and transaction logs of the host system, add a first time stamp to the memory snapshot, and add a second time stamp to the transaction log, wherein the memory snapshot and the transaction log are associated with each other through transaction numbers; The second collection unit is used to collect the container status and database logs of the distributed system, add a third time stamp to the container status, and add a fourth time stamp to the database transaction logs. The distributed system and the host system are used to process the same business, and the container status and the database logs are associated with each other through the service call chain number. The matching unit is used to match the first time stamp, the second time stamp, the third time stamp, and the fourth time stamp using a sliding window algorithm to obtain successfully matched status data, wherein the status data includes at least one of the following: the memory snapshot, the transaction log, the container status, and the database log; The verification unit is used to construct a state chain based on the successfully matched state data, and to verify the state chain. If the state chain is verified, the state data is determined to have been successfully captured.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the state data capture method according to any one of claims 1 to 8.

Images