Primary and backup dual cache data snapshot and recovery method for a business processing system

Abstract

Embodiments of the present disclosure disclose a primary-backup dual cache data snapshot and recovery method for a business processing system. A specific implementation of the method includes: performing reference switching on a primary cache mapping table and a backup cache mapping table to obtain a switched backup cache mapping table; performing serialization coding processing on the switched backup cache mapping table to obtain a target snapshot file set; extracting a first snapshot file and a second snapshot file; deserializing the first snapshot file and the second snapshot file; performing ordered playback updating on the primary cache mapping table and the backup cache mapping table to obtain an updated primary cache mapping table and an updated backup cache mapping table; determining target business state data; merging the updated primary cache mapping table, and performing memory reorganization on the merged primary cache mapping table. The implementation relates to the technical field of computers, and can avoid business downtime during snapshot, avoid inconsistent business state data, avoid incorrect data retention, and avoid system delay fluctuations.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a method for primary and backup dual-buffer data snapshot and recovery for a business processing system. Background Technology

[0002] In business processing systems, to ensure data reliability and rapid recovery under high concurrency, it is typically necessary to periodically snapshot the core business state data in memory and restore it from the snapshot upon system restart. Existing memory data snapshot and recovery methods usually work as follows: when a snapshot is triggered, the data structure in memory is locked, and the cached data is completely copied or serialized and written to disk; upon system restart, the latest single snapshot file is read from disk, deserialized, and loaded into a single cache mapping table in memory; then, the message stream during downtime is retrieved from the sequencer and replayed sequentially into the cache mapping table; during system operation, business query requests directly access this single cache mapping table, and at the end of the day, the cache is fully overwritten and merged.

[0003] Currently, in practice, the following technical problems often arise when using the above methods to perform data snapshots and restore data from business processing systems: Existing cache snapshot mechanisms require locking or fully copying runtime data when generating snapshots, leading to blocking of business threads and increased latency in high-frequency, low-latency-sensitive business scenarios, ultimately causing business interruptions during snapshot periods. When the system restarts, only a single snapshot is loaded and replayed, which can easily cause data version conflicts between snapshot data and replay messages, resulting in inconsistent business states after recovery. Furthermore, traditional single-cache merging methods cannot correctly propagate deletion operation semantics, causing deleted data to be incorrectly retained after recovery. Simultaneously, frequent business updates lead to frequent creation and destruction of cached objects, easily causing heap memory pressure and garbage collection jitter, resulting in system latency fluctuations.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the present disclosure concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure provide a method, apparatus, electronic device, and computer-readable medium for primary and backup dual-buffered data snapshot and recovery in a business processing system to address the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a method for data snapshotting and recovery of a primary and backup dual-cached system for a business processing system, comprising: in response to receiving a snapshot trigger instruction, switching the references of a primary cache mapping table and a backup cache mapping table to obtain a swapped primary cache mapping table and a swapped backup cache mapping table; performing serialization encoding processing on the swapped backup cache mapping table to obtain a target snapshot file set, and storing the target snapshot file set in a preset snapshot storage directory; in response to detecting a system restart signal, traversing the preset snapshot storage directory to extract a first snapshot file and a second snapshot file; deserializing the first snapshot file and the second snapshot file to obtain a first business status dataset and a second business status dataset; storing the first business status dataset in the backup cache mapping table, and storing the second business status dataset in a backup cache mapping table. The aforementioned primary cache mapping table; in response to receiving a service information stream to be replayed during downtime, the primary cache mapping table and the backup cache mapping table are updated in an orderly manner according to the global sequence number of the service information stream to be replayed, resulting in an updated primary cache mapping table and an updated backup cache mapping table; in response to receiving a query request for a target key value, the primary version data object and the backup version data object corresponding to the query request are extracted according to the updated primary cache mapping table and the updated backup cache mapping table, and the target service status data is determined according to the primary version data object and the backup version data object, so as to output the target service status data; according to the updated backup cache mapping table, the updated primary cache mapping table is merged to obtain a merged primary cache mapping table, and the merged primary cache mapping table is reorganized in memory based on a preset object pool.

[0008] Secondly, some embodiments of this disclosure provide a primary and secondary dual-cache data snapshot and recovery apparatus for a business processing system, comprising: a reference switching unit configured to, in response to receiving a snapshot trigger instruction, perform reference switching on a primary cache mapping table and a secondary cache mapping table to obtain a swapped primary cache mapping table and a swapped secondary cache mapping table; a serialization encoding processing unit configured to perform serialization encoding processing on the swapped secondary cache mapping table to obtain a target snapshot file set, and store the target snapshot file set in a preset snapshot storage directory; a traversal unit configured to, in response to detecting a system restart signal, traverse the preset snapshot storage directory to extract a first snapshot file and a second snapshot file; a deserialization unit configured to deserialize the first snapshot file and the second snapshot file to obtain a first business state dataset and a second business state dataset; and a storage unit configured to store the first business state dataset in the secondary cache mapping table and store the target snapshot file in a preset snapshot storage directory; and to store the target snapshot file in a preset snapshot storage directory to obtain a target snapshot file set ... The second business status dataset is stored in the aforementioned main cache mapping table; the ordered replay update unit is configured to, in response to receiving a business information stream to be replayed during downtime, perform ordered replay updates on the aforementioned main cache mapping table and the aforementioned backup cache mapping table according to the global sequence number of the business information stream to be replayed, to obtain the updated main cache mapping table and the updated backup cache mapping table; the extraction unit is configured to, in response to receiving a query request for a target key value, extract the main version data object and the backup version data object corresponding to the query request according to the aforementioned updated main cache mapping table and the aforementioned updated backup cache mapping table, and determine the target business status data according to the aforementioned main version data object and the aforementioned backup version data object, so as to output the aforementioned target business status data; the merging unit is configured to merge the aforementioned updated main cache mapping table according to the aforementioned updated backup cache mapping table, to obtain the merged main cache mapping table, and perform memory reorganization on the aforementioned merged main cache mapping table based on a preset object pool.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0011] The above-described embodiments of this disclosure have the following beneficial effects: the primary and backup dual-caching data snapshot and recovery method for business processing systems, as described in some embodiments of this disclosure, can avoid business interruptions during snapshots, avoid inconsistencies in business state data, avoid incorrect data retention, and avoid system latency fluctuations. Specifically, the reasons for business interruptions, inconsistencies in business state data, incorrect data retention, and system latency fluctuations during snapshots are as follows: existing cache snapshot mechanisms require locking or completely copying running data when generating snapshots, leading to business thread blocking and increased business request latency in high-frequency, low-latency sensitive business scenarios, thus causing business interruptions during snapshots. When the system restarts, only a single snapshot is loaded and replayed, which can easily lead to data version conflicts between snapshot data and replay messages, resulting in inconsistent business states after recovery. Furthermore, traditional single-cache merging methods cannot correctly propagate the semantics of deletion operations, causing deleted data to be incorrectly retained after recovery. At the same time, high-frequency business updates lead to frequent creation and destruction of cache objects, which can easily cause heap memory pressure and garbage collection jitter, resulting in system latency fluctuations. Based on this, some embodiments of the present disclosure of a primary and backup dual-cached data snapshot and recovery method for a business processing system firstly, in response to receiving a snapshot trigger instruction, switch the references of the primary cache mapping table and the backup cache mapping table to obtain a swapped primary cache mapping table and a swapped backup cache mapping table. This allows business writes to be immediately switched to the swapped primary cache mapping table, eliminating lock contention and business thread blocking during snapshotting, achieving zero-pause snapshots, and avoiding business interruptions during snapshotting. Secondly, the swapped backup cache mapping table is serialized and encoded to obtain a target snapshot file set, and the target snapshot file set is stored in a preset snapshot storage directory. This allows the isolated swapped backup cache mapping table to be serialized and encoded, completely decoupling the snapshot file generation process from real-time business writes, avoiding additional impacts on business request delays. Thirdly, in response to detecting a system restart signal, the preset snapshot storage directory is traversed to extract the first snapshot file and the second snapshot file. This allows the extraction of the two snapshot files with the largest and second largest global sequence numbers, providing a redundant data foundation for subsequent dual-version data loading and version arbitration, avoiding state loss or inconsistency caused by loading only a single snapshot. Next, the first snapshot file and the second snapshot file are deserialized to obtain the first business status dataset and the second business status dataset. This allows the snapshot files on disk to be restored into the first and second business status datasets in memory, providing structured data input for subsequent concurrent loading and version comparison of primary and backup caches. Then, the first business status dataset is stored in the backup cache mapping table, and the second business status dataset is stored in the primary cache mapping table.Therefore, different versions of business status data can be loaded into the backup cache mapping table and the main cache mapping table respectively, achieving physical isolation between the two caches and creating conditions for version arbitration and correct propagation of deletion semantics during queries. Subsequently, in response to receiving the business information stream to be replayed during downtime, the main cache mapping table and the backup cache mapping table are updated in an orderly manner according to the global sequence number of the business information stream to be replayed, resulting in the updated main cache mapping table and the updated backup cache mapping table. Thus, the main and backup caches can be updated in an orderly manner according to the global sequence number, and the new data is prioritized through the version number increment comparison mechanism, which resolves the version conflict between snapshot data and replay information and ensures the consistency of business status after recovery. Then, in response to receiving a query request for a target key value, the main version data object and the backup version data object corresponding to the query request are extracted according to the updated main cache mapping table and the updated backup cache mapping table, and the target business status data is determined based on the main version data object and the backup version data object, so as to output the target business status data. Therefore, queries can always simultaneously check the primary and backup versions of the data object, arbitrate by version number, and detect soft deletion markers, ensuring that the target business status data output externally is always the latest and valid data, avoiding the erroneous retention of deleted data after recovery. Finally, based on the updated backup cache mapping table, the updated primary cache mapping table is merged to obtain a merged primary cache mapping table, and memory reorganization is performed on the merged primary cache mapping table based on a preset object pool. This releases memory fragmentation, reduces garbage collection jitter, and avoids system latency fluctuations. Ultimately, it avoids business interruptions during snapshots, inconsistencies in business status data, erroneous data retention, and system latency fluctuations. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the primary and backup dual-buffer data snapshot and recovery method for a business processing system according to the present disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the primary and backup dual-buffer data snapshot and recovery device for a business processing system according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] refer to Figure 1 The diagram illustrates a flow 100 of some embodiments of a primary / backup dual-buffer data snapshot and recovery method for a business processing system according to the present disclosure. This primary / backup dual-buffer data snapshot and recovery method for a business processing system includes the following steps: Step 101: In response to receiving the snapshot trigger instruction, switch the references of the primary cache mapping table and the backup cache mapping table to obtain the swapped primary cache mapping table and the swapped backup cache mapping table.

