Flink checkpoint backup method and apparatus

Abstract

The present disclosure provides a Flink checkpoint backup method and device, the method comprising: obtaining task identification information and checkpoint storage root path of a Flink task; traversing snapshot files under the checkpoint storage root path, screening out valid snapshot files, and performing incremental identification and deduplication verification based on the snapshot serial number of the valid snapshot files and the task identification information; assembling the file full path of the valid snapshot files that pass the verification and the task identification information into a backup task message, and pushing the backup task message to a buffer queue of a distributed cache; and dispatching to an idle worker thread in a corresponding consumer thread pool; analyzing the backup task message through the idle worker thread, constructing a redundant backup target path, and performing cross-storage redundant backup. Thus, through incremental identification and deduplication verification of valid snapshot files and cross-storage redundant replication, the checkpoint backup is completed without stopping the Flink task, and the single-point storage failure risk is eliminated.

Description

Technical Field

[0001] This disclosure relates to the field of big data service technology, and in particular to a Flink checkpoint backup method and apparatus. Background Technology

[0002] Apache Flink (hereinafter referred to as Flink) is an open-source distributed stream processing framework that uses a checkpoint mechanism based on the distributed snapshot algorithm (Chandy-Lamport) to achieve fault tolerance. It periodically persists the operator state to a remote storage system, so that the task can recover from the most recently completed checkpoint when a failure occurs, thereby ensuring data consistency and business continuity.

[0003] In related technologies, Flink's checkpoint mechanism persistently stores checkpoint data to a single remote storage system, and its lifecycle is automatically managed by the system according to preset thresholds. This makes it difficult for users to flexibly control backup and retention strategies, leading to a single point of failure risk for checkpoint data and failing to meet the differentiated backup needs of various business scenarios. Furthermore, when users need to create additional backups for Flink tasks to cope with version upgrades or task migrations, they must stop the task, manually copy files or trigger savepoints, and then restart the task, causing data processing interruptions and failing to meet the continuity requirements of real-time business operations. Summary of the Invention

[0004] This disclosure provides a Flink checkpoint backup method and apparatus to at least partially solve one of the technical problems in related technologies. The technical solution of this disclosure is as follows: According to a first aspect of the present disclosure, a Flink checkpoint backup method is provided, comprising: obtaining task identification information and checkpoint storage root path of a Flink task; traversing snapshot files under the checkpoint storage root path, filtering out valid snapshot files that conform to a preset naming rule, and parsing out the snapshot sequence number of the valid snapshot file; performing incremental identification and deduplication verification on the valid snapshot file based on the task identification information and snapshot sequence number, assembling the full file path of the valid snapshot file that passes the verification with the task identification information into a backup task message, and pushing it to the buffer queue of a distributed cache; pulling the backup task message from the buffer queue of the distributed cache and dispatching it to an idle worker thread in the corresponding consumer thread pool; and parsing the backup task message through the idle worker thread to construct a redundant backup target path for cross-storage redundant backup.

[0005] According to a second aspect of the present disclosure, a Flink checkpoint backup apparatus is provided, comprising: an acquisition module, configured to acquire task identification information and checkpoint storage root path of a Flink task; a verification module, configured to traverse snapshot files under the checkpoint storage root path, filter out valid snapshot files that conform to a preset naming rule, and parse out the snapshot sequence number of the valid snapshot file; perform incremental identification and deduplication verification on the valid snapshot file based on the task identification information and the snapshot sequence number, assemble the full file path of the valid snapshot file that passes the verification with the task identification information into a backup task message, and push it to the buffer queue of a distributed cache; a dispatch module, configured to pull the backup task message from the buffer queue of the distributed cache and dispatch it to an idle worker thread in the corresponding consumer thread pool; and a backup module, configured to parse the backup task message through the idle worker thread, construct a redundant backup target path, and perform cross-storage redundant backup.

[0006] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the Flink checkpoint backup method as described in the first aspect of the present disclosure.

[0007] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the Flink checkpoint backup method as described in the first aspect of the present disclosure.

[0008] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the Flink checkpoint backup method as described in the first aspect of the present disclosure.

[0009] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: In this technical solution, a list of running Flink tasks is obtained, and the task identifier information and checkpoint storage root path of each Flink task are extracted. Snapshot files under the checkpoint storage root path are traversed, and valid snapshot files conforming to preset naming rules are selected, with their snapshot sequence numbers parsed. Based on the task identifier information and snapshot sequence number, incremental identification and deduplication verification are performed on the valid snapshot files. The full file path of the verified valid snapshot files is assembled with the task identifier information into a backup task message, which is pushed to the buffer queue of the distributed caching system. Backup task messages are pulled from the buffer queue and dispatched to idle worker threads in the consumer thread pool. Idle worker threads parse the backup task messages to construct redundant backup target paths for cross-storage redundant backup. Thus, this method decouples the discovery and backup execution of checkpoint snapshots through a distributed buffer queue, avoids duplicate backups through incremental identification and deduplication verification, and eliminates the risk of single-point storage failures by combining cross-storage redundant replication. It achieves checkpoint backup without stopping Flink tasks and supports flexible management of the number of backups.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0012] Figure 1 This is a flowchart illustrating the Flink checkpoint backup method shown in the first embodiment of this disclosure; Figure 2 This is a flowchart illustrating the Flink checkpoint backup method according to the second embodiment of this disclosure; Figure 3 This is a flowchart illustrating the Flink checkpoint backup method according to the third embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of the Flink checkpoint backup device shown in the fourth embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0014] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data used can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0015] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the technical solution disclosed herein are all carried out with the consent of the user, and all comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0016] Apache Flink (hereinafter referred to as Flink) is an open-source distributed stream processing framework that uses a checkpoint mechanism based on the distributed snapshot algorithm (Chandy-Lamport) to achieve fault tolerance. It periodically persists the operator state to a remote storage system, so that the task can recover from the most recently completed checkpoint when a failure occurs, thereby ensuring data consistency and business continuity.