[0021] In some embodiments, the execution entity (e.g., an electronic device) of the above-described method for primary and backup dual-cached data snapshot and recovery in a business processing system can, in response to receiving a snapshot trigger instruction, switch the references of the primary cache mapping table and the backup cache mapping table to obtain the swapped primary cache mapping table and the swapped backup cache mapping table. The business processing system can be a high-concurrency data processing system capable of receiving, processing, and storing a large number of business requests. For example, the business system can be a stock trading system or a brokerage's core trading system. The snapshot trigger instruction can be an electrical signal or control information generated by a system timer at a preset time point to trigger business operations, or it can be manually triggered by maintenance personnel through a management interface. The preset time point can be a time point pre-set in the business processing system to trigger snapshots. For example, the system timer can be Linux cron. For example, the snapshot trigger instruction can be an intraday incremental snapshot instruction triggered by the trading system at 14:30. The primary cache mapping table can be a memory data structure (e.g., a hash table structure) that directly carries all real-time read and write operations during the operation of the business processing system. The primary cache mapping table can be implemented using a hash table (HashMap) to store the latest business status data. The aforementioned business status data can be data generated during the operation of the aforementioned business processing system by various business operations (e.g., adding, deleting, modifying), reflecting the current status of the business entity. This business status data can be stored in key-value pair format. The key of the aforementioned business status data can be a business identifier. For example, the key of the aforementioned business status data can include, but is not limited to: order ID, user ID. The value of the aforementioned business status data can be specific business content. For example, the value of the aforementioned business status data can include, but is not limited to: order details, position records. As an example, the aforementioned business status data can be the latest order status or position information. The aforementioned backup cache mapping table can have the same structure as the aforementioned main cache mapping table, used to store the previous snapshot data or historical data during the recovery process. The aforementioned backup cache mapping table is only accessed when a snapshot is generated, a snapshot is loaded, or the end-of-day merge occurs.

[0022] In some optional implementations of certain embodiments, the aforementioned execution entity may, in response to receiving a snapshot trigger instruction, perform a reference switch between the primary cache mapping table and the backup cache mapping table to obtain the swapped primary cache mapping table and the swapped backup cache mapping table: Step 1: In response to receiving the snapshot trigger instruction, read the current reference address of the main cache mapping table and the current reference address of the backup cache mapping table to obtain the first reference address and the second reference address. Based on the first reference address and the second reference address, generate a set of addresses to be swapped. In practice, firstly, the execution entity can suspend the modification privilege of the business thread on the cache mapping table reference pointer in response to receiving the snapshot trigger instruction. Secondly, read the pointer variable (current reference address) of the main cache mapping table to obtain the address value of the physical memory pointed to by the pointer variable, thus obtaining the first reference address. Thirdly, read the pointer variable of the backup cache mapping table to obtain the address value of the physical memory pointed to by the pointer variable, thus obtaining the second reference address. Fourthly, merge the first reference address and the second reference address into a set of addresses to be swapped. As an example, if the main cache mapping table points to memory address 0xAA01 and the backup cache mapping table points to memory address 0xBB02, the set of addresses to be swapped can be {0xAA01, 0xBB02}. The first reference address can be the starting address of the memory currently pointed to by the main cache mapping table. The second reference address mentioned above can be the starting memory address currently pointed to by the aforementioned backup cache mapping table.

[0023] Step two: Based on the aforementioned set of addresses to be swapped, construct a temporary reference address variable and write the first reference address into this temporary reference address variable as a temporary storage address. In practice, the execution entity can create a storage unit as the storage unit for the temporary reference address variable. Then, write the first reference address into the storage unit of the temporary reference address variable as a temporary storage address. This temporary reference address variable can be a temporary storage space created in the CPU register or stack memory. The size of this temporary storage space can store the size of a complete memory address value.

[0024] Step three: Assign the second reference address to the reference pointer of the main cache mapping table to generate the swapped main cache mapping table. In practice, the execution entity can overwrite the reference pointer of the main cache mapping table with the second reference address in the set of addresses to be swapped, thus obtaining the swapped main cache mapping table.

[0025] Step four: Assign the temporary address to the reference pointer of the backup cache mapping table to generate the swapped backup cache mapping table. In practice, the execution entity can assign the temporary address stored in the temporary reference address variable to the reference pointer of the backup cache mapping table to obtain the swapped backup cache mapping table.

[0026] Step 102: Perform serialization encoding on the swap backup cache mapping table to obtain the target snapshot file set, and store the target snapshot file set in the preset snapshot storage directory.

[0027] In some embodiments, the execution entity may perform serialization encoding on the exchanged backup cache mapping table to obtain a target snapshot file set, and store the target snapshot file set in a preset snapshot storage directory.

[0028] In some optional implementations of certain embodiments, the execution entity may perform serialization encoding on the aforementioned swap backing cache mapping table to obtain a target snapshot file set, and store the target snapshot file set in a preset snapshot storage directory through the following steps: Step 1: Extract the business status records to be serialized from the aforementioned exchange backup cache mapping table to obtain a set of business status records to be serialized. In practice, the execution entity can traverse the cache entries stored in the aforementioned exchange backup cache mapping table, identifying the key and corresponding value in each cache entry as the business status record to be serialized, thus obtaining a set of business status records to be serialized. The aforementioned cache entries can be business status data and corresponding metadata fields stored in the aforementioned exchange backup cache mapping table. The aforementioned metadata fields can include, but are not limited to: original version number, global sequence number, and soft deletion flag. The business status records to be serialized in the aforementioned set of business status records can be business status data stored in the aforementioned exchange backup cache mapping table. The aforementioned original version number can be the number of times the business status record has been modified since its creation. The aforementioned global sequence number can be an incrementing logical timestamp used to identify the chronological order of business occurrences.

[0029] Step two: Extract the original version number and global sequence number of each business state record to be serialized from the aforementioned business state record set to be serialized, as metadata snapshot information, to obtain a metadata snapshot information set. In practice, the aforementioned execution entity can traverse the metadata fields of the corresponding cache entries of each business state record to be serialized in the aforementioned business state record set to be serialized in the aforementioned exchange backend cache mapping table, and read the original version number and global sequence number from the aforementioned metadata fields as metadata snapshot information.

[0030] Step 3: Based on the aforementioned metadata snapshot information set, perform binary stream encoding conversion on the aforementioned set of business status records to be serialized to obtain a serialized byte stream set. In practice, the aforementioned execution entity can write each business status record to be serialized and its corresponding metadata snapshot information into a byte stream according to a preset encoding protocol to obtain an initial serialized byte stream set. Then, add a length identifier to the beginning of each initial serialized byte stream in the aforementioned initial serialized byte stream set to obtain the serialized byte stream set. The aforementioned binary stream encoding conversion can be a process of converting a structured object into a continuous binary byte sequence that can be stored in a file or transmitted over a network. The aforementioned preset encoding protocol can be Protobuf or Kryo. The aforementioned length identifier can be the total number of bytes in the aforementioned initial serialized byte stream, used to indicate the length of the aforementioned initial serialized byte stream.

[0031] Step four: Generate a target snapshot file name set based on the current business identifier and the metadata snapshot information set. In practice, the aforementioned execution entity can read the current business identifier from the aforementioned business processing system. Next, it selects the largest global sequence number from the aforementioned metadata snapshot information set. Then, it merges the current business identifier and the global sequence number into a target snapshot file name using a preset string format, resulting in the target snapshot file name set. The current business identifier can be a string identifier used to distinguish different business lines, different nodes, or different cache instances. The preset string format can be snapshot_cache_{global sequence number}_{business identifier}.bin.

[0032] Step 5: Generate an initial snapshot file set based on the target snapshot file name set and the serialized byte stream set. In practice, the execution entity can create a corresponding empty file for each target snapshot file name in the target snapshot file name set. Then, write each serialized byte stream in the serialized byte stream set into the empty file to obtain a written file, and name the written file the target file name as the initial snapshot file, thus obtaining the initial snapshot file set.

[0033] Step six: Perform cyclic redundancy check (CRC) on each initial snapshot file in the initial snapshot file set to obtain a checksum set. Then, merge this checksum set with the initial snapshot file set to obtain the target snapshot file set. In practice, the executing entity can determine the CRC checksum for each initial snapshot file in the initial snapshot file set to obtain the checksum set. For example, the CRC32 or CRC64 algorithm can be used to determine the CRC checksum. Next, append each checksum from the checksum set to the end of the corresponding initial snapshot file in the initial snapshot file set to obtain the target snapshot file set.

[0034] Step seven: Store the target snapshot file set to a preset snapshot storage directory. In practice, the executing entity can store the target snapshot file set in the preset snapshot storage directory and update the file system inode list under the preset snapshot storage directory. The preset snapshot storage directory can be a specific folder path in the business processing system used to store snapshot files. The file system inode list can be a list used to record the metadata of all files in the preset snapshot storage directory. Each file inode in the file inode list can correspond to the filename of the target snapshot file and its corresponding global sequence number.

[0035] Step 103: In response to the detection of a system restart signal, traverse the preset snapshot storage directory to extract the first snapshot file and the second snapshot file.

[0036] In some embodiments, the aforementioned execution entity may, in response to detecting a system restart signal, traverse the aforementioned preset snapshot storage directory to extract a first snapshot file and a second snapshot file. The aforementioned system restart signal may be a startup notification signal sent by the operating system kernel to the business process when the aforementioned business processing system recovers from a failure, restarts after a version upgrade, or restarts during routine maintenance, and is used to trigger the system state recovery process.

[0037] In some optional implementations of certain embodiments, the aforementioned execution entity may, in response to the detection of a system restart signal, traverse the aforementioned preset snapshot storage directory to extract the first snapshot file and the second snapshot file: Step one: In response to the detection of a system restart signal, read the file system inode list of the aforementioned preset snapshot storage directory to obtain a set of candidate snapshot filenames. In practice, the aforementioned execution entity can, in response to the detection of a system restart signal, initiate a read request to the file system of the aforementioned preset snapshot storage directory to obtain the filenames associated with the inodes, which will serve as candidate snapshot filenames, thus obtaining a set of candidate snapshot filenames.

[0038] Step two involves matching and filtering the aforementioned candidate snapshot filename set to obtain a valid snapshot filename set. This matching and filtering process can involve removing candidate snapshot filenames that do not conform to a preset snapshot file naming rule. This preset snapshot file naming rule can be a string used to uniformly name snapshot files. For example, this preset naming rule could be prefixed with `snapshot_cache`, followed by a global serial number in numeric format and a business identifier code combining alphanumeric characters, and ending with `bin`. In practice, the executing entity can use regular expressions to match each candidate snapshot filename in the aforementioned candidate snapshot filename set, and determine the matching candidate snapshot filenames as valid snapshot filenames, thus obtaining a valid snapshot filename set.

[0039] Step 3: Extract the global sequence number of each valid snapshot filename from the set of valid snapshot filenames mentioned above, and use it as sequence number metadata to obtain the sequence number metadata dataset. In practice, the execution entity mentioned above can extract the global sequence number corresponding to each valid snapshot filename from the set of valid snapshot filenames mentioned above, and use it as sequence number metadata to obtain the sequence number metadata dataset.

[0040] Step four: Sort the above sequence number metadata dataset in descending order to obtain the sequence number metadata sequence. In practice, the execution entity can sort the sequence number metadata in the above sequence number metadata set in descending order according to the sequence number size to obtain the sequence number metadata sequence.

[0041] Step 5: Based on the aforementioned sequence number metadata sequence, determine the first snapshot file name and the second snapshot file name. In practice, the executing entity can determine the snapshot file name corresponding to the first sequence number metadata in the aforementioned sequence as the first snapshot file name. Then, it can determine the snapshot file name corresponding to the second sequence number metadata in the aforementioned sequence as the second snapshot file name.

[0042] Step six: Based on the first snapshot filename and the second snapshot filename, locate the corresponding snapshot file in the preset snapshot storage directory to obtain the first snapshot file and the second snapshot file. In practice, the executing entity can search for the snapshot file corresponding to the first snapshot filename and the second snapshot filename in the preset snapshot storage directory. Then, the snapshot file corresponding to the first snapshot filename is determined as the first snapshot file, and the snapshot file corresponding to the second snapshot filename is determined as the second snapshot file.

[0043] Step 104: Deserialize the first snapshot file and the second snapshot file to obtain the first business status dataset and the second business status dataset.

[0044] In some embodiments, the execution entity can deserialize the first snapshot file and the second snapshot file to obtain a first business state dataset and a second business state dataset. The deserialization process can be the process of restoring a binary byte stream to structured data in memory.

[0045] In some optional implementations of certain embodiments, the aforementioned execution entity can deserialize the first snapshot file and the second snapshot file through the following steps to obtain a first business state dataset and a second business state dataset: Step one: Obtain the header information of the first snapshot file and the second snapshot file to obtain a header information set. The header information in this set may include the header information of both the first and second snapshot files. This header information may include the snapshot file's version number, global serial number, checksum, and service identifier.

[0046] Step two: Based on the aforementioned file header information set, extract the file-internal checksums of the first snapshot file and the second snapshot file to obtain a file-internal checksum set. In practice, the executing entity can read the checksums of the first snapshot file and the second snapshot file from the aforementioned file header information set as the file-internal checksums to obtain the file-internal checksum set.

[0047] Step three: Perform cyclic redundancy check on the first snapshot file and the second snapshot file to obtain a real-time checksum set. In practice, the executing entity can determine the cyclic checksums of all fields in the first and second snapshot files except for the checksum field at the end, as real-time checksums, thus obtaining a real-time checksum set. The real-time checksums in the set can include the real-time checksums of the first and second snapshot files.

[0048] Step four: Generate an integrity verification result based on the aforementioned file-internal checksum set and the aforementioned real-time checksum set. In practice, the executing entity can generate an integrity verification result indicating data integrity in response to the fact that the file-internal checksum of the first snapshot file is equal to the aforementioned real-time checksum and the file-internal checksum of the second snapshot file is equal to the aforementioned real-time checksum; and generate an integrity verification result indicating data incompleteness in response to the fact that the file-internal checksum of the first snapshot file is not equal to the aforementioned real-time checksum or the file-internal checksum of the second snapshot file is not equal to the aforementioned real-time checksum.

[0049] Step five: In response to the integrity check result indicating data integrity, extract the serialized byte stream of the first snapshot file to obtain a first serialized byte stream, and extract the serialized byte stream of the second snapshot file to obtain a second serialized byte stream. In practice, the execution entity can, in response to the integrity check result indicating data integrity, determine the binary content between the end of the header of the first snapshot file and the start of the checksum block as the first serialized byte stream, and determine the binary content between the end of the header of the second snapshot file and the start of the checksum block as the second serialized byte stream.

[0050] Step six involves decoding and converting the first and second serialized byte streams to obtain a first and a second original key-value pair set. This decoding and conversion can be the process of restoring the binary serialized byte stream to a key-value pair structure in memory, following the inverse rules of the preset encoding protocol. In practice, the executing entity can parse the key-value pairs from the first and second serialized byte streams according to the preset encoding protocol to obtain the first and second original key-value pair sets. These key-value pairs may include, but are not limited to, the original version number, the global serial number, and a soft delete flag.

[0051] Step seven: Based on the first and second original key-value pair sets mentioned above, generate a first metadata set and a second metadata set. In practice, the executing entity can determine the original version number, global sequence number, and soft deletion marker from the first original key-value pair set as the first metadata to obtain the first metadata set. The original version number, global sequence number, and soft deletion marker from the second original key-value pair set can be determined as the second metadata to obtain the second metadata set.