[0017] In related technologies, Flink's checkpoint mechanism persistently stores checkpoint data to a single remote storage system, and its lifecycle is automatically managed by the system according to preset thresholds. This makes it difficult for users to flexibly control backup and retention strategies, leading to a single point of failure risk for checkpoint data and failing to meet the differentiated backup needs of various business scenarios. Furthermore, when users need to create additional backups for Flink tasks to cope with version upgrades or task migrations, they must stop the task, manually copy files or trigger savepoints, and then restart the task, causing data processing interruptions and failing to meet the continuity requirements of real-time business operations.

[0018] The Flink checkpoint backup method and apparatus according to embodiments of the present disclosure are described below with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart illustrating the Flink checkpoint backup method shown in the first embodiment of this disclosure.

[0020] like Figure 1 As shown, the Flink checkpoint backup method includes the following steps: Step 101: Obtain the task identifier information and checkpoint storage root path of the Flink task.

[0021] It should be noted that: In this embodiment, one method for obtaining the task identifier information and checkpoint storage root path of a Flink task is as follows: A list of currently running Flink tasks is obtained through periodic scanning by a scheduled task; for each Flink task in the list, the task identifier information and the corresponding checkpoint storage root path are extracted, where the checkpoint storage root path serves as the scanning entry point for snapshot file traversal. Obtaining the task identifier information and checkpoint storage root path of running Flink tasks through periodic scanning by a scheduled task enables batch collection of the unique identifier and snapshot file scanning entry path of each Flink task, providing a basic data source for subsequent batch traversal of the snapshot files corresponding to each task.

[0022] As an example, a scan can be triggered every 30 seconds using a scheduled task. The system maintains a set of running task caches (TimedCache) with a timeout of 10 minutes. Newly discovered running tasks are merged and assembled with historical tasks to ensure that no newly started or running Flink tasks are missed. For each Flink task, the system obtains its unique primary key ID from the task database as the task identifier, as well as the corresponding checkpoint storage root path, such as the Hadoop Distributed File System (HDFS) path / flink / flink-checkpoints / {jobId} / , which serves as the entry point for subsequent scanning steps.

[0023] Step 102: Traverse the snapshot files under the root path of the checkpoint storage, filter out valid snapshot files that conform to the preset naming rules, and parse out the snapshot sequence number of the valid snapshot file; perform incremental identification and deduplication verification on the valid snapshot file based on the task identification information and the snapshot sequence number, assemble the full file path of the valid snapshot file that passes the verification with the task identification information into a backup task message, and push it to the buffer queue of the distributed cache.

[0024] In this embodiment, the preset naming rule is: filenames contain the prefix "chk-" and the suffix "_metadata". When traversing snapshot files under the root path of the checkpoint storage, the system recursively scans all subdirectories under the root path of the checkpoint storage, filters out files that simultaneously meet the above naming rule as valid snapshot files, and parses the snapshot sequence number from the filename using the regular expression chk-(\d+). Incremental identification is used to filter snapshot files that have already been backed up, that is, by comparing the current snapshot sequence number with the maximum snapshot sequence number that the task has backed up in the distributed cache, if the current sequence number is greater than the maximum sequence number, it is determined to be a new snapshot; deduplication verification is used to filter valid snapshot files that are being processed by other threads, that is, by querying whether there is a processed tag in the distributed cache with the task identifier information and the snapshot sequence number as the joint key, if it does not exist, it is determined to pass the deduplication verification.

[0025] As an example, the system uses a path scanning thread pool configured with core and maximum thread limits for multi-threaded concurrent processing. Each processing thread recursively traverses the checkpoint remote storage directory (checkpoint storage root path) corresponding to the Flink job ID using a distributed file system tool (such as HdfsUtils), retrieving all file status information. For example, for the Flink Job ID job_123456, it filters out tasks that match the chk- After obtaining a valid snapshot file according to the _metadata naming rule, the snapshot sequence number 100 is parsed using the regular expression chk-(\d+). The system retrieves the maximum snapshot sequence number that has been backed up for this Flink Job ID from the distributed cache (Remote Dictionary Server (Redis) hash structure: flink-check-point-mun-map). If the current sequence number 100 is greater than the maximum backed-up sequence number 95, incremental identification is performed. At the same time, it checks whether there is an anti-duplicate exclusive lock set for this snapshot sequence number in Redis (key: flink-check-point-path:job_123456:100). If it does not exist, deduplication verification is performed. After successful verification, the task database primary key ID, Flink Job ID, and the full path of the valid snapshot file are concatenated using the separator (##) to form a standardized message (format: ID##FlinkJobId##Path). This message is then pushed to the head of the distributed cache buffer queue (Redis list data structure: flink-check-point-list) through an atomic Left Push operation, achieving efficient decoupling between snapshot file discovery and subsequent transfer.

[0026] Step 103: Retrieve backup task messages from the distributed cache's buffer queue and dispatch them to the idle worker threads in the corresponding consumer thread pool.

[0027] In this embodiment, a single-threaded, continuously running main loop for consumption processing can be started in the background to monitor the buffer queue and regulate the consumption thread pool in real time. Before each pull operation is executed, the current number of active threads in the consumption thread pool is monitored in real time, and the pull speed is dynamically adjusted or sleep waiting is executed according to the load. Successfully pulled backup task messages are dispatched to idle worker threads in the consumption thread pool.

[0028] As an example, the main loop thread for consumption processing is named `thread-checkpoint-processor`, and the consumption thread pool (`threadPoolForRedis`) is configured with 3 core threads, a maximum of 20 threads, a queue capacity of 10, and an idle lifespan of 30 seconds. Before each dequeue, the main loop queries the current active thread count (`activeCount`) of the consumption thread pool in real time and executes differentiated dequeue and sleep strategies based on the load. When the active thread count has not reached the maximum thread count of 20, an atomic `Right Pop` operation is performed on the `RedisList` to retrieve the tail message. If the popped backup task message is empty (the queue currently has no valid snapshot files to process), a long sleep of 1000 milliseconds is initiated. If the popped backup task message is not empty, the backup task message is encapsulated and submitted to the consumption thread pool for backup processing. The main loop then enters a short sleep of 10 milliseconds before continuing the next round of dequeueing. If the current active thread count has reached the maximum of 20, indicating that consumption processing is at full load, the main loop enters a moderate sleep of 500 milliseconds, waiting for existing threads to be released before resuming scheduling.

[0029] Step 104: Parse the backup task message using an idle worker thread and construct a redundant backup target path to perform cross-storage redundant backup.

[0030] In this embodiment, one approach to cross-storage redundancy backup is as follows: A backup task message is parsed using an idle worker thread to extract the full file path and task identifier information; a redundant backup target path is constructed by concatenating the preset backup root path, task identifier information, and the relative path portion of the full file path; and a distributed file system interface is invoked to asynchronously and recursively copy the valid snapshot file pointed to by the full file path to the redundant backup target path, thus performing cross-storage redundancy backup. By parsing the backup task message and generating the redundant backup target path using an idle worker thread, and then calling the distributed file system interface to perform asynchronous recursive copying of the valid snapshot file, cross-storage redundancy backup of snapshot files can be achieved, improving the backup efficiency and disaster recovery capabilities of snapshot data.

[0031] As an example, the idle worker thread uses the separator (##) to parse and extract the task ID, Flink Job ID, and full file path, and extracts the snapshot sequence number (chkNum) from them. Based on the system's preset physical backup root path (flinkSavePointPath, such as / flink / flink-savepoints / ) and rules, it constructs a redundant backup target path on the distributed file system, in the format {flinkSavePointPath} / checkpoints / {flinkJobId} / {relativePath}. The distributed file system interface (hdfsUtils.copyFiles) is called to recursively copy and persistently store the valid snapshot file and its associated data to the target redundant backup path. The full file path and the physical backup root path can reside on different nodes within the same HDFS cluster, or they can reside in completely different distributed file system clusters (e.g., the source is HDFS cluster A, and the physical backup root path is HDFS cluster B or Amazon S3), thus achieving high-availability backup independent of a local physical point of failure.

[0032] In addition, after asynchronously and recursively copying the valid snapshot file pointed to by the full path of the file to the redundant backup target path, the process also includes: storing the task identification information, snapshot sequence number, and redundant backup target path corresponding to the valid snapshot file in the business database; wherein, the task identification information is used to associate the corresponding Flink task, and the snapshot sequence number is used to distinguish valid snapshot files of different versions under the same Flink task; the redundant backup target path stored in the business database is used to locate the redundant backup file pointed to by the redundant backup target path to perform fault recovery when a Flink task fails. This enables persistent retention of backup metadata, and relying on the metadata's association and differentiation capabilities, it can quickly locate redundant backup files when a Flink task fails, supporting Flink task fault recovery operations.

[0033] In this embodiment, after performing cross-storage redundancy backup, the snapshot sequence number of the valid snapshot file that completed the cross-storage redundancy backup is used as the current snapshot sequence number. The maximum backed-up snapshot sequence number corresponding to the task identifier information in the distributed cache is updated to the current snapshot sequence number. The maximum backed-up snapshot sequence number is used for subsequent incremental identification and deduplication verification, comparing it with the snapshot sequence number of the valid snapshot file to be verified, filtering out valid snapshot files that have already been backed up. Using the task identifier information and the snapshot sequence number as a joint key, a processed mark is written to the distributed cache, and a preset expiration time is set. The processed mark is available for querying in the incremental identification and deduplication verification steps within the preset expiration time, so as to skip valid snapshot files with processed marks. Incremental identification and deduplication verification can be completed quickly with the help of caching, avoiding repeated backups of the same valid snapshot files and reducing unnecessary backup overhead.

[0034] As an example, after cross-storage redundancy backup is completed, idle worker threads extract task identification information, snapshot sequence number, full file path of valid snapshot files, and redundancy backup target path as backup metadata, and persist this set of metadata into the business database. This backup metadata includes at least: task identification information, snapshot sequence number, full file path of valid snapshot files, and redundancy backup target path, which can be retrieved by upper-layer business systems and supports Flink task failure recovery based on specified snapshots. Simultaneously, in Redis Hash (Flink... check point mun In the `map`, update the latest processed snapshot sequence number corresponding to the Flink Job ID to the current snapshot sequence number; write an deduplication lock (Key: flink) with a TTL expiration time (preferably 3 minutes) to Redis. check point path:{JobId}:{num}), to prevent concurrent duplicate data transfers.

[0035] Furthermore, this disclosure can also count the total number of backups stored in the business database corresponding to each task identifier information according to a preset period; when the total number of backups exceeds a preset maximum retention threshold, calculate the snapshot sequence number threshold to be cleaned; query and delete backup records in the business database whose snapshot sequence numbers are less than the snapshot sequence number threshold to be cleaned; and call the distributed file system interface to physically delete the snapshot files under the redundant backup target path corresponding to the backup records. By counting the total number of backups corresponding to each task identifier according to a preset period, determining the snapshot sequence number threshold to be cleaned when it exceeds the preset maximum retention threshold, and synchronously cleaning up backup records in the business database and snapshot files in the distributed file system, this disclosure can automatically manage the storage scale of backup data, clean up expired backups, and save storage resources.

[0036] As an example, the system is configured with a maximum allowed number of backups to be saved (flinkSaveMax, e.g., set to 10). The system periodically (preferably every 30 seconds) retrieves the latest backup sequence number of each running Flink task. If the total number of backups exceeds the set maximum retention threshold, the system calculates the number of backups to be deleted: needDeleteNum = flinkJobMaxNum - flinkSaveMax. It then queries the database for historical backup records with snapshot sequence numbers less than needDeleteNum, deletes the corresponding entries from the business database in batches, and simultaneously calls the file system interface to physically delete expired historical snapshot directories on the distributed file system (hdfsUtils.delete(paths)), thus achieving automatic release and flexible management of storage space.

[0037] In summary, this method obtains a list of running Flink tasks and extracts the task identifier information and checkpoint storage root path for each task. It then iterates through snapshot files under the checkpoint storage root path, filters out valid snapshot files that conform to preset naming rules, and parses out the snapshot sequence number of each valid snapshot file. Based on the task identifier information and snapshot sequence number, it performs incremental identification and deduplication verification on the valid snapshot files. The full file path of the verified valid snapshot files is then assembled with the task identifier information into a backup task message, which is pushed to the buffer queue of the distributed caching system. Backup task messages are pulled from the buffer queue and dispatched to idle worker threads in the consumer thread pool. The idle worker threads parse the backup task messages to construct redundant backup target paths for cross-storage redundant backup. Therefore, this method decouples the discovery and backup execution of checkpoint snapshots through a distributed buffer queue, avoids duplicate backups through incremental identification and deduplication verification, and eliminates the risk of single-point storage failures by combining cross-storage redundant replication. This achieves checkpoint backup without stopping Flink tasks and supports flexible management of the number of backups.

[0038] To clearly illustrate how the above embodiments perform incremental identification and deduplication verification of valid snapshot files based on task identification information and snapshot sequence number, assemble the full file path of the verified valid snapshot file and task identification information into a backup task message, and push it to the buffer queue of the distributed cache, this disclosure proposes another Flink checkpoint backup method.

[0039] Figure 2 This is a flowchart illustrating the Flink checkpoint backup method shown in the second embodiment of this disclosure.

[0040] like Figure 2 As shown, the Flink checkpoint backup method includes the following steps: Step 201: Obtain the task identifier information and checkpoint storage root path of the Flink task.

[0041] Step 202: Traverse the snapshot files under the root path of the checkpoint storage, filter out valid snapshot files that conform to the preset naming rules, and parse out the snapshot sequence number of the valid snapshot file.

[0042] Step 203: Compare the snapshot sequence number with the maximum snapshot sequence number that has been backed up corresponding to the task identification information in the distributed cache. If the snapshot sequence number is less than or equal to the maximum snapshot sequence number, it is determined that the valid snapshot file has not passed the incremental identification and the valid snapshot file is skipped.

[0043] In this embodiment, incremental identification is used to filter valid snapshot files that have already been backed up. The distributed cache stores the maximum snapshot sequence number that the Flink task has backed up. By comparing the currently parsed snapshot sequence number with the maximum snapshot sequence number, if the current sequence number is less than or equal to the maximum sequence number, it means that the valid snapshot file has already been backed up, and it is determined that it has failed incremental identification and is skipped; if the current sequence number is greater than the maximum sequence number, it means that the valid snapshot file is a newly added valid snapshot file that has not yet been backed up, and it proceeds to the deduplication verification step after passing incremental identification.

[0044] As an example, suppose the maximum snapshot sequence number of the task job_123456 recorded in the distributed cache (Redis Hash structure: flink-check-point-mun-map) is 95. The currently traversed valid snapshot file is / flink / flink-checkpoints / job_123456 / chk-88 / _metadata, and the parsed snapshot sequence number is 88. Since 88 is less than 95, the system determines that this valid snapshot file has already been backed up and skips it directly, without performing subsequent deduplication verification and backup processing. If the current snapshot sequence number is 100, since 100 is greater than 95, the system determines that this valid snapshot file is a newly added snapshot file, and proceeds to step 204 after incremental identification.

[0045] Step 204: If the snapshot sequence number is greater than the maximum snapshot sequence number, query the distributed cache for a corresponding processed mark using the task identifier information and the snapshot sequence number as the joint key. If a processed mark exists, it is determined that the valid snapshot file has not passed the deduplication check and the valid snapshot file is skipped.

[0046] In this embodiment, deduplication verification is used to filter snapshot files that are being processed by other threads. Using the combination of task identifier information and snapshot sequence number as a joint key, the system queries the distributed cache to see if a corresponding "processed" marker exists. If the marker exists, it indicates that the valid snapshot file is being processed by other consumer threads or has been marked as processed. To prevent concurrent duplicate data transfer, the deduplication verification fails, and the valid snapshot file is skipped. If the marker does not exist, the deduplication verification passes, and the process proceeds to step 205.

[0047] As an example, the system uses the task identifier job_123456 and snapshot sequence number 100 as the combined key to query whether a corresponding processed mark exists in Redis (an exclusive lock with the key flink-check-point-path:job_123456:100). If the key exists (possibly because the TTL has not expired, another thread is processing it, or it has been processed but the mark has not expired), the valid snapshot file is determined to have failed the deduplication check, and the valid snapshot file is skipped to avoid duplicate backups. If the key does not exist, the deduplication check is determined to have passed, and the process proceeds to step 205.

[0048] Step 205: If there is no processed marker, the valid snapshot file is determined to have passed the verification. The full file path of the valid snapshot file and the task identifier information are assembled into a backup task message and pushed to the buffer queue of the distributed cache.

[0049] In this embodiment of the disclosure, a valid snapshot file is considered to have passed verification only if it simultaneously passes incremental identification (the current sequence number is greater than the historical maximum sequence number) and deduplication verification (no processed markers exist). After successful verification, the full file path and task identification information are assembled into a backup task message, which is then pushed to the buffer queue of the distributed cache through atomic operations.

[0050] As an example, for a valid snapshot file that passes double-checking, the task database primary key ID (e.g., 12345), Flink Job ID (e.g., job_123456), and the full file path (e.g., / flink / flink-checkpoints / job_123456 / chk-100 / _metadata) are concatenated using the delimiter ## to form a standardized message text (format: The data (12345##job_123456## / flink / flink-checkpoints / job_123456 / chk-100 / _metadata) is pushed to the head of the Redis List (flink-check-point-list) via an atomic Left Push operation, waiting for the consumer thread to pull and process it.

[0051] Step 206: Retrieve backup task messages from the buffer queue of the distributed cache and dispatch them to the idle worker threads in the corresponding consumer thread pool.

[0052] Step 207: Parse the backup task message using an idle worker thread and construct a redundant backup target path to perform cross-storage redundant backup.

[0053] It should be noted that the execution processes of steps 201 to 202 and steps 206 to 207 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit these processes and will not elaborate further.

[0054] In summary, the process involves: obtaining the task identifier information and checkpoint storage root path of the Flink task; traversing the snapshot files under the checkpoint storage root path, filtering out valid snapshot files that conform to the preset naming rules, and parsing out the snapshot sequence number of the valid snapshot file; comparing the snapshot sequence number with the maximum backup snapshot sequence number corresponding to the task identifier information in the distributed cache; if the snapshot sequence number is less than or equal to the maximum snapshot sequence number, the valid snapshot file is determined to have failed incremental identification and is skipped; if the snapshot sequence number is greater than the maximum snapshot sequence number, querying the distributed cache for a corresponding processed mark using the task identifier information and the snapshot sequence number as a joint key; if a processed mark exists, the valid snapshot file is determined to have failed deduplication verification and is skipped; if no processed mark exists, the valid snapshot file is determined to have passed verification, and the full file path of the valid snapshot file and the task identifier information are assembled into a backup task message and pushed to the buffer queue of the distributed cache; pulling the backup task message from the buffer queue of the distributed cache and dispatching it to the idle worker thread in the corresponding consumer thread pool; and using the idle worker thread to parse the backup task message and construct a redundant backup target path for cross-storage redundant backup. Therefore, incremental identification is completed by comparing the sequence number of the largest backed-up snapshot in the distributed cache, and deduplication verification is achieved by combining the processed mark of the joint key. The valid snapshot file that passes the verification is encapsulated into a backup task message and sent to the buffer queue for idle worker threads to perform cross-storage redundant backup. This realizes incremental deduplication backup of valid snapshot files in Flink, avoids the resource consumption caused by repeated backups, and improves the overall processing efficiency of snapshot backup.

[0055] To clearly illustrate how backup task messages are retrieved from the distributed cache's buffer queue and dispatched to idle worker threads in the corresponding consumer thread pool in the above embodiments, this disclosure proposes another Flink checkpoint backup method.

[0056] Figure 3 This is a flowchart illustrating the Flink checkpoint backup method according to the third embodiment of this disclosure.

[0057] like Figure 3 As shown, the Flink checkpoint backup method includes the following steps: Step 301: Obtain the task identifier information and checkpoint storage root path of the Flink task.

[0058] Step 302: Traverse the snapshot files under the root path of the checkpoint storage, filter out valid snapshot files that conform to the preset naming rules, and parse out the snapshot sequence number of the valid snapshot file; perform incremental identification and deduplication verification on the valid snapshot file based on the task identification information and the snapshot sequence number, assemble the full file path of the valid snapshot file that passes the verification with the task identification information into a backup task message, and push it to the buffer queue of the distributed cache.

[0059] Step 303: Obtain the current number of active threads in the consumer thread pool.

[0060] In this embodiment, the current active thread count of the consumer thread pool refers to the number of worker threads currently executing backup tasks. By obtaining this current active thread count in real time, the system can perceive the current load status of the consumer end, providing a basis for dynamically adjusting the retrieval speed.

[0061] As an example, the consumer thread pool (threadPoolForRedis) is configured with a core thread count of 3, a maximum thread count of 20, a queue capacity of 10, and an idle lifespan of 30 seconds. The system can obtain the current active thread count in real time through the getActiveCount() method of ThreadPoolExecutor for subsequent load-aware scheduling decisions.

[0062] Step 304: When the current number of active threads has not reached the maximum thread limit, the backup task message is pulled from the buffer queue of the distributed cache at the first speed. If no backup task message is obtained, the first sleep state is executed. If a backup task message is obtained, the backup task message is dispatched to the idle worker thread in the corresponding consumer thread pool, and then the second sleep state is executed, and the backup task message is pulled from the buffer queue of the distributed cache at the first speed again.

[0063] In this embodiment, when the consumer thread pool is not yet fully loaded, the system pulls backup task messages from the buffer queue at a relatively fast first speed to improve backup throughput. If the buffer queue is empty (no backup task message is obtained), a first sleep state (long sleep) is executed to avoid wasting CPU resources due to invalid polling; if a backup task message is successfully obtained, it is dispatched to an idle worker thread to perform the backup, and then a second sleep state (short sleep) is executed, and then the system continues to pull messages at the first speed.

[0064] As an example, when the number of active threads is less than 20, the main loop performs an atomic Right Pop operation on the Redis List at the highest speed to retrieve the tail message. If the popped backup task message is empty (the queue currently has no valid snapshot files waiting to be processed), the main loop enters the first sleep state (long sleep, 1000 milliseconds) to avoid CPU idling. If the popped backup task message is not empty, the backup task message is encapsulated into a Runnable object and submitted to the consumer thread pool for backup processing. The main loop then enters the second sleep state (short sleep, 10 milliseconds) and continues to retrieve at the highest speed.

[0065] Step 305: When the current number of active threads has reached the maximum number of threads, execute the third sleep state, then reacquire the current number of active threads in the consumer thread pool, and pull backup task messages from the buffer queue of the distributed cache at the second speed; the first speed is faster than the second speed.

[0066] In this embodiment, when the current consumer thread pool is full, the system executes a third sleep state (moderate sleep), actively slowing down the fetching speed to avoid excessive backup of backup tasks in the memory queue, which could lead to memory overflow. After the sleep ends, the number of active threads is reacquired, and fetching continues at a slower second speed.

[0067] As an example, when the number of active threads has reached the maximum of 20, it indicates that the consumption process is at full capacity, and all worker threads are performing time-consuming cross-storage file copy operations. At this time, the main loop enters the third sleep state (medium sleep, 500 milliseconds), and continues scheduling after the existing worker threads are released, thereby avoiding excessive backlog of tasks in memory.

[0068] Among them, the sleep duration of the first sleep state (1000 milliseconds) is greater than the sleep duration of the third sleep state (500 milliseconds), and the sleep duration of the third sleep state (500 milliseconds) is greater than the sleep duration of the second sleep state (10 milliseconds).

[0069] Step 306: Parse the backup task message using an idle worker thread to construct a redundant backup target path for cross-storage redundant backup.

[0070] It should be noted that the execution processes of steps 301 to 302 and 306 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit these processes and will not elaborate further.

[0071] In summary, the process involves: obtaining the task identifier information and checkpoint storage root path of the Flink task; traversing the snapshot files under the checkpoint storage root path, filtering out valid snapshot files that conform to the preset naming rules, and parsing out the snapshot sequence number of the valid snapshot files; performing incremental identification and deduplication verification on the valid snapshot files based on the task identifier information and snapshot sequence number; assembling the full file path of the valid snapshot files that pass the verification with the task identifier information into a backup task message, and pushing it to the buffer queue of the distributed cache; obtaining the current active thread count of the consumer thread pool; if the current active thread count has not reached the maximum thread count limit, pulling the backup task message from the buffer queue of the distributed cache at the highest speed; if no backup task message is obtained, executing the first sleep state; if... Upon receiving a backup task message, the message is dispatched to an idle worker thread in the corresponding consumer thread pool. Then, a second sleep state is entered, and the backup task message is retrieved from the distributed cache's buffer queue at the first speed. When the current number of active threads reaches the maximum thread count, a third sleep state is entered. The current number of active threads in the consumer thread pool is then retrieved again, and the backup task message is retrieved from the distributed cache's buffer queue at the second speed. The first speed is faster than the second speed. The sleep duration of the first sleep state is longer than that of the third sleep state, and the sleep duration of the third sleep state is longer than that of the second sleep state. The backup task message is parsed by an idle worker thread to construct a redundant backup target path for cross-storage redundant backup. Therefore, after incremental identification and deduplication verification of valid snapshot files, the message retrieval speed and the sleep duration of different levels are dynamically adjusted based on the number of active threads in the consumer thread pool. Backup task messages are distributed to idle worker threads for cross-storage redundant backup, achieving adaptive retrieval and consumption of backup task messages. This fully utilizes thread resources while avoiding empty queue polling and thread overload, improving the overall throughput and operational stability of the snapshot backup task.

[0072] Figure 4 This is a schematic diagram of the structure of the Flink checkpoint backup device shown in the fourth embodiment of this disclosure.

[0073] like Figure 4 As shown, the Flink checkpoint backup device 400 includes: an acquisition module 401, a verification module 402, a dispatch module 403, and a backup module 404.

[0074] The module includes: an acquisition module 401, used to acquire the task identifier information and checkpoint storage root path of a Flink task; a verification module 402, used to traverse the snapshot files under the checkpoint storage root path, filter out valid snapshot files that conform to preset naming rules, and parse out the snapshot sequence number of the valid snapshot file; based on the task identifier information and snapshot sequence number, incremental identification and deduplication verification are performed on the valid snapshot files, and the full file path of the valid snapshot file that passes the verification is assembled with the task identifier information into a backup task message, which is then pushed to the buffer queue of the distributed cache; a dispatch module 403, used to pull the backup task message from the buffer queue of the distributed cache and dispatch it to the idle worker thread in the corresponding consumer thread pool; and a backup module 404, used to parse the backup task message through the idle worker thread, construct a redundant backup target path, and perform cross-storage redundant backup.

[0075] As one possible implementation of this disclosure, the acquisition module 401 is specifically used to: periodically scan through a timed task to obtain a list of currently running Flink tasks; for each Flink task in the Flink task list, extract task identification information and the corresponding checkpoint storage root path, wherein the checkpoint storage root path is used as the scanning entry point for the snapshot file traversal.

[0076] As one possible implementation of this disclosure, the verification module 402 is specifically used to: compare the snapshot sequence number with the maximum backup snapshot sequence number corresponding to the task identifier information in the distributed cache; if the snapshot sequence number is less than or equal to the maximum snapshot sequence number, it is determined that the valid snapshot file has not passed the incremental identification and the valid snapshot file is skipped; if the snapshot sequence number is greater than the maximum snapshot sequence number, the task identifier information and the snapshot sequence number are used as a joint key to query whether there is a corresponding processed mark in the distributed cache; if the processed mark exists, it is determined that the valid snapshot file has not passed the deduplication verification and the valid snapshot file is skipped; if the processed mark does not exist, it is determined that the valid snapshot file has passed the verification, and the full file path of the valid snapshot file and the task identifier information are assembled into a backup task message and pushed to the buffer queue of the distributed cache.

[0077] As one possible implementation of this disclosure, the dispatch module 403 is specifically configured to: obtain the current active thread count of the consumer thread pool; when the current active thread count has not reached the maximum thread count limit, retrieve backup task messages from the buffer queue of the distributed cache at a first speed; wherein, if no backup task message is retrieved, a first sleep state is executed; if a backup task message is retrieved, the backup task message is dispatched to an idle worker thread in the corresponding consumer thread pool, then a second sleep state is executed, and the backup task message is retrieved from the buffer queue of the distributed cache at the first speed again; when the current active thread count has reached the maximum thread count limit, a third sleep state is executed, then the current active thread count of the consumer thread pool is retrieved again, and the backup task message is retrieved from the buffer queue of the distributed cache at a second speed; the first speed is faster than the second speed; wherein, the sleep duration of the first sleep state is longer than the sleep duration of the third sleep state, and the sleep duration of the third sleep state is longer than the sleep duration of the second sleep state.

[0078] As one possible implementation of this disclosure, the backup module 404 is specifically used to: parse the backup task message through the idle working thread to extract the full file path and task identification information; construct a redundant backup target path by concatenating the preset backup root path, the task identification information, and the relative path portion of the full file path; and call the distributed file system interface to asynchronously and recursively copy the valid snapshot file pointed to by the full file path to the redundant backup target path to perform cross-storage redundant backup.

[0079] As a possible implementation of this disclosure, after asynchronously and recursively copying the valid snapshot file pointed to by the full path of the file to the redundant backup target path, the apparatus further includes: a storage module, used to store the task identification information, snapshot sequence number and redundant backup target path corresponding to the valid snapshot file to a business database; wherein, the task identification information is used to associate the corresponding Flink task, and the snapshot sequence number is used to distinguish valid snapshot files of different versions under the same Flink task; and a recovery module, used to locate the redundant backup file pointed to by the redundant backup target path stored in the business database to perform fault recovery when the Flink task fails.

[0080] As a possible implementation of this disclosure, the apparatus further includes: an update module, configured to, after performing cross-storage redundancy backup, use the snapshot sequence number of the valid snapshot file that has completed the cross-storage redundancy backup as the current snapshot sequence number, and update the maximum backed-up snapshot sequence number corresponding to the task identifier information in the distributed cache to the current snapshot sequence number; the maximum backed-up snapshot sequence number is used for comparison with the snapshot sequence number of the valid snapshot file to be verified during subsequent incremental identification and deduplication verification to filter out valid snapshot files that have already been backed up; a write module, configured to write a processed mark in the distributed cache using the task identifier information and the snapshot sequence number as a joint key, and set a preset expiration time; and a query module, configured to allow the incremental identification and deduplication verification steps to query the processed mark within the preset expiration time, so as to skip valid snapshot files containing the processed mark.

[0081] As a possible implementation of this disclosure, the apparatus further includes: a first calculation module, configured to count the total number of backups stored in the business database corresponding to each task identifier information according to a preset period; a second calculation module, configured to calculate a snapshot sequence number threshold to be cleaned when the total number of backups exceeds a preset maximum retention threshold; a first deletion module, configured to query and delete backup records in the business database whose snapshot sequence number is less than the snapshot sequence number threshold to be cleaned; and a second deletion module, configured to call a distributed file system interface to physically delete snapshot files under the redundant backup target path corresponding to the backup records.

[0082] The Flink checkpoint backup apparatus of this embodiment acquires a list of running Flink tasks and extracts the task identifier information and checkpoint storage root path of each Flink task; it traverses snapshot files under the checkpoint storage root path, filters out valid snapshot files that conform to preset naming rules, and parses out the snapshot sequence number of the valid snapshot files; it performs incremental identification and deduplication verification on the valid snapshot files based on the task identifier information and snapshot sequence number, assembles the full file path of the valid snapshot files that pass the verification with the task identifier information into a backup task message, and pushes it to the buffer queue of the distributed cache system; it pulls the backup task message from the buffer queue and dispatches it to the idle worker thread in the consumer thread pool; the idle worker thread parses the backup task message and constructs a redundant backup target path for cross-storage redundant backup. Thus, this method decouples the discovery and backup execution of checkpoint snapshots through a distributed buffer queue, avoids duplicate backups by using incremental identification and deduplication verification, and eliminates the risk of single-point storage failure by combining cross-storage redundant replication, achieving checkpoint backup without stopping Flink tasks and supporting flexible management of the number of backups.

[0083] In an exemplary embodiment, an electronic device is also proposed.

[0084] The electronic devices include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the Flink checkpoint backup method as proposed in any of the foregoing embodiments.

[0085] As an example, Figure 5 This is a schematic diagram of the structure of an electronic device 500 as shown in an exemplary embodiment of this disclosure, as follows: Figure 5 As shown, the above-mentioned electronic device 500 may further include: The memory 510 and processor 520 are connected by a bus 530, which connects different components (including the memory 510 and the processor 520). The memory 510 stores a computer program, which implements the Flink checkpoint backup method described in this embodiment when the processor 520 executes the program.

[0086] Bus 530 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0087] Electronic device 500 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 500, including volatile and non-volatile media, removable and non-removable media.

[0088] Memory 510 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 540 and / or cache memory 550. The server may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 560 can be used to read and write non-removable, non-volatile magnetic media (…). Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 530 via one or more data media interfaces. Memory 510 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0089] A program / utility 580 having a set (at least one) of program modules 570 may be stored, for example, in memory 510. Such program modules 570 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 570 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0090] Electronic device 500 can also communicate with one or more external devices 590 (e.g., keyboard, pointing device, display 591, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 592. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 593. As shown, network adapter 593 communicates with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0091] The processor 520 performs various functional applications and data processing by running programs stored in the memory 510.