[0052] Step 8: Based on the aforementioned first metadata set, perform data cleaning and reconstruction on the aforementioned first original key-value pair set to obtain the first business status dataset. In practice, the aforementioned execution entity can perform the following data cleaning and reconstruction on the aforementioned first original key-value pair set: First, in response to missing required fields in the aforementioned first original key-value pair set, query the message with the corresponding global sequence number from the sequencer's message log to complete the data. Second, in response to field format errors in the first original key-value pair set, correct them according to the business rules corresponding to the global sequence number. Third, temporary fields used for snapshot storage in the original data can be removed. Fourth, classify and reorganize according to business type to obtain the first business status dataset. The aforementioned required fields can be fields that must exist in the business status data. For example, the aforementioned required fields can be order ID and transaction time. The aforementioned field format errors can include, but are not limited to, data type errors and value range errors. For example, the aforementioned data type error can be a numeric field (e.g., price) including alphanumeric characters. The aforementioned value range error can be an additional field being a negative number, or a future timestamp appearing in the transaction time field. The aforementioned temporary field can be a snapshot generation timestamp. The aforementioned business types can be order-based, account-based, or position-based. The aforementioned sequencer can be a component that generates a globally unique sequence number for the input events, transactions, or messages.

[0053] Step 9: Based on the aforementioned second metadata, perform data cleaning and reconstruction on the aforementioned second original key-value pair set to obtain the second business status dataset.

[0054] Step 105: Store the first business status dataset in the backup cache mapping table and store the second business status dataset in the main cache mapping table.

[0055] In some embodiments, the execution entity may store the first business status dataset in the backup cache mapping table and the second business status dataset in the main cache mapping table.

[0056] In addressing the technical problems mentioned in the background section, the following technical issues often arise in the application scenario: recovery of a business processing system after a crash or version upgrade. These issues include: during the system recovery phase, when loading the deserialized business state dataset into the memory cache, traditional single-cache direct overwrite methods suffer from residual historical data, leading to a mix of old and new versions; lack of data standardization and encapsulation causes subsequent version arbitration to fail; lack of pre-allocated hash buckets results in frequent dynamic expansion during insertion, causing memory fragmentation and performance fluctuations; and the lack of a rollback mechanism for loading failures leaves the cache in a semi-updated state. These factors contribute to inconsistent business states after recovery, frequent system fluctuations, and excessively long recovery times. Given the specific requirements of this application scenario—pre-allocated space and batch insertion—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may store the first business status dataset in the backup cache mapping table and the second business status dataset in the main cache mapping table through the following steps: Step one involves redundancy removal from the aforementioned primary cache mapping table and backup cache mapping table, resulting in a primary cache mapping table and a backup cache mapping table after redundancy removal. This redundancy removal may involve removing residual historical key-value pairs from the cache mapping tables and releasing memory space occupied by invalid data.

[0057] Step two: Based on the first business status dataset and the second business status dataset mentioned above, generate a first dataset to be written and a second dataset to be written. In practice, the execution entity can add metadata fields to each first business status data in the first business status dataset and each second business status data in the second business status dataset to obtain the first dataset to be written and the second dataset to be written.

[0058] Step 3: Based on the first dataset to be written and the second dataset to be written, determine the primary cache pre-allocation information and the backup cache pre-allocation information. In practice, the execution entity can determine the number of first data to be written in the first dataset and the number of second data to be written in the second dataset. Then, the product of the number of first data to be written and a preset load factor is used to determine the backup cache pre-allocation information, as is the product of the number of second data to be written and the preset load factor. The preset load factor can be the maximum percentage of used slots and total slots in the cache mapping table preset by the business processing system. For example, the preset load factor can be 0.75. The used slots can be the number of currently occupied slots in the cache mapping table. The total slots can be the total number of slots pre-allocated in the cache mapping table.

[0059] Step four: Based on the aforementioned backup cache pre-allocation information, insert the first dataset to be written into the aforementioned backing cache removal mapping table to obtain the backing cache insertion mapping table. In practice, the execution entity can allocate space for the first dataset to be written in the aforementioned backing cache removal mapping table according to the aforementioned backup cache pre-allocation information and write the aforementioned backup cache pre-allocation information to obtain the backing cache insertion mapping table.

[0060] Step 5: Based on the above main cache pre-allocation information, insert the above second dataset to be written into the above removed main cache mapping table to obtain the inserted main cache mapping table.

[0061] Step six: Count the number of entries in the aforementioned post-insertion primary cache mapping table and the aforementioned post-insertion backup cache mapping table to obtain a primary and backup entry count set. In practice, the execution entity can count the number of non-empty entries in the aforementioned post-insertion primary cache mapping table and the aforementioned post-insertion backup cache mapping table to obtain the primary and backup entry count set. The primary and backup entry counts in the aforementioned primary and backup entry count set can include the primary entry count and the backup entry count.

[0062] Step seven: Based on the aforementioned primary and backup entry count sets, perform storage checks on the aforementioned insertion backup cache mapping table and the aforementioned insertion primary cache mapping table to obtain a detection result set. In practice, the execution entity can compare whether the primary entry count is consistent with the size of the aforementioned second dataset to be written and whether the backup entry count is consistent with the size of the aforementioned first dataset to be written. In response to size consistency, a detection result indicating successful storage is generated; in response to size inconsistency, a detection result indicating storage failure is generated. The detection results in the aforementioned detection result set may include the detection results of the aforementioned insertion primary cache mapping table and the aforementioned insertion backup cache mapping table.

[0063] Step 8: In response to each detection result in the above detection result set indicating successful storage, the above-mentioned primary cache mapping table after insertion is determined as the primary cache mapping table, and the above-mentioned backup cache mapping table after insertion is determined as the backup cache mapping table.

[0064] The above-mentioned technical content and related content, as an inventive point of this disclosure, solve the technical problem of "inconsistent business states after recovery, frequent system fluctuations, and excessively long recovery time." Factors leading to inconsistencies in business states after recovery, frequent system fluctuations, and excessively long recovery time often include: during the system restart and recovery phase, when loading the deserialized business state dataset into the memory cache, the traditional single-cache direct overwrite method results in residual historical data not being cleared, leading to a mix of old and new versions; the lack of standardized data encapsulation causes subsequent version arbitration to fail; the absence of pre-allocated hash buckets leads to frequent dynamic expansion during the insertion process, causing memory fragmentation and performance jitter; and the lack of a rollback mechanism for loading failures results in the cache being in a semi-updated state, thus causing inconsistencies in business states after recovery, frequent system fluctuations, and excessively long recovery time. Solving these factors can avoid inconsistencies in business states after recovery, frequent system fluctuations, and excessively long recovery time. To achieve this effect, the first step is to remove redundancy from the aforementioned main cache mapping table and the aforementioned backup cache mapping table, obtaining a main cache mapping table and a backup cache mapping table after redundancy removal. This process clears residual key-value pairs, preventing data from mixing old and new versions and avoiding inconsistencies in business state after recovery. The second step generates a first and a second dataset to be written based on the first and second business state datasets. This adds standardized encapsulation containing header information such as version number and global sequence number to the original business state dataset, ensuring correct execution of subsequent version arbitration and deletion semantics, and preventing inconsistencies in business state after recovery. The third step determines the pre-allocation information for the main cache and the backup cache based on the first and second datasets to be written. This allows for pre-determining the required number of hash bucket slots, avoiding memory fragmentation and performance fluctuations caused by frequent dynamic expansion of the hash table during insertion, and preventing frequent system fluctuations and excessively long recovery times. The fourth step inserts the first dataset to be written into the removed backup cache mapping table based on the backup cache pre-allocation information, obtaining the inserted backup cache mapping table. This allows for batch allocation of contiguous hash buckets in the backup cache according to the pre-allocation information and writing of data, improving data loading efficiency and shortening restart recovery time. Fifth, based on the aforementioned pre-allocation information of the main cache, the second dataset to be written is inserted into the removed main cache mapping table to obtain the inserted main cache mapping table. This allows snapshot data to be written to the main cache according to the pre-allocation information, forming dual-version redundancy and providing fallback data for version arbitration in subsequent queries, avoiding inconsistencies in business status after recovery. Sixth, the number of entries in the inserted main cache mapping table and the inserted backup cache mapping table is counted to obtain the main and backup entry count sets. This allows the number of non-empty entries in both mapping tables to be counted, obtaining the actual amount of data after loading and providing a baseline value for subsequent integrity verification.Step 7: Based on the aforementioned primary and backup entry count sets, perform storage checks on the aforementioned inserted backup cache mapping table and the aforementioned inserted primary cache mapping table to obtain a check result set. This allows comparing the number of entries after loading with the size of the dataset to be written, checking whether the data has been completely written, ensuring no loss or corruption, and avoiding inconsistencies in the business state after recovery. Step 8: In response to each check result in the aforementioned check result set indicating successful storage, the aforementioned inserted primary cache mapping table is designated as the primary cache mapping table, and the aforementioned inserted backup cache mapping table is designated as the backup cache mapping table. This allows for atomic switching after all checks pass, avoiding business anomalies caused by partial updates. Ultimately, this avoids inconsistencies in the business state after recovery, frequent system fluctuations, and excessively long recovery times.