[0092] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the Flink checkpoint backup method in this disclosure embodiment, and will not be repeated here.

[0093] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor of an electronic device to perform the Flink checkpoint backup method proposed in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0094] In an exemplary embodiment, a computer program product is also provided, including a computer program / instructions that, when executed by a processor, implement the Flink checkpoint backup method proposed in any of the above embodiments.

[0095] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0096] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A Flink checkpoint backup method, characterized in that, include: Obtain the task identifier information and checkpoint storage root path of the Flink task; Traverse the snapshot files under the root path of the checkpoint storage, filter out valid snapshot files that conform to the preset naming rules, and parse out the snapshot sequence number of the valid snapshot file; Based on the task identification information and snapshot sequence number, the valid snapshot files are incrementally identified and deduplicated. The full file path of the valid snapshot file that passes the verification is assembled with the task identification information into a backup task message and pushed to the buffer queue of the distributed cache. The backup task message is retrieved from the buffer queue of the distributed cache and dispatched to the idle worker thread in the corresponding consumer thread pool; The idle worker thread parses the backup task message and constructs a redundant backup target path to perform cross-storage redundant backup.

2. The method according to claim 1, characterized in that, The incremental identification and deduplication verification of valid snapshot files based on the task identifier information and snapshot sequence number, assembling the full file path of the verified valid snapshot file with the task identifier information into a backup task message, and pushing it to the buffer queue of the distributed cache includes: The snapshot sequence number is compared with the maximum snapshot sequence number that has been backed up corresponding to the task identification information in the distributed cache. If the snapshot sequence number is less than or equal to the maximum snapshot sequence number, it is determined that the valid snapshot file has not passed the incremental identification and the valid snapshot file is skipped. If the snapshot sequence number is greater than the maximum snapshot sequence number, query the distributed cache for a corresponding processed mark using the task identifier information and the snapshot sequence number as a joint key. If the processed mark exists, it is determined that the valid snapshot file has failed the deduplication check and the valid snapshot file is skipped. If the processed flag does not exist, the valid snapshot file is deemed to have passed the verification. The full file path of the valid snapshot file and the task identifier information are assembled into a backup task message and pushed to the buffer queue of the distributed cache.