[0065] Step 106: In response to receiving the service information stream to be replayed during the downtime, perform ordered replay updates on the main cache mapping table and the backup cache mapping table according to the global sequence number of the service information stream to be replayed, and obtain the updated main cache mapping table and the updated backup cache mapping table.

[0066] In addressing the technical problems mentioned in the background section, the application scenario—a high-frequency, low-latency sensitive business processing system—often presents the following challenges: During system restart and recovery, it's necessary to retrieve business messages from the sequencer to restore the status. Traditional single-cache linear replay methods directly write messages sequentially to a single cache without comparing the global sequence number of the message with the version number of existing data in the cache. This leads to version conflicts between snapshot data and replay messages, causing older data to overwrite newer data. Furthermore, traditional replay methods fail to correctly propagate deletion operation semantics; deletion operations are ignored or lost during replay, resulting in incorrectly retained deleted data after recovery. Given the following requirements for this application scenario—ordered replay with global sequence numbers and synchronous updates to primary and backup caches—we have decided to adopt the following solution: In some embodiments, the aforementioned execution entity may, in response to receiving a service information stream to be replayed during a downtime, perform ordered replay updates on the aforementioned main cache mapping table and the aforementioned backup cache mapping table based on the global sequence number of the service information stream to be replayed, thereby obtaining an updated main cache mapping table and an updated backup cache mapping table. The service information stream to be replayed during the downtime may be an ordered set of service information temporarily stored by the aforementioned service processing system before a failure or upgrade restart, which has not yet been processed by the service processing system.

[0067] In some optional implementations of certain embodiments, the aforementioned execution entity may, in response to receiving a service information stream to be replayed during a downtime, perform ordered replay updates on the primary cache mapping table and the backup cache mapping table based on the global sequence number of the service information stream to be replayed, thereby obtaining the updated primary cache mapping table and the updated backup cache mapping table: Step 1: Extract the global sequence number of each service message to be replayed from the aforementioned service information stream to obtain the set of replay sequence numbers. The global sequence number can be a logical timestamp stored in the metadata header of each service message in the aforementioned service information stream.

[0068] Step two: Determine the local baseline sequence number based on the aforementioned main cache mapping table. In practice, the execution entity can determine the local baseline sequence number as the largest global sequence number in the main cache mapping table.

[0069] Step 3: Determine the set of valid serial numbers based on the aforementioned set of serial numbers to be replayed and the aforementioned local reference serial number. In practice, the executing entity can determine the serial numbers to be replayed that are greater than the aforementioned local reference serial number in the set of serial numbers to be replayed as valid serial numbers, thus obtaining the set of valid serial numbers.

[0070] Step four: Based on the aforementioned set of valid sequence numbers and the aforementioned stream of information to be replayed, determine the set of valid information to be replayed. In practice, the executing entity can select the information to be replayed corresponding to each valid sequence number in the set of valid sequence numbers from the stream of information to be replayed, and use this information as the valid information to be replayed, thus obtaining the set of valid information to be replayed.

[0071] Step 5: Sort the above-mentioned set of valid information to be replayed to obtain a sequence of valid information to be replayed. In practice, the executing entity can sort the valid information to be replayed in the above-mentioned set of valid information to be replayed in ascending order according to the global sequence number to obtain a sequence of valid information to be replayed.

[0072] Step 6: Perform the following steps for each valid piece of information to be replayed in the above valid sequence of information to be replayed: Sub-step one: Based on the aforementioned valid information to be replayed, generate the information payload and the current information sequence number. In practice, the executing entity can deserialize the aforementioned valid information to be replayed to obtain the target key value, business operation type, and updated business status data, and extract the global sequence number from the protocol header of the aforementioned valid information to be replayed as the current information sequence number. The aforementioned information payload includes, but is not limited to: the target key value, business operation type, and updated business status data. The aforementioned target key value can be a business identifier. For example, the aforementioned target key value can be an order ID. The aforementioned business operation type can include, but is not limited to: adding a business, modifying a business, and deleting a business. The aforementioned updated business status data can be the modified complete business object.

[0073] Sub-step two involves performing a query operation in the primary cache mapping table and the backup cache mapping table based on the target key value to obtain the primary cache hit result and the backup cache hit result. In practice, the execution entity can use the target key value as the query key to query the primary cache mapping table and the backup cache mapping table for the entry corresponding to the target key value. For entries that exist corresponding to the target key value, a cache hit result representing a hit is generated; for entries that do not exist corresponding to the target key value, a cache hit result representing a miss is generated, thus obtaining the primary cache hit result and the backup cache hit result.

[0074] Sub-step three involves determining the current version number of the main cache based on the main cache hit result and the main cache mapping table. In practice, the execution entity can respond to a main cache hit result indicating a hit by querying the version number field corresponding to the valid replay information in the main cache mapping table to obtain the current version number of the main cache. If the main cache hit result indicates a miss, the current version number of the main cache is initialized to 0.

[0075] Sub-step four: Based on the aforementioned backup cache hit results and the aforementioned backup cache mapping table, determine the current version number of the backup cache. In practice, the execution entity can respond to the aforementioned backup cache hit result indicating a hit by querying the version number field corresponding to the aforementioned valid replay information in the aforementioned backup cache mapping table to obtain the current version number of the backup cache. If the aforementioned backup cache hit result indicates a miss, the current version number of the backup cache is initialized to 0.

[0076] Sub-step five: In response to the aforementioned business operation type representing a deletion operation, a soft delete flag and tombstone information to be written are generated. The soft delete flag can be a boolean field in the cached entry used to identify that data has been deleted. A soft delete flag value of true indicates that the entry is deleted tombstone data, preventing it from being overwritten by older version data during snapshot recovery or version merging. A soft delete flag value of false indicates valid business data, indicating that the deletion operation was performed by older data during snapshot recovery. The tombstone information to be written can include the business identifier, version number, and business status data of the deleted data.

[0077] Sub-step six: In response to the above-mentioned business operation type representing a non-deletion operation, the updated business status data is encapsulated to obtain the business information to be written. In practice, the above-mentioned execution entity can, in response to the above-mentioned business operation type representing a non-deletion operation, encapsulate the above-mentioned updated business status data into the value of a cache entry, set the soft delete flag to false, and set the version number to the maximum value of the current version number of the main cache and the current version number of the backup cache plus one, to obtain the business information to be written. As an example, for a non-deletion operation, the version number = max(current version number of the main cache, current version number of the backup cache) + 1.

[0078] Sub-step seven involves comparing the current version number of the main cache with the version of the business information to be written or the tombstone information to be written, obtaining a version comparison result. In practice, the execution entity can generate a version comparison result indicating that the current version number of the main cache is lower if the current version number of the main cache is lower than the version number of the tombstone information or the business information to be written. Conversely, it can generate a version comparison result indicating that the current version number of the main cache is not lower if the current version number of the main cache is not lower than the version number of the tombstone information or the business information to be written.

[0079] Sub-step eight: In response to the version comparison result indicating that the current version number of the main cache is lower, the business information to be written or the tombstone information to be written is written to the main cache mapping table and the backup cache mapping table, resulting in an updated main cache mapping table and an updated backup cache mapping table. In practice, the execution entity can respond to the version comparison result indicating that the current version number of the main cache is lower by writing the business information to be written or the tombstone information to be written to the main cache mapping table and the backup cache mapping table, resulting in an updated main cache mapping table and an updated backup cache mapping table.