3. The method according to claim 1, characterized in that, The process of obtaining the task identifier information and checkpoint storage root path of the Flink task includes: A list of currently running Flink tasks is obtained through periodic scanning using a scheduled task. For each Flink task in the Flink task list, extract the task identifier information and the corresponding checkpoint storage root path, wherein the checkpoint storage root path is used as the scanning entry point for the snapshot file traversal.

4. The method according to claim 1, characterized in that, The step of retrieving the backup task message from the buffer queue of the distributed cache and dispatching it to the idle worker thread in the corresponding consumer thread pool includes: Get the current number of active threads in the consumer thread pool; When the current number of active threads has not reached the maximum number of threads, a backup task message is retrieved from the buffer queue of the distributed cache at a first speed; if no backup task message is retrieved, a first sleep state is executed; if a backup task message is retrieved, the backup task message is dispatched to an idle worker thread in the corresponding consumer thread pool, and then a second sleep state is executed, and the backup task message is retrieved from the buffer queue of the distributed cache at the first speed again. When the current number of active threads has reached the maximum number of threads, the third sleep state is executed. Then, the current number of active threads in the consumer thread pool is retrieved again, and backup task messages are pulled from the buffer queue of the distributed cache at a second speed; the first speed is faster than the second speed. Among them, the hibernation duration of the first hibernation state is greater than that of the third hibernation state, and the hibernation duration of the third hibernation state is greater than that of the second hibernation state.