[0080] The above-mentioned technical content and related content, as an inventive point of this disclosure, solve the technical problem of "version conflict between snapshot data and playback messages, and incorrect retention of deleted data after recovery". The factors leading to version conflicts between snapshot data and playback messages, and the incorrect retention of deleted data after recovery, are often as follows: During the system restart and recovery phase, it is necessary to obtain business messages from the sequencer during downtime for state tracing. However, the traditional single-buffer linear playback method directly writes messages sequentially into a single buffer without comparing the global sequence number of the message with the version number of existing data in the buffer, resulting in version conflicts between snapshot data and playback messages, causing old data to overwrite new data. Simultaneously, the traditional playback method cannot correctly propagate the semantics of deletion operations; deletion operations are ignored or lost during playback, leading to the incorrect retention of deleted data after recovery. Solving these factors can avoid version conflicts between snapshot data and playback messages, and the incorrect retention of deleted data after recovery. To achieve this effect, firstly, the global sequence number of each business message to be replayed in the above-mentioned business information stream to be replayed is extracted to obtain a set of replay sequence numbers. Therefore, the timestamps of all information to be replayed can be obtained, providing a basis for subsequent filtering of processed messages and on-demand replay, avoiding version conflicts caused by repeated replay. Second, based on the aforementioned main cache mapping table, the local baseline sequence number is determined. This allows the determination of the maximum sequence number of processed messages in the main cache, serving as a filtering benchmark to prevent the repeated replay of expired messages. Third, based on the aforementioned set of sequence numbers to be replayed and the aforementioned local baseline sequence number, the set of valid sequence numbers is determined. This allows the filtering of valid sequence numbers greater than the local baseline sequence number, eliminating processed messages, ensuring that only incremental messages are replayed, and avoiding old data overwriting new data. Fourth, based on the aforementioned set of valid sequence numbers and the aforementioned business information flow to be replayed, the set of valid information to be replayed is determined. This allows the location of business messages that need to be replayed, avoiding interference from invalid messages, and ensuring that the replayed data is all the latest data to be processed. Fifth, the aforementioned set of valid information to be replayed is sorted to obtain the sequence of valid information to be replayed. This ensures that the replay order is consistent with the sequencer, avoiding inconsistencies in state caused by out-of-order replay. Sixth, for each valid piece of information to be replayed in the above valid replay information sequence, perform the following steps: First, generate an information payload and a current information sequence number based on the above valid replay information. This provides complete data input for subsequent queries, version comparisons, and writes. Second, perform a query operation in the above main cache mapping table and the above backup cache mapping table based on the above target key value to obtain the main cache hit result and the backup cache hit result. This allows us to obtain the existence status of the target key value in the main and backup caches, providing a basis for subsequent version number extraction. Third, determine the current version number of the main cache based on the above main cache hit result and the above main cache mapping table.Therefore, the version number of the data corresponding to the primary cache can be obtained and compared with the version number of the message to be written, preventing lower version data from overwriting higher version data. Next, based on the backup cache hit result and the backup cache mapping table, the current version number of the backup cache is determined. This allows the version number of the corresponding data in the backup cache to be obtained, ensuring that version arbitration considers both primary and backup cache data, avoiding erroneous overwriting due to missing backup cache versions. Then, in response to the above business operation type representing a deletion operation, a soft deletion marker and tombstone information to be written are generated. This transforms the deletion operation into a tombstone entry carrying an incrementing version number, ensuring that deletion semantics are correctly propagated during replay and preventing incorrect retention of deleted data after recovery. Then, in response to the above business operation type representing a non-deletion operation, the updated business status data is encapsulated to obtain the business information to be written. This generates a cache entry carrying the correct version number for add or modify operations. Finally, the current version number of the primary cache is compared with the business information to be written or the tombstone information to be written to obtain the version comparison result. Therefore, the larger of the current version number of the primary cache and the current version number of the secondary cache can be used as the current cache version number to determine whether the version of the message to be written is higher than the version of the existing data in the cache, preventing old data from overwriting new data. Finally, in response to the above version comparison result indicating that the current version number of the primary cache is lower, the above-mentioned business information or tombstone information to be written is written to the above-mentioned primary cache mapping table and the above-mentioned secondary cache mapping table, resulting in the updated primary cache mapping table and the updated secondary cache mapping table. Thus, data can be updated synchronously in the primary and secondary caches, ensuring that the dual cache states are consistent, while ensuring that higher version data correctly overwrites lower version data. Ultimately, this avoids version conflicts between snapshot data and replay messages, and prevents deleted data from being incorrectly retained after recovery.

[0081] Step 107: In response to receiving a query request for the target key value, extract the primary version data object and backup version data object corresponding to the query request based on the updated primary cache mapping table and the updated backup cache mapping table, and determine the target business status data based on the primary version data object and the backup version data object, so as to output the target business status data.

[0082] In some embodiments, the execution entity may, in response to receiving a query request for a target key value, extract the primary version data object and the backup version data object corresponding to the query request based on the updated primary cache mapping table and the updated backup cache mapping table, and determine the target business status data based on the primary version data object and the backup version data object, so as to output the target business status data. The query request may be a query instruction for a target key value during the operation of the business processing system, used to obtain the corresponding latest business status data.

[0083] In some optional implementations of certain embodiments, the execution entity may respond to a received query request for a target key value by performing the following steps: extracting the primary version data object and the backup version data object corresponding to the query request based on the updated primary cache mapping table and the updated backup cache mapping table; and determining the target business status data based on the primary version data object and the backup version data object, so as to output the target business status data. Step 1: In response to receiving a query request for the target key value, a lookup is performed in both the updated main cache mapping table and the updated standby cache mapping table to obtain the main cache lookup result and the standby cache lookup result. In practice, firstly, the executing entity can extract the target key value from the query request. Secondly, the entry corresponding to the target key value is searched in the updated main cache mapping table to obtain the main cache lookup result. Thirdly, the entry corresponding to the target key value is searched in the updated standby cache mapping table to obtain the standby cache lookup result. The main cache lookup result can include a hit or a miss. The standby cache lookup result can also include a hit or a miss. A hit indicates that an entry corresponding to the target key value exists in the cache mapping table. A miss indicates that an entry corresponding to the target key value does not exist in the cache mapping table.

[0084] Step two: Based on the primary cache lookup results and the backup cache lookup results, determine the primary version data object and the backup version data object. In practice, the execution entity can, in response to a primary cache lookup result indicating a hit, determine the entry corresponding to the target key value in the updated primary cache mapping table as the primary version data object. Similarly, in response to a backup cache lookup result indicating a hit, determine the entry corresponding to the target key value in the updated backup cache mapping table as the backup version data object. If the primary cache lookup result indicates a miss, generate a primary version data object with version number 0 and an empty key. Likewise, in response to a backup cache lookup result indicating a miss, generate a backup version data object with version number 0 and an empty key.

[0085] Step 3: Based on the aforementioned primary version data object and backup version data object, determine the candidate data object. In practice, the executing entity can compare the version numbers of the primary version data object and the backup version data object, and determine the data object with the larger version number as the candidate data object. As an example, in response to the primary version data object's version number being higher than the backup version data object's version number, the primary version data object can be determined as a candidate data object; in response to the primary version data object's version number being lower than the backup version data object's version number, the backup version data object can be determined as a candidate data object.

[0086] Step four: Based on the aforementioned candidate data objects, determine the target business status data. In practice, the executing entity can, in response to the presence of a soft delete flag indicating true in the aforementioned candidate data objects, set the aforementioned candidate data objects to null to obtain the target business status data. Conversely, in response to the presence of a soft delete flag indicating false in the aforementioned candidate data objects, determine the aforementioned candidate data objects as the target business status data.

[0087] Step five: Encapsulate the target business status data and output it. In practice, the executing entity can encapsulate the target business status data into a JSON file and send it to the client associated with the business processing system via a network communication protocol. The network communication protocol can be either HTTP or TCP / IP.

[0088] Step 108: Based on the updated backup cache mapping table, merge the updated main cache mapping table to obtain the merged main cache mapping table, and perform memory reorganization on the merged main cache mapping table based on the preset object pool.

[0089] In some embodiments, the execution entity may merge the updated primary cache mapping table according to the updated backup cache mapping table to obtain a merged primary cache mapping table, and then perform memory reorganization on the merged primary cache mapping table based on a preset object pool. The preset object pool may be a memory pool component in the business processing system used to manage the lifecycle of cache entry objects and implement object reuse to reduce garbage collection overhead. The memory reorganization may involve fragmenting the memory space occupied by the cache mapping table and resetting the object pool to release idle objects.

[0090] In some optional implementations of certain embodiments, the execution entity may merge the updated main cache mapping table according to the updated backup cache mapping table to obtain a merged main cache mapping table, and then perform memory reorganization on the merged main cache mapping table based on a preset object pool: Step one: In response to the arrival of the end-of-day settlement time, change the write permissions of the updated backup cache mapping table and the updated main cache mapping table. In practice, the executing entity can detect when the system clock of the business processing system reaches the end-of-day settlement time and modify the write permissions of the updated backup cache mapping table and the updated main cache mapping table to read-only mode. The system clock can be the operating system clock, the business scheduler clock, or a scheduled task trigger. The end-of-day settlement time can be the point at which key data, business results, and system status generated that day are comprehensively and statically recorded and saved at the end of each day's business or system operation.

[0091] Step two: Traverse the updated backup cache mapping table to obtain the sets of valid and invalid data records. Valid data records in the valid data record set can be business data in the updated backup cache mapping table that are not marked with a soft delete flag and whose data version number is higher than the corresponding key value in the updated main cache mapping table. Invalid data records in the invalid data record set can be business data in the updated backup cache mapping table that are marked with a soft delete flag or whose data version number is lower than the corresponding key value in the updated main cache mapping table.