5. The method according to claim 1, characterized in that, The step of parsing backup task messages and constructing redundant backup target paths through the idle worker thread to perform cross-storage redundant backups includes: The backup task message is parsed using the idle worker thread to extract the full file path and task identification information. The redundant backup target path is constructed by concatenating the preset backup root path, the task identification information, and the relative path portion of the full file path. The distributed file system interface is invoked to asynchronously and recursively copy the valid snapshot file pointed to by the full path of the file to the redundant backup target path, thereby performing cross-storage redundant backup.

6. The method according to claim 5, characterized in that, After asynchronously and recursively copying the valid snapshot file pointed to by the full path of the file to the redundant backup target path, the method further includes: The task identification information, snapshot sequence number, and redundant backup target path corresponding to the valid snapshot file are stored in the business database; wherein, the task identification information is used to associate the corresponding Flink task, and the snapshot sequence number is used to distinguish different versions of valid snapshot files under the same Flink task; The redundant backup target path stored in the business database is used to locate the redundant backup file pointed to by the redundant backup target path to perform fault recovery when the Flink task fails.

7. The method according to claim 6, characterized in that, The method further includes: After performing cross-storage redundancy backup, the snapshot sequence number of the valid snapshot file that has completed the cross-storage redundancy backup is used as the current snapshot sequence number. The maximum backup snapshot sequence number of the corresponding task identification information in the distributed cache is updated to the current snapshot sequence number. The maximum backup snapshot sequence number is used to compare with the snapshot sequence number of the valid snapshot file to be verified during subsequent incremental identification and deduplication verification, and to filter out the valid snapshot files that have been backed up. Using the task identifier information and the snapshot sequence number as a joint key, a processed flag is written into the distributed cache, and a preset expiration time is set; The processed marker is available for querying in the incremental identification and deduplication verification steps within the preset expiration time, so as to skip valid snapshot files containing the processed marker.