[0092] Step three involves writing the aforementioned set of valid data records into the updated main cache mapping table and deleting the aforementioned set of invalid data records from the updated main cache mapping table, resulting in a merged main cache mapping table. In practice, the executing entity can, in response to the existence of a key-value pair corresponding to a valid data record in the updated main cache mapping table, replace the corresponding key-value pair in the updated main cache mapping table with the valid data record; and in response to the absence of a key-value pair corresponding to a valid data record in the updated main cache mapping table, insert the valid data record into the updated main cache mapping table. Then, the invalid data records corresponding to the aforementioned set of invalid data records are deleted from the updated main cache mapping table, resulting in a merged main cache mapping table.

[0093] Step four involves clearing the updated backup cache mapping table and invoking the preset object pool to reorganize the memory of the merged main cache mapping table. In practice, the execution entity can delete each entry in the updated backup cache mapping table. Next, the preset object pool can be invoked to obtain the current active object count and free object count, and to check for memory fragmentation and an excess of free objects. In response to memory fragmentation exceeding a threshold (e.g., 30%), the memory occupied by all free objects in the preset object pool is released, and the memory addresses of the merged main cache mapping table are rearranged to ensure contiguous data storage.

[0094] The above-described embodiments of this disclosure have the following beneficial effects: the primary and backup dual-caching data snapshot and recovery method for business processing systems, as described in some embodiments of this disclosure, can avoid business interruptions during snapshots, avoid inconsistencies in business state data, avoid incorrect data retention, and avoid system latency fluctuations. Specifically, the reasons for business interruptions, inconsistencies in business state data, incorrect data retention, and system latency fluctuations during snapshots are as follows: existing cache snapshot mechanisms require locking or completely copying running data when generating snapshots, leading to business thread blocking and increased business request latency in high-frequency, low-latency sensitive business scenarios, thus causing business interruptions during snapshots. When the system restarts, only a single snapshot is loaded and replayed, which can easily lead to data version conflicts between snapshot data and replay messages, resulting in inconsistent business states after recovery. Furthermore, traditional single-cache merging methods cannot correctly propagate the semantics of deletion operations, causing deleted data to be incorrectly retained after recovery. At the same time, high-frequency business updates lead to frequent creation and destruction of cache objects, which can easily cause heap memory pressure and garbage collection jitter, resulting in system latency fluctuations. Based on this, some embodiments of the present disclosure of a primary and backup dual-cached data snapshot and recovery method for a business processing system firstly, in response to receiving a snapshot trigger instruction, switch the references of the primary cache mapping table and the backup cache mapping table to obtain a swapped primary cache mapping table and a swapped backup cache mapping table. This allows business writes to be immediately switched to the swapped primary cache mapping table, eliminating lock contention and business thread blocking during snapshotting, achieving zero-pause snapshots, and avoiding business interruptions during snapshotting. Secondly, the swapped backup cache mapping table is serialized and encoded to obtain a target snapshot file set, and the target snapshot file set is stored in a preset snapshot storage directory. This allows the isolated swapped backup cache mapping table to be serialized and encoded, completely decoupling the snapshot file generation process from real-time business writes, avoiding additional impacts on business request delays. Thirdly, in response to detecting a system restart signal, the preset snapshot storage directory is traversed to extract the first snapshot file and the second snapshot file. This allows the extraction of the two snapshot files with the largest and second largest global sequence numbers, providing a redundant data foundation for subsequent dual-version data loading and version arbitration, avoiding state loss or inconsistency caused by loading only a single snapshot. Next, the first snapshot file and the second snapshot file are deserialized to obtain the first business status dataset and the second business status dataset. This allows the snapshot files on disk to be restored into the first and second business status datasets in memory, providing structured data input for subsequent concurrent loading and version comparison of primary and backup caches. Then, the first business status dataset is stored in the backup cache mapping table, and the second business status dataset is stored in the primary cache mapping table.Therefore, different versions of business status data can be loaded into the backup cache mapping table and the main cache mapping table respectively, achieving physical isolation between the two caches and creating conditions for version arbitration and correct propagation of deletion semantics during queries. Subsequently, in response to receiving the business information stream to be replayed during downtime, the main cache mapping table and the backup cache mapping table are updated in an orderly manner according to the global sequence number of the business information stream to be replayed, resulting in the updated main cache mapping table and the updated backup cache mapping table. Thus, the main and backup caches can be updated in an orderly manner according to the global sequence number, and the new data is prioritized through the version number increment comparison mechanism, which resolves the version conflict between snapshot data and replay information and ensures the consistency of business status after recovery. Then, in response to receiving a query request for a target key value, the main version data object and the backup version data object corresponding to the query request are extracted according to the updated main cache mapping table and the updated backup cache mapping table, and the target business status data is determined based on the main version data object and the backup version data object, so as to output the target business status data. Therefore, queries can always simultaneously check the primary and backup versions of the data object, arbitrate by version number, and detect soft deletion markers, ensuring that the target business status data output externally is always the latest and valid data, avoiding the erroneous retention of deleted data after recovery. Finally, based on the updated backup cache mapping table, the updated primary cache mapping table is merged to obtain a merged primary cache mapping table, and memory reorganization is performed on the merged primary cache mapping table based on a preset object pool. This releases memory fragmentation, reduces garbage collection jitter, and avoids system latency fluctuations. Ultimately, it avoids business interruptions during snapshots, inconsistencies in business status data, erroneous data retention, and system latency fluctuations.

[0095] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a primary / backup dual-buffer data snapshot and recovery device for a business processing system. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the primary and backup dual-buffer data snapshot and recovery device for business processing systems can be specifically applied to various electronic devices.

[0096] like Figure 2As shown, a primary and backup dual-buffer data snapshot and recovery device 200 for a business processing system includes: a reference switching unit 201, a serialization encoding processing unit 202, a traversal unit 203, a deserialization unit 204, a storage unit 205, an ordered playback update unit 206, an extraction unit 207, and a merging unit 208. The system includes the following components: a reference switching unit 201, configured to switch the references of the primary cache mapping table and the backup cache mapping table in response to receiving a snapshot trigger command, to obtain a swapped primary cache mapping table and a swapped backup cache mapping table; a serialization encoding processing unit 202, configured to perform serialization encoding processing on the swapped backup cache mapping table to obtain a target snapshot file set, and to store the target snapshot file set in a preset snapshot storage directory; a traversal unit 203, configured to traverse the preset snapshot storage directory in response to detecting a system restart signal, to extract a first snapshot file and a second snapshot file; a deserialization unit 204, configured to deserialize the first snapshot file and the second snapshot file to obtain a first service status dataset and a second service status dataset; and a storage unit 205, configured to store the first service status dataset in the backup cache mapping table and the second service status dataset in the primary cache mapping table. The table includes: an ordered replay update unit 206, configured to, in response to receiving a service information stream to be replayed during downtime, perform ordered replay updates on the main cache mapping table and the backup cache mapping table based on the global sequence number of the service information stream to be replayed, to obtain updated main cache mapping tables and updated backup cache mapping tables; an extraction unit 207, configured to, in response to receiving a query request for a target key value, extract the main version data object and backup version data object corresponding to the query request based on the updated main cache mapping table and the updated backup cache mapping table, and determine the target service status data based on the main version data object and the backup version data object, so as to output the target service status data; and a merging unit 208, configured to, based on the updated backup cache mapping table, merge the updated main cache mapping table to obtain a merged main cache mapping table, and perform memory reorganization on the merged main cache mapping table based on a preset object pool.

[0097] It is understandable that the units and references described in the primary and backup dual-buffer data snapshot and recovery device 200 for the business processing system are... Figure 1 The steps in the described method correspond accordingly. Therefore, the operations, features, and beneficial effects described above for the method also apply to the primary and backup dual-buffer data snapshot and recovery device 200 for business processing systems and the units contained therein, and will not be repeated here.

[0098] The following is for reference. Figure 3 It shows a method suitable for implementing this disclosure. Figure 1A schematic diagram of the structure of an electronic device 300 in some corresponding embodiments. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0099] like Figure 3 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory 302 or a program loaded from a storage device 308 into a random access memory 303. The random access memory 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, the read-only memory 302, and the random access memory 303 are interconnected via a bus 304. An input / output interface 305 is also connected to the bus 304.