8. The method according to claim 6, characterized in that, The method further includes: According to a preset period, the total number of backups stored in the business database corresponding to each task identification information is counted. When the total number of backups exceeds the preset maximum retention threshold, calculate the threshold for the snapshot sequence number to be cleaned. Query and delete backup records in the business database whose snapshot sequence number is less than the threshold of the snapshot sequence number to be cleaned; Call the distributed file system interface to physically delete the snapshot file under the redundant backup target path corresponding to the backup record.

9. A Flink checkpoint backup device, characterized in that, include: The acquisition module is used to obtain the task identifier information and checkpoint storage root path of the Flink task; The verification module is used to traverse the snapshot files under the root path of the checkpoint storage, filter out valid snapshot files that conform to the preset naming rules, and parse out the snapshot sequence number of the valid snapshot file. Based on the task identification information and snapshot sequence number, the valid snapshot files are incrementally identified and deduplicated. The full file path of the valid snapshot file that passes the verification is assembled with the task identification information into a backup task message and pushed to the buffer queue of the distributed cache. The dispatch module is used to pull the backup task message from the buffer queue of the distributed cache and dispatch it to the idle worker thread in the corresponding consumer thread pool. The backup module is used to parse backup task messages through the idle worker thread and construct redundant backup target paths for cross-storage redundant backup.

10. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 8.

Images