[0100] Typically, the following devices can be connected to the input / output interface 305: input devices 306 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 307 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 308 including, for example, magnetic tape, hard disk, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0101] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 309, or installed from a storage device 308, or installed from a read-only memory 302. When the computer program is executed by the processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0102] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0103] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0104] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: in response to receiving a snapshot trigger instruction, switch references between the primary cache mapping table and the backup cache mapping table to obtain a swapped primary cache mapping table and a swapped backup cache mapping table; perform serialization encoding on the swapped backup cache mapping table to obtain a target snapshot file set, and store the target snapshot file set in a preset snapshot storage directory; in response to detecting a system restart signal, traverse the preset snapshot storage directory to extract a first snapshot file and a second snapshot file; deserialize the first snapshot file and the second snapshot file to obtain a first service state dataset and a second service state dataset; store the first service state dataset in the backup cache mapping table, and store the second service state dataset in... The data is stored in the aforementioned main cache mapping table. In response to receiving a service information stream to be replayed during downtime, the main cache mapping table and the backup cache mapping table are updated in an orderly manner based on the global sequence number of the service information stream to be replayed, resulting in an updated main cache mapping table and an updated backup cache mapping table. In response to receiving a query request for a target key-value pair, the main version data object and backup version data object corresponding to the query request are extracted based on the updated main cache mapping table and the updated backup cache mapping table. The target service status data is then determined based on the main version data object and the backup version data object, and the target service status data is output. The updated main cache mapping table is merged based on the updated backup cache mapping table to obtain a merged main cache mapping table. Finally, the merged main cache mapping table is reorganized in memory based on a preset object pool.

[0105] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0107] The units described in some embodiments of this disclosure can be implemented in software or in hardware. The described units can also be located in a processor.

[0108] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0109] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for primary and backup dual-buffer data snapshot and recovery in a business processing system, characterized in that, include: In response to receiving a snapshot trigger command, the references of the primary cache mapping table and the backup cache mapping table are switched to obtain the swapped primary cache mapping table and the swapped backup cache mapping table. The exchanged backup cache mapping table is serialized and encoded to obtain a target snapshot file set, and the target snapshot file set is stored in a preset snapshot storage directory; In response to the detection of a system restart signal, the preset snapshot storage directory is traversed to extract the first snapshot file and the second snapshot file; Deserialize the first snapshot file and the second snapshot file to obtain the first business status dataset and the second business status dataset. The first business status dataset is stored in the backup cache mapping table, and the second business status dataset is stored in the main cache mapping table; In response to receiving a service information stream to be replayed during downtime, the main cache mapping table and the backup cache mapping table are updated in an orderly manner according to the global sequence number of the service information stream to be replayed, so as to obtain the updated main cache mapping table and the updated backup cache mapping table. In response to receiving a query request for a target key value, the main version data object and the backup version data object corresponding to the query request are extracted according to the updated main cache mapping table and the updated backup cache mapping table. The target business status data is determined according to the main version data object and the backup version data object, and the target business status data is output. Based on the updated backup cache mapping table, the updated main cache mapping table is merged to obtain a merged main cache mapping table, and based on a preset object pool, the merged main cache mapping table is reorganized in memory.

2. The method according to claim 1, characterized in that, The step of responding to a snapshot trigger command by switching the references of the primary cache mapping table and the backup cache mapping table to obtain the swapped primary cache mapping table and the swapped backup cache mapping table includes: In response to receiving a snapshot trigger instruction, the current reference address of the main cache mapping table and the current reference address of the backup cache mapping table are read to obtain a first reference address and a second reference address, and a set of addresses to be swapped is generated based on the first reference address and the second reference address; Based on the set of addresses to be exchanged, a temporary reference address variable is constructed, and the first reference address is written into the temporary reference address variable as a temporary storage address; The second reference address is assigned to the reference pointer of the main cache mapping table to generate the swapped main cache mapping table; The temporary storage address is assigned to the reference pointer of the backup cache mapping table to generate the swapped backup cache mapping table.

3. The method according to claim 1, characterized in that, The step of serializing and encoding the swapped backup cache mapping table to obtain a target snapshot file set, and storing the target snapshot file set to a preset snapshot storage directory, includes: Extract the service status records to be serialized from the exchange backup cache mapping table to obtain the service status record set to be serialized; Extract the original version number and global sequence number of each business status record to be serialized from the business status record set to be serialized, and use them as metadata snapshot information to obtain a metadata snapshot information set; Based on the metadata snapshot information set, the set of business status records to be serialized is converted into binary stream encoding to obtain a set of serialized byte streams. Generate a set of target snapshot file names based on the current business identifier and metadata snapshot information set; An initial set of snapshot files is generated based on the target snapshot file name set and the serialized byte stream set; Cyclic redundancy check is performed on each initial snapshot file in the initial snapshot file set to obtain a check value set, and the check value set is merged with the initial snapshot file set to obtain the target snapshot file set; Store the target snapshot file set to a preset snapshot storage directory.

4. The method according to claim 1, characterized in that, In response to detecting a system restart signal, traversing the preset snapshot storage directory to extract the first snapshot file and the second snapshot file includes: Read the file system inode list of the preset snapshot storage directory to obtain a set of candidate snapshot file names; The candidate snapshot file name set is matched and filtered to obtain the valid snapshot file name set; Extract the global sequence number of each valid snapshot file name from the set of valid snapshot file names, and use it as sequence number metadata to obtain the sequence number metadata dataset; Sort the sequence number metadata dataset in descending order to obtain the sequence number metadata sequence; The first snapshot file name and the second snapshot file name are determined based on the sequence number metadata sequence; Based on the first snapshot file name and the second snapshot file name, locate the corresponding snapshot file in the preset snapshot storage directory to obtain the first snapshot file and the second snapshot file.

5. The method according to claim 1, characterized in that, In response to receiving a query request for a target key value, the system extracts the primary version data object and the backup version data object corresponding to the query request based on the updated primary cache mapping table and the updated backup cache mapping table, and determines the target business status data based on the primary version data object and the backup version data object, so as to output the target business status data, including: In response to receiving a query request for a target key value, a lookup is performed in the updated main cache mapping table and the updated standby cache mapping table to obtain the main cache lookup result and the standby cache lookup result. Based on the primary cache lookup result and the backup cache lookup result, determine the primary version data object and the backup version data object; Based on the primary version data object and the backup version data object, candidate data objects are determined; Based on the candidate data objects, determine the target business status data; The target service status data is encapsulated and then output.

6. The method according to claim 1, characterized in that, The step of deserializing the first snapshot file and the second snapshot file to obtain the first business status dataset and the second business status dataset includes: Obtain the file header information of the first snapshot file and the second snapshot file to obtain the file header information set; Based on the file header information set, extract the file internal checksums of the first snapshot file and the second snapshot file to obtain the file internal checksum set; Cyclic redundancy check is performed on the first snapshot file and the second snapshot file to obtain a real-time check value set; Based on the file's internal checksum set and the real-time checksum set, an integrity check result is generated; In response to the integrity verification result indicating data integrity, the serialized byte stream of the first snapshot file is extracted to obtain a first serialized byte stream, and the serialized byte stream of the second snapshot file is extracted to obtain a second serialized byte stream; The first serialized byte stream and the second serialized byte stream are decoded and converted to obtain a first original key-value pair set and a second original key-value pair set; Based on the first original key-value pair set and the second original key-value pair set, generate a first meta-dataset and a second meta-dataset; Based on the first metadata, the first original key-value pair set is cleaned and reconstructed to obtain the first business status dataset. Based on the second metadata, the second original key-value pair set is cleaned and reconstructed to obtain the second business status dataset.

7. A primary / backup dual-buffer data snapshot and recovery device for a business processing system, characterized in that, include: The reference switching unit is configured to switch the references of the primary cache mapping table and the standby cache mapping table in response to receiving a snapshot trigger command, so as to obtain the swapped primary cache mapping table and the swapped standby cache mapping table. The serialization encoding processing unit is configured to perform serialization encoding processing on the exchanged backup cache mapping table to obtain a target snapshot file set, and to store the target snapshot file set in a preset snapshot storage directory; The traversal unit is configured to traverse the preset snapshot storage directory in response to the detection of a system restart signal to extract the first snapshot file and the second snapshot file; The deserialization unit is configured to deserialize the first snapshot file and the second snapshot file to obtain a first business state dataset and a second business state dataset. The storage unit is configured to store the first service status dataset in the backup cache mapping table and the second service status dataset in the main cache mapping table; The ordered replay update unit is configured to, in response to receiving a service information stream to be replayed during a downtime, perform ordered replay updates on the main cache mapping table and the backup cache mapping table according to the global sequence number of the service information stream to be replayed, to obtain the updated main cache mapping table and the updated backup cache mapping table. The extraction unit is configured to, in response to receiving a query request for a target key value, extract the primary version data object and the backup version data object corresponding to the query request according to the updated primary cache mapping table and the updated backup cache mapping table, and determine the target business status data according to the primary version data object and the backup version data object, so as to output the target business status data. The merging unit is configured to merge the updated primary cache mapping table according to the updated backup cache mapping table to obtain a merged primary cache mapping table, and to perform memory reorganization on the merged primary cache mapping table based on a preset object pool.

Images