A state polling method, device and medium based on asynchronous tasks and cache

Abstract

The application discloses a state polling method and device based on an asynchronous task and a cache, and a medium, relates to the field of data processing, and the method comprises the following steps: in response to receiving an execution request for a time-consuming operation, generating a unique task identifier associated with the time-consuming operation; starting the time-consuming operation as an asynchronous task; storing an initial state associated with the unique task identifier in a preset cache; returning the unique task identifier and the initial state to a requester of the execution request; in response to receiving a state query request comprising the unique task identifier, retrieving a current state associated with the unique task identifier from the preset cache; and returning the current state to a requester of the state query request. The asynchronous task is used for updating the current state associated with the unique task identifier in the preset cache during the execution process or after the execution is completed. The application can effectively solve the problem of long-time occupation of server resources, causing resource waste.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a state polling method, device and medium based on asynchronous tasks and caching. Background Technology

[0002] In modern software development and operations practices, with the widespread application of distributed systems, microservice architectures, and cloud-native technologies, service deployment has become a routine and core operation. Whether it's releasing a new application version to a production environment or updating and extending existing services, the service deployment process is indispensable.

[0003] Specifically, a typical service deployment process includes the following steps: First, data extraction, such as pulling the latest code from the source code management repository or downloading container images from the image repository; second, service packaging, including compiling code, building Docker images, and generating deployment packages; next, remote transmission, transferring the packaged service files or images to the target deployment environment, which involves data transmission across networks and regions, and its time consumption is significantly affected by network bandwidth and latency; then, environment preparation and configuration; and finally, service startup and health checks, starting a new service instance and waiting for it to pass health checks to ensure that the service is running normally before switching traffic to the new instance and possibly taking the old instance offline.

[0004] Any of these steps can become very time-consuming due to large data volumes, poor network conditions, limited computing resources, or complex dependencies. For example, a Docker image for a large microservice can reach hundreds of megabytes or even gigabytes, and its transfer process can take several minutes; complex compilation processes or database migration scripts can also take a long time to run. Therefore, service deployment operations are often time-consuming.

[0005] For time-consuming service deployment operations, a synchronous request mode is typically used to reduce latency. In synchronous request mode, when a client sends a service deployment request to the server, the server immediately receives the request and begins executing all deployment steps. During this period, the server's thread or process handling the request is completely blocked until the entire deployment operation is complete, at which point the server can return a final response to the client. Meanwhile, the client must continuously wait for the server's response, unable to perform other operations, and its network connection with the server remains open.

[0006] In the synchronous mode described above, server resources are occupied for extended periods. Each deployment request in synchronous mode occupies a server processing thread or process for an extended period. The server's concurrent processing capacity is limited, typically determined by the size of its available thread pool. If multiple deployment requests arrive simultaneously, or if a single deployment request takes too long, the server's thread resources will be quickly exhausted. Once all processing threads are blocked, new requests cannot be processed and will instead enter a waiting queue or be rejected outright. This leads to a sharp drop in server throughput, poor service responsiveness, and may even trigger a cascading failure, impacting the operation of other normal services and causing significant resource waste. This waste is not only reflected in CPU and memory usage but also in network connection resources, as each synchronous request requires maintaining a long-running TCP connection.

[0007] There is currently no effective solution to the above problems. Summary of the Invention

[0008] This application provides a status polling method, device, and medium based on asynchronous tasks and caching, which effectively solves the problem of server resources being occupied for a long time, resulting in resource waste.

[0009] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0010] Firstly, a state polling method based on asynchronous tasks and caching is provided, which includes:

[0011] In response to receiving a request to execute a time-consuming operation, a unique task identifier associated with the time-consuming operation is generated, wherein the time-consuming operation includes service deployment or service packaging;

[0012] Start the time-consuming operation as an asynchronous task;

[0013] An initial state associated with the unique task identifier is stored in a preset cache, the initial state being used to indicate that the asynchronous task is being executed;

[0014] Return the unique task identifier and the initial state to the requester of the execution request;

[0015] In response to receiving a status query request including the unique task identifier, the system retrieves the current status associated with the unique task identifier from a preset cache; and

[0016] The current state is returned to the requester of the status query request, wherein the asynchronous task is used to update the current state associated with the unique task identifier in the preset cache during or after execution.

[0017] In one possible implementation of the first aspect, starting the time-consuming operation as an asynchronous task includes:

[0018] The time-consuming operation is encapsulated into an executable task unit, the task unit including the unique task identifier and the specific execution logic of the time-consuming operation;

[0019] The task unit is submitted to a preset task scheduling service. The task scheduling service is used to maintain a task queue and multiple worker thread pools, and to allocate the task unit to the corresponding worker thread pool for processing according to the type and priority of the time-consuming operation. The worker thread in the worker thread pool is used to receive the task unit and start the specific execution logic of the time-consuming operation.

[0020] After the worker thread starts the specific execution logic of the time-consuming operation, the initial execution log of the asynchronous task is written to the preset cache. The initial execution log includes the task start time, the execution thread ID, and the expected first status update time. After starting the asynchronous task, the task scheduling service starts a monitoring process. The monitoring process is used to check whether the first status update of the asynchronous task has been completed within a preset time interval to ensure that the asynchronous task is successfully activated and starts execution.

[0021] In another possible implementation of the first aspect, the preset cache includes a memory-based cache or a database for storing task states.

[0022] In another possible implementation of the first aspect, storing the initial state associated with the unique task identifier in a preset cache includes:

[0023] Construct a task status data structure, which includes the unique task identifier, the initial state, the task creation timestamp, the task type, and the task initiator identifier.

[0024] The task status data structure is serialized into a preset format, and the serialized task status data structure is stored in the preset cache through the API of the preset cache.

[0025] Set a time-to-live for the stored initial state to automatically clean up expired states when the asynchronous task terminates abnormally or has not been updated for a long time;

[0026] When storing the initial state, the expected completion time range of the time-consuming operation is recorded;

[0027] The preset cache is used to synchronously copy the task status data structure to at least one backup cache node.

[0028] In another possible implementation of the first aspect, the asynchronous task updates the current state associated with the unique task identifier in the preset cache during or after execution, including:

[0029] During execution, the asynchronous task periodically stores intermediate step status, error messages, and / or solutions in a preset cache; or

[0030] After the asynchronous task is completed, the final execution result is stored in a preset cache, whereby the final execution result includes success or failure indication, error message and / or solution.

[0031] In another possible implementation of the first aspect, the asynchronous task updates the current state associated with the unique task identifier in the preset cache during or after execution, further comprising:

[0032] When the asynchronous task completes each key execution stage or detects a state change, it triggers a state update event. The state update event carries one or more of the following: the current progress percentage of the asynchronous task, the list of completed subtasks, and the resource consumption index of the current stage. A preset cache is used to receive the state update event and update the current state using an optimistic locking mechanism based on the unique task identifier.

[0033] Each time the asynchronous task successfully updates the current state, it synchronously refreshes the lifetime of the unique task identifier. A preset cache is used to dynamically adjust the frequency and synchronization level of state updates.

[0034] The preset cache dynamically adjusts the frequency and synchronization level of state updates, including:

[0035] The preset cache dynamically adjusts the minimum time interval for status updates based on the current execution stage of the asynchronous task and the preset task priority.

[0036] The preset cache adjusts the synchronization level of status updates based on the received current resource utilization and cache load;

[0037] The preset cache determines whether the asynchronous task is a real-time task or a batch processing task;

[0038] If the asynchronous task belongs to the real-time task, the preset cache executes a strong synchronization strategy;

[0039] If the asynchronous task is a batch processing task, the default cache executes an asynchronous-synchronous strategy.

[0040] In another possible implementation of the first aspect, before starting the asynchronous task, the following is also included:

[0041] The preset cache is used to check whether there are any currently executing tasks associated with the time-consuming operation;

[0042] If a task is currently being executed, return the unique task identifier and the initial state of the task being executed, without starting a new asynchronous task.

[0043] In another possible implementation of the first aspect, the method further includes:

[0044] In response to receiving a retry request, the existing state associated with the unique task identifier in the preset cache is cleared before starting the asynchronous task.

[0045] Secondly, this application provides an electronic device, characterized in that it comprises:

[0046] The memory is configured to store instructions; and

[0047] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned asynchronous task and cache-based state polling method.

[0048] Thirdly, this application provides a machine-readable storage medium, characterized in that the machine-readable storage medium stores instructions for causing the machine to execute the above-described asynchronous task and cache-based state polling method.

[0049] By decoupling time-consuming operations into asynchronous tasks and introducing task identifiers and status polling mechanisms, the original blocking synchronous request mode is transformed into a non-blocking asynchronous mode. This allows the server to respond quickly to client requests, release processing threads, significantly improve the server's concurrency processing capabilities, throughput, and resource utilization, while also improving the client's user experience and effectively solving the problem of resource waste caused by prolonged server resource occupation.

[0050] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0051] Figure 1 A flowchart illustrating a status polling method based on asynchronous tasks and caching, provided for an embodiment of this application;

[0052] Figure 2 This is a schematic diagram illustrating the timing of time-consuming operation request processing and asynchronous task startup provided in an embodiment of this application.

[0053] Figure 3 This is a schematic diagram illustrating the timing of task status polling and asynchronous task execution update provided in an embodiment of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0055] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0056] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0057] Figure 1 The illustration shows a flowchart of a state polling method based on asynchronous tasks and caching according to an embodiment of this application. Figure 1 As shown in the figure, this application embodiment provides a status polling method based on asynchronous tasks and cache, which may include the following steps.

[0058] S110. In response to receiving a request to execute a time-consuming operation, generate a unique task identifier associated with the time-consuming operation, wherein the time-consuming operation includes service deployment or service packaging.

[0059] S120. Start the time-consuming operation as an asynchronous task;

[0060] S130. Store the initial state associated with a unique task identifier in a preset cache. The initial state is used to indicate that the asynchronous task is being executed.

[0061] S140. Return a unique task identifier and initial state to the requester of the execution request;

[0062] S150, In response to receiving a status query request including a unique task identifier, retrieve the current status associated with the unique task identifier from a preset cache; and

[0063] S160. Return the current status to the requester of the status query request, wherein the asynchronous task is used during or after execution to update the current status associated with the unique task identifier in the preset cache.

[0064] Upon receiving a request to execute a time-consuming operation, the server first needs to parse and validate the request to determine its validity and the operation type. In practice, the server receives execution requests from clients via HTTP interfaces or RPC calls. These requests contain key information such as the operation type (e.g., service deployment, service packaging), target environment information, and configuration parameters. Upon receiving the request, the server immediately validates the request format, checking the completeness and validity of necessary parameters, such as verifying the existence of the target deployment environment and the correctness of the packaging configuration. After successful validation, the server generates a unique task identifier associated with the time-consuming operation. This identifier can be generated using a UUID (Universally Unique Identifier) ​​algorithm, combined with the current timestamp, the operation type hash value, and a random number, ensuring global uniqueness in a distributed environment. For example, for a service deployment operation, the generated identifier might be "DEPLOY_20250827_073123_A1B2C3D4", which includes an operation type prefix, a timestamp, and a random string. This not only guarantees uniqueness but also provides readability, facilitating troubleshooting and log analysis by operations personnel. In this way, each time-consuming operation acquires a unique identifier, laying the foundation for subsequent asynchronous processing and state tracking.

[0065] The implementation principle of starting time-consuming operations as asynchronous tasks is based on an asynchronous processing model using task queues and thread pools. In practice, the server first encapsulates the received time-consuming operation into an executable task unit. This task unit contains complete information such as a unique task identifier, operation type, execution parameters, and callback functions. After encapsulation, the task unit is submitted to a pre-configured task scheduling service, which maintains one or more task queues and corresponding worker thread pools. Based on the operation type and priority, the scheduling service allocates the task to an appropriate thread pool for processing. For example, CPU-intensive service packaging operations are allocated to the computing thread pool, while I / O-intensive remote deployment operations are allocated to the I / O thread pool. After retrieving the task from the queue, the worker thread immediately begins executing the specific operation logic, such as code compilation, image building, and file transfer.

[0066] Simultaneously with task initiation, the scheduling service starts a monitoring process. This process tracks the task's execution status, checks whether the task has started normally, and issues alerts or retries in case of abnormalities. In the asynchronous startup mechanism of this embodiment, refer to... Figure 2 and Figure 3 The main service thread is released immediately after a task is submitted, preventing it from being blocked by prolonged operations and significantly improving the server's concurrent processing capabilities. Furthermore, through proper thread pool configuration and task priority management, the use of system resources can be effectively controlled, avoiding resource exhaustion caused by a large number of concurrent tasks.

[0067] Storing the initial state in a pre-defined cache ensures the persistence and fast access of state information. During implementation, the server first constructs a complete task state data structure, which includes a unique task identifier, current state, task creation timestamp, operation type, requester identifier, expected completion time, and other detailed information. The data structure is serialized using JSON format for easy storage and transmission. The pre-defined cache can use in-memory databases such as Redis or Memcached, or a dedicated table structure in a relational database.

[0068] Taking Redis as an example, storage operations are executed using the SET command. The key is the task identifier, and the value is the serialized state information. An appropriate expiration time (time-to-live) is set to prevent the cache from growing indefinitely. To ensure high availability, the caching system is typically configured in master-slave or cluster mode, and the state information is automatically synchronized to the standby node. When storing the initial state, the expected execution time range of the task is also recorded, which helps with subsequent timeout detection and exception handling. This cache-based state storage solution not only provides millisecond-level read / write performance but also ensures the reliability of state information through data persistence and backup mechanisms, providing a data foundation for the entire asynchronous processing flow.

[0069] The server returns a unique task identifier and initial status to the requester. In practice, after initiating the task and storing its status, the server immediately constructs a response message and returns it to the client. The response message is in JSON format and includes key information such as the task identifier, current status, expected completion time, and status query interface address.

[0070] Reference Figure 2After receiving the response, the client can periodically query the task status based on the task identifier, implementing an asynchronous polling mechanism. To improve user experience, the response can also include a suggested interval for progress queries, avoiding excessively frequent query requests that could overload the server. In case of network anomalies or response timeouts, the server will implement a retry mechanism to ensure that the response is reliably delivered to the client. Simultaneously, the server logs the response transmission, including response time, client information, and task identifier, facilitating subsequent troubleshooting and performance analysis. This addresses the issue of long client wait times in traditional synchronous modes, allowing clients to perform other operations immediately after submitting a task, significantly improving user experience and overall system response performance.

[0071] When a client initiates a status query request, the server first verifies the request, confirming the validity of the task identifier and the requester's permissions. Once verification is successful, the server quickly retrieves the latest status information associated with the task identifier from a pre-set cache via a caching API. The retrieval process uses key-value pairs, with the task identifier as the key to directly obtain the corresponding status data. Due to the high-performance nature of the caching system, the retrieval operation is typically completed within milliseconds.

[0072] During the retrieval process, the server returns corresponding error messages for non-existent task identifiers. In cases of cached connection failures, a backup cache node can be enabled, or the query can be downgraded to a database query. The retrieved status information is deserialized and converted into structured data objects containing detailed information such as the current execution stage of the task, progress percentage, completed subtasks, encountered error messages, and estimated remaining time. To optimize performance, the server can also implement cache preheating and data compression strategies, preloading frequently queried hot data and compressing large status data for storage. This cache-based status retrieval mechanism not only ensures high-performance queries but also guarantees service stability and reliability.

[0073] Returning the current status to the requester of the status query request and ensuring that asynchronous tasks continuously update the cached status information is the final step in the entire polling mechanism. After retrieving the latest status, the server immediately constructs a detailed response message and returns it to the client. The response message includes not only basic status information but also execution details, such as a description of the current execution stage, the percentage of work completed, and the estimated completion time. For example, for a service deployment task, the response might include specific information such as: "Image download in progress, 60% complete, estimated to take 3 minutes." Simultaneously, the asynchronous tasks executing in the background proactively update the cached status information at key execution nodes, such as... Figure 3 As shown.

[0074] In this embodiment, the update mechanism adopts an event-driven approach. A state update event is triggered when a task completes a significant step, encounters an error, or its state changes. Update operations use cached commands (such as Redis's SET or HSET) to ensure consistency of state information. To avoid update conflicts, optimistic locking or version number mechanisms are used to handle concurrent updates. The frequency of state updates can also be dynamically adjusted during task execution, increasing the update frequency for rapidly changing phases and decreasing it for stable execution phases to balance information real-time performance and system performance. When the task is finally completed, the final execution result is written, including success or failure indicators, detailed execution logs, performance statistics, etc. This continuously updating state mechanism ensures that the client can understand the task's execution progress in real time, while avoiding excessive impact on system performance through a reasonable update strategy.

[0075] This embodiment effectively solves the problem of prolonged server resource occupation in traditional synchronous modes, transforming the originally blocking, long-running operations into a non-blocking asynchronous processing mode. This allows the server to release processing threads immediately after receiving a request, significantly improving the system's concurrent processing capabilities. By introducing a unique task identifier and a caching mechanism, efficient state tracking and query functions are achieved. Clients can understand task progress at any time without maintaining long connections, which not only greatly improves server throughput and resource utilization but also enhances the client's user experience, allowing them to continue other operations after submitting time-consuming tasks. Simultaneously, the cache-based state storage and retrieval mechanism provides millisecond-level response performance, ensuring efficient state queries. It also possesses good scalability and fault tolerance, adapting to the needs of large-scale distributed environments and effectively supporting complex deployment scenarios in modern cloud-native and microservice architectures.

[0076] In one embodiment of this invention, the time-consuming operation is started as an asynchronous task, including the following steps:

[0077] S210. Encapsulate the time-consuming operation into an executable task unit, the task unit including a unique task identifier and the specific execution logic of the time-consuming operation;

[0078] S220. Submit the task unit to the preset task scheduling service. The task scheduling service is used to maintain a task queue and multiple worker thread pools, and to allocate the task unit to the corresponding worker thread pool for processing according to the type and priority of the time-consuming operation. The worker threads in the worker thread pool are used to receive the task unit and start the specific execution logic of the time-consuming operation.

[0079] S230. After the worker thread starts the specific execution logic of the time-consuming operation, it writes the initial execution log of the asynchronous task to the preset cache. The initial execution log includes the task start time, the execution thread ID and the expected first status update time. After the asynchronous task is started, the task scheduling service starts the monitoring process. The monitoring process is used to check whether the first status update of the asynchronous task has been completed within a preset time interval to ensure that the asynchronous task is successfully activated and starts execution.

[0080] Time-consuming operations are encapsulated into executable task units. In practice, the encapsulation process first creates a standardized task unit data structure. This structure adopts a unified interface specification and contains the necessary information and execution logic of the task.

[0081] The core components of a task unit include: a unique task identifier as the task's identity; the specific execution logic of time-consuming operations is encapsulated into callable functions or methods; a task type identifier to distinguish different types of operations (such as service deployment, service packaging, data migration, etc.); a priority parameter for the scheduler to sort tasks; an execution parameter set containing the configuration information required for the operation; a callback function for handling the notification mechanism after the task is completed; and an exception handling strategy defining how to handle task failures.

[0082] The encapsulation process also preprocesses the execution logic, including parameter validation, dependency checks, and resource estimation. For example, for service deployment tasks, the encapsulation process verifies the reachability of the target environment, checks the integrity of the deployment package, and estimates the required CPU and memory resources. The task unit also includes execution context information, such as execution environment variables, security credentials, and log configurations, ensuring that the task can run normally in an independent execution environment. Through a standardized encapsulation mechanism, different types of time-consuming operations are converted into task units of a unified format, providing a consistent interface for subsequent scheduling and execution, facilitating task serialization, persistence, and cross-process transmission.

[0083] Task units are submitted to a pre-defined task scheduling service based on a producer-consumer pattern and a multi-threaded pool architecture. The task scheduling service acts as the central hub of the asynchronous processing system, maintaining task management and resource scheduling mechanisms. In practice, the scheduling service contains one or more task queues, which are categorized according to task type, priority, or execution characteristics, such as CPU-intensive task queues, I / O-intensive task queues, and high-priority task queues. Each queue employs a first-in-first-out (FIFO) or priority queue data structure to ensure ordered task processing.

[0084] The scheduling service maintains multiple worker thread pools, each specializing in handling a specific type of task. The size of each thread pool is dynamically adjusted based on system resources and task characteristics. When a task unit is submitted to the scheduling service, the scheduler uses a load balancing algorithm to allocate the task to an appropriate queue based on the task's type identifier and priority parameters. The allocation algorithm considers factors such as the current queue length, thread pool load, estimated task execution time, and system resource utilization.

[0085] For example, I / O-intensive tasks such as service deployment are assigned to the I / O thread pool; CPU-intensive tasks such as service packaging are assigned to the compute thread pool. After a worker thread retrieves a task from the queue, it creates an independent execution environment, loads the task's execution context, and then starts the specific execution logic. The entire submission and allocation process is asynchronous and non-blocking, ensuring that the scheduling service can quickly respond to a large number of concurrent task submission requests. Through reasonable resource allocation and load balancing, it maximizes the system's processing efficiency and throughput.

[0086] After the worker thread starts the specific execution logic of the time-consuming operation, the initial execution log of the asynchronous task is written to the preset cache based on distributed logging and state synchronization mechanisms. Once the worker thread successfully starts the task execution logic, a detailed initial execution log is immediately constructed. This log contains key information fields: the task start time is in a high-precision timestamp format (accurate to milliseconds); the execution thread ID contains the thread's unique identifier and process information; and the expected first state update time is derived based on statistical analysis of the task type and historical execution data.

[0087] The log also includes the initial resource allocation for the task, such as the number of CPU cores, memory size, and network bandwidth, as well as the task's execution environment information, such as the operating system version, runtime environment, and dependent library versions. Write operations use atomic cached commands to ensure the integrity and consistency of the log records.

[0088] In this embodiment, the task scheduling service initiates a dedicated monitoring process. This process uses periodic polling to check whether the initial status update of each asynchronous task has been completed as expected within a preset time interval (typically 30 seconds to 2 minutes). The monitoring process determines whether the task is executing normally by comparing the current time with the expected initial status update time. If a task fails to update its status on time, the monitoring process triggers an alarm mechanism to notify operations personnel for manual intervention, or automatically restarts the task according to a preset strategy. This proactive monitoring mechanism effectively prevents silent task failures, ensuring that each asynchronous task is correctly activated and begins execution, thus improving the reliability and stability of the entire asynchronous processing system.

[0089] This embodiment achieves efficient asynchronous processing of time-consuming operations. Through a standardized task encapsulation mechanism, various complex time-consuming operations are uniformly converted into schedulable task units, providing a consistent interface and specification for asynchronous processing. The task scheduling service, through a multi-queue and multi-thread pool architecture, achieves intelligent task allocation and parallel processing, significantly improving the system's processing capacity and resource utilization efficiency. The introduction of initial execution logs and monitoring processes provides observability and fault detection capabilities for asynchronous tasks, ensuring that each task can be correctly started and executed.

[0090] This embodiment not only solves the problem of prolonged thread resource occupation in traditional synchronous modes, but also optimizes system performance through fine-grained task management and resource scheduling. Simultaneously, monitoring and logging mechanisms provide support for operation and maintenance management, making the management of large-scale asynchronous tasks more controllable and reliable. This embodiment is particularly suitable for complex deployment scenarios in cloud-native and microservice environments, effectively supporting high-concurrency, large-scale service deployment and management needs.

[0091] In one embodiment of this example, the preset cache includes a memory-based cache or a database for storing task status records.

[0092] As the core storage component for asynchronous task state management, the preset cache has two implementation methods: a memory-based caching system and a dedicated state record table in the database.

[0093] Memory-based caching systems employ in-memory database technologies such as Redis, Memcached, and Hazelcast to store task status information directly in the server's memory, providing millisecond-level read and write performance. Redis, as a commonly used implementation, supports various data structures, including strings, hash tables, lists, and sets, making it suitable for storing complex task status information. For example, Redis's hash table structure can be used to store multiple status fields of a single task, a string structure can be used to store the serialized complete status object, or an ordered set can be used to store time-sorted historical status records.

[0094] The memory cache supports data persistence mechanisms, periodically writing data from memory to disk using RDB snapshots and AOF logs to ensure that state information can be restored after a system restart. Simultaneously, the memory cache supports master-slave replication and cluster modes, achieving high availability and horizontal scalability through data replication and sharding technologies.

[0095] Another approach is to create a dedicated task status table in a relational database (such as MySQL or PostgreSQL) or a NoSQL database (such as MongoDB or Cassandra). This approach is slower than pure memory caching, but it provides stronger data consistency guarantees and larger storage capacity, making it suitable for scenarios that require long-term storage of task status history.

[0096] In terms of data storage structure design, the memory cache organizes data using key-value pairs, storing task identifiers as keys and task status information as values. To improve storage efficiency and access speed, status information is typically encoded using efficient serialization formats such as JSON or Protocol Buffers.

[0097] Memory allocation employs a strategy combining pre-allocation and dynamic expansion, dynamically adjusting memory usage based on system load and the number of tasks. The caching system implements an intelligent data eviction mechanism, including LRU (Least Recently Used), LFU (Least Frequently Used), and Time-to-Live (TTL) strategies, automatically cleaning up expired or infrequently used state data to prevent memory overflow.

[0098] In terms of concurrency control, memory caching employs fine-grained locking mechanisms or lock-free data structures to support high-concurrency read and write operations. For example, Redis uses a single-threaded model to process commands and achieves high concurrency through an event-driven approach, while Hazelcast uses distributed locks and optimistic locking mechanisms to handle concurrent updates. At the network communication level, memory caching provides support for multiple protocols, including TCP, UDP, and HTTP, allowing clients to choose the appropriate communication method as needed.

[0099] The database implementation for storing task status records provides stronger data durability and transaction consistency guarantees. In relational database implementations, a dedicated task status table is typically created, containing fields such as task identifier, status value, creation time, update time, execution progress, and error information. The table structure design considers query performance and storage efficiency, creating a primary key index on the task identifier field and a composite index on the status value and time fields, supporting fast status queries and historical record retrieval.

[0100] The database implementation supports complex query operations, such as querying task status history by time range, counting the number of tasks by status type, and sorting the task list by execution duration. The transaction mechanism ensures the atomicity and consistency of status updates, guaranteeing data correctness even in high-concurrency scenarios.

[0101] In NoSQL database implementations, such as MongoDB, task status is stored as documents, each containing complete task information and status history. The document structure is more flexible, allowing for dynamic adjustment of field structures based on the characteristics of different task types. The database implementation supports data backup and recovery mechanisms, ensuring data security and recoverability through regular backups, incremental backups, master-slave replication, and other methods.

[0102] This embodiment implements a multi-layered data management strategy: the first layer is a memory cache, which stores the status information of currently active tasks and provides millisecond-level read and write performance; the second layer is a database cache, which stores the status information of recently completed tasks, balancing performance and persistence; the third layer is archive storage, which stores long-term historical data, mainly for auditing and analysis.

[0103] The flow of data between different tiers employs an automated strategy, automatically migrating data across storage layers based on factors such as access frequency, timestamps, and importance. For example, the status of newly created tasks is first written to an in-memory cache, and remains in the cache for a period after completion for fast retrieval. After a certain period, it is migrated to database storage, and finally, a retention policy determines whether to archive or delete it. This tiered storage architecture not only optimizes system performance but also effectively controls storage costs while ensuring data integrity and traceability.

[0104] This embodiment provides an efficient and reliable storage infrastructure for asynchronous task state management. The memory caching scheme, by storing state data directly in memory, achieves extremely high access performance, making it suitable for scenarios requiring frequent state queries and updates, and significantly improving the response speed of the entire asynchronous processing system. The database recording scheme, through a database management system, provides robust data consistency guarantees and rich query functions, ensuring reliable storage and long-term preservation of task state information.

[0105] This embodiment also possesses excellent scalability and fault tolerance, enabling it to adapt to application scenarios of varying scales and complexities. Whether in small-scale single-machine deployments or large-scale distributed cluster environments, it provides stable and reliable state storage services, laying a technical foundation for the efficient operation of asynchronous task processing systems.

[0106] In one embodiment of this invention, storing the initial state associated with a unique task identifier in a preset cache includes the following steps:

[0107] S410. Construct a task status data structure, which includes a unique task identifier, initial status, task creation timestamp, task type, and task initiator identifier.

[0108] S420. Serialize the task status data structure into a preset format, and store the serialized task status data structure in the preset cache through the API of the preset cache.

[0109] S430. Set the time-to-live for the initial state of the storage to automatically clean up expired states when the asynchronous task terminates abnormally or has not been updated for a long time.

[0110] S440. When storing the initial state, record the expected completion time range of the time-consuming operation;

[0111] The preset cache is used to synchronously copy the task status data structure to at least one standby cache node.

[0112] The task status data structure is constructed using a hierarchical design pattern, which includes multiple core fields and extended fields.

[0113] The core fields include: a unique task identifier serving as the primary key of the data structure; an initial status field using an enumeration type or predefined status codes, such as "PENDING" (waiting) and "RUNNING" (running), facilitating standardized management and querying of status; a task creation timestamp using a Unix timestamp to record the exact creation time of the task; a task type field identifying the specific category of the operation, such as "SERVICE_DEPLOYMENT" (service deployment), facilitating task classification management and statistical analysis; and a task initiator identifier containing user ID, client IP address, API key, and other information, used for access control and audit tracing.

[0114] The data structure also includes extended fields such as task priority, execution parameters, dependencies, and resource requirements to support complex task management needs. The structure design employs a versioning approach, using a version number field to support data structure evolution and compatibility management. Additionally, the data structure includes verification fields, such as CRC checksums or hash values, to ensure data integrity during transmission and storage.

[0115] The task status data structure is serialized into a preset format. The serialization process first selects a suitable data format, commonly including JSON and XML. The serialized data structure is presented as a key-value pair text format, facilitating debugging and maintenance. The serialization process also includes data compression, using compression algorithms such as gzip and lz4 to further reduce storage space and network transmission overhead. After serialization, storage operations are performed through the standard API interface of the preset cache. Taking Redis as an example, the SET command is used for key-value storage, the HSET command for hash table storage, and the ZADD command for ordered set storage.

[0116] The API call process includes steps such as connection management, authentication, command execution, and result processing. Connection management employs connection pooling technology, pre-establishing and reusing multiple connections to avoid the overhead of frequent connection establishment and destruction. Authentication ensures that only authorized clients can access the caching system, guaranteeing security through password authentication, SSL / TLS encryption, and other methods. Command execution utilizes pipeline technology, submitting multiple related operations in batches to reduce network round trips and improve execution efficiency.

[0117] Setting a time-to-live (TTL) for the initial state of storage requires considering factors such as the expected execution time of the task, the system's storage capacity, and the importance of the data. In practice, the TTL is typically set to 2 to 3 times the expected execution time of the task, allowing sufficient buffer time for exceptional circumstances. For example, for a service deployment task expected to take 30 minutes, the TTL might be set to 90 minutes.

[0118] The time-to-live (TTL) setting uses native commands from the caching system, such as Redis's EXPIRE or SETEX commands, to set the expiration time while storing data. The expiration mechanism employs a combination of lazy deletion and periodic deletion: lazy deletion immediately deletes expired keys when they are accessed, while periodic deletion uses a background process to periodically scan and clean up expired data.

[0119] This embodiment also allows for dynamic lifetime settings, extending or shortening the lifetime based on the actual execution status of the task. For example, when a task is detected to be still executing normally but nearing its expiration time, the lifetime is automatically extended; when an abnormal termination of a task is detected, the relevant status data is immediately cleared. The lifetime mechanism also supports tiered settings, allowing different expiration strategies to be set for tasks of different importance, with longer retention times for critical tasks and shorter retention times for ordinary tasks. This automated data lifecycle management effectively prevents the unlimited growth of cache space, ensures the long-term stable operation of the system, and provides a reliable mechanism for the automatic cleanup of abnormal tasks.

[0120] When storing the initial state, the expected completion time range for time-consuming operations is recorded. The calculation of the expected completion time adopts a historical statistical method. Specifically, the historical statistical method analyzes the historical execution data of similar tasks to calculate statistical indicators such as average execution time, standard deviation, and quantiles, forming a time prediction model. For example, by analyzing the execution time of the past 100 service deployment tasks, the average time is found to be 15 minutes, and 90% of the tasks are completed within 25 minutes. Based on this, the expected completion time range is set to 10-30 minutes.

[0121] The expected time range is typically represented as an interval containing three values: the shortest expected time, the most likely time, and the longest expected time, corresponding to optimistic, normal, and pessimistic scenarios, respectively. This time information, along with the task status, is stored in a cache, providing crucial reference for subsequent monitoring, alerting, and resource scheduling.

[0122] The default cache synchronously replicates the task state data structure to the standby cache node. In practice, the caching system adopts a master-slave replication or multi-master replication architecture. In master-slave replication, all write operations are performed on the master node and then asynchronously or synchronously replicated to one or more slave nodes. Synchronous replication ensures strong data consistency but may affect write performance; asynchronous replication provides better performance but carries the risk of data loss.

[0123] Multi-master replication allows multiple nodes to handle write operations simultaneously, ensuring data consistency through conflict detection and resolution mechanisms. The replication process uses binary logs or operation logs to record all data change operations, and then transmits the logs to standby nodes for replay. To optimize replication performance, techniques such as batch transmission, compressed transmission, and incremental transmission are employed.

[0124] Network partitioning employs split-brain detection and arbitration mechanisms to prevent data inconsistencies caused by network failures. A failover mechanism automatically switches services to a backup node when the primary node fails, ensuring service continuity. Data consistency checks ensure data consistency across all nodes through regular verification and comparison. This multi-node replication mechanism not only provides data redundancy protection but also supports read / write separation and load balancing, significantly improving system availability and scalability.

[0125] This embodiment achieves standardized, persistent, and highly available management of task status information. The standardized data structure design provides a unified organizational form for task status, facilitating system management and maintenance while supporting complex query and analysis needs. Efficient serialization and API storage mechanisms ensure that status data can be quickly and reliably persisted to the cache system, providing a foundation for subsequent status queries and updates. An intelligent time-to-live (TTL) management mechanism effectively prevents unlimited cache space growth through automated data lifecycle control, while providing reliable guarantees for the automatic cleanup of abnormal tasks. Recording expected completion times provides crucial support for intelligent monitoring and user experience optimization. A multi-node replication mechanism ensures high system availability and data reliability through data redundancy and failover. This embodiment not only meets the needs of high-performance asynchronous task processing but also provides enterprise-level reliability and scalability guarantees, laying the technical foundation for task status management in large-scale distributed systems.

[0126] In one embodiment of this invention, the asynchronous task updates the current state associated with the unique task identifier in the preset cache during or after execution, including the following steps:

[0127] S510, During the execution of an asynchronous task, the intermediate step status, error messages, and / or solutions are periodically stored in a preset cache; or

[0128] S520: After the asynchronous task is completed, the final execution result is stored in a preset cache. The final execution result includes success or failure indication, error message and / or solution.

[0129] During execution, asynchronous tasks periodically store intermediate step status, error messages, and solutions in a pre-defined cache. In practice, the execution logic of asynchronous tasks is divided into multiple key stages and checkpoints, with each stage corresponding to specific business steps and status indicators.

[0130] Taking service deployment as an example, the execution phases include: initialization phase, code retrieval phase, compilation and building phase, image packaging phase, remote transmission phase, environment configuration phase, service startup phase, and health check phase. The status update for each phase uses an event-triggered mechanism; when the task reaches a specific milestone or checkpoint, a status update event is automatically triggered.

[0131] The frequency of status updates is dynamically adjusted based on the characteristics of the stage. For rapidly changing stages (such as file transfer), the progress can be updated every few seconds, while for relatively stable stages (such as compilation and building), it can be updated every few minutes. The intermediate step status not only includes simple status indicators, but also detailed execution information, such as the description of the current step, the percentage of work completed, the estimated remaining time, and resource usage.

[0132] Error messages include the error code, error description, time of occurrence, error level (warning, error, fatal error), and scope of impact. Solution information is based on a predefined error handling knowledge base, automatically matching appropriate solutions based on the error type, such as retrying the operation, adjusting parameters, or contacting the administrator. Status update operations use an asynchronous, non-blocking approach to avoid impacting the main task's performance, implemented through a dedicated status update thread or message queue mechanism.

[0133] After an asynchronous task completes its execution, it stores the final result in a pre-defined cache. Once the asynchronous task has completed all execution steps, regardless of success or failure, the generation and storage of the final result will be triggered.

[0134] The final execution result employs a comprehensive data structure containing key components: success and failure indicators are represented by Boolean values ​​or enumeration types, providing clients with clear judgments of the execution result; the execution summary includes the overall execution status of the task, such as total time consumption, time distribution of each stage, resource consumption statistics, performance indicators, etc.; detailed execution logs record key events and operations during task execution, facilitating troubleshooting and performance analysis; error messages summarize errors and warnings encountered during execution, categorized by severity and scope of impact; and solution information provides specific handling suggestions and follow-up operation guidance for encountered problems.

[0135] For successfully completed tasks, the final result also includes output information such as the service access address after deployment, the path of generated files, and configuration information. For failed tasks, the result includes failure reason analysis, rollback information, and retry suggestions. The final result is stored using atomic operations to ensure the integrity and consistency of the result information. The stored procedure also triggers relevant notification mechanisms, such as sending email notifications, calling callback interfaces, and updating monitoring dashboards, to promptly notify relevant personnel or systems of the task completion status.

[0136] Regarding the cache update strategy, a combination of incremental and full updates is adopted. Incremental updates are used for frequently changing progress information to reduce network transmission and storage overhead; full updates are used for state transitions and important milestones to ensure information integrity.

[0137] Concurrency control for update operations employs optimistic locking or a version number mechanism to prevent conflicts between multiple update operations. Specifically, each update checks the current version number; the update operation is only executed if the version number matches, otherwise, a retry or conflict resolution is performed. Cache consistency is guaranteed through a read-after-write verification mechanism; after an update operation is completed, the cached content is read immediately to verify whether the update was successful.

[0138] In this embodiment, when the caching service is unavailable, the state information can be temporarily stored in a local file or memory, and then synchronized after the service is restored. Performance optimization for state updates is achieved through techniques such as batch updates, connection reuse, and data compression, maintaining good performance even in high-concurrency scenarios.

[0139] This embodiment achieves complete transparency in the task execution process and full recording of results. The periodic intermediate state update mechanism allows clients and monitoring systems to understand the task's progress in real time, promptly detect and handle anomalies, significantly improving system observability and user experience. Detailed error messages and solution logs support problem diagnosis and handling, reducing the workload of operations and maintenance personnel and improving problem-solving efficiency. Comprehensive storage of the final execution results provides a complete data foundation for subsequent task processing, audit analysis, and performance optimization. This embodiment ensures the efficiency and reliability of update operations through event-driven, asynchronous processing, and concurrency control technologies, enabling stable operation even in high-concurrency and large-scale deployment scenarios.

[0140] In one embodiment of this invention, updating the current state associated with the unique task identifier in the preset cache during or after the asynchronous task is executed further includes the following steps:

[0141] S610. When an asynchronous task completes each key execution stage or detects a state change, it triggers a state update event. The state update event carries one or more of the following: the current progress percentage of the asynchronous task, the list of completed subtasks, and the resource consumption indicators of the current stage. The preset cache is used to receive the state update event and update the current state using an optimistic locking mechanism based on the unique task identifier.

[0142] S620: When an asynchronous task successfully updates its current state, it synchronously refreshes the lifetime of the unique task identifier. A preset cache is used to dynamically adjust the frequency and synchronization level of state updates.

[0143] The preset cache dynamically adjusts the frequency and synchronization level of state updates, including:

[0144] S630: The preset cache dynamically adjusts the minimum time interval for status updates based on the current execution stage of the asynchronous task and the preset task priority.

[0145] S640: The preset cache adjusts the synchronization level of the status update based on the received current resource utilization and cache load.

[0146] S650, Preset cache determines whether an asynchronous task is a real-time task or a batch task;

[0147] S660. If the asynchronous task is a real-time task, the default cache will execute a strong synchronization strategy.

[0148] S670. If the asynchronous task is a batch processing task, the default cache executes the asynchronous-synchronous strategy.

[0149] In this embodiment, when multiple consecutive state update failures or network fluctuations are detected, the preset cache automatically reduces the frequency of state updates or switches to a backup update channel to reduce system overhead and improve robustness.

[0150] The preset cache adjusts the synchronization level of state updates based on the received current resource utilization and cache load, including:

[0151] S1. Monitor the CPU utilization, memory usage, and network I / O of the cache server, as well as the overall load of the task scheduling service;

[0152] S2. Track the read / write throughput, concurrent connections, and cache hit rate of the preset cache to assess cache load;

[0153] S3. Define multi-level synchronization strategies, including strong consistency synchronization, eventual consistency synchronization, and asynchronous write, and set thresholds for resource utilization and cache load for each strategy level.

[0154] S4. When CPU utilization, memory usage, and network I / O are all below the corresponding low thresholds, and the cache load is idle, a strong consistency synchronization strategy is adopted to ensure the immediate visibility of state updates.

[0155] S5. When any of the following metrics exceeds the corresponding low threshold but does not reach the corresponding high threshold, or when the cache load is within the preset medium range, an eventual consistency synchronization strategy is adopted, using asynchronous copying or delayed writing to balance performance and consistency.

[0156] S6. When any resource utilization indicator or cache load reaches the corresponding high threshold, an asynchronous write strategy is adopted to prevent system overload.

[0157] When multiple consecutive state update failures or network fluctuations are detected, the preset cache automatically reduces the frequency of state updates or switches to a backup update channel to reduce system overhead and improve robustness, including:

[0158] S10. When multiple consecutive state update failures or network fluctuations are detected, the current state update frequency is adjusted to a preset low frequency mode.

[0159] S20. The preset cache attempts to establish a connection through the backup network interface or backup cache node, and switches to the backup update channel for status update. The backup update channel includes independent network links or cache instances with different network topologies.

[0160] S30. After switching to the backup update channel or reducing the update frequency, the preset cache continuously monitors the success rate of status updates and network conditions, and gradually restores the normal update frequency or the main update channel when the number of consecutive successful updates reaches the preset number or the network conditions return to normal.

[0161] Asynchronous tasks trigger state update events upon completion of each critical execution phase or upon detecting a state change. In practice, the definition of critical execution phases employs a combination of business logic analysis and execution time evaluation, dividing complex, time-consuming operations into multiple execution phases with clearly defined boundaries and characteristics.

[0162] Taking service deployment as an example, the key stages include environment initialization (5% of total time), code retrieval (15% of total time), dependency installation (20% of total time), compilation and building (30% of total time), image packaging (10% of total time), remote transfer (15% of total time), and service startup (5% of total time). Each stage has clearly defined start conditions, end conditions, and state transition triggers.

[0163] The status change detection adopts a multi-level monitoring mechanism, including progress threshold monitoring (triggered when the progress change exceeds 5%), time interval monitoring (forced to trigger once every preset time), abnormal event monitoring (triggered immediately when an error or warning is detected), and resource change monitoring (triggered when the CPU or memory usage changes exceed 10%).

[0164] Status update events include core fields such as a unique event identifier, trigger timestamp, task identifier, event type, and payload data. The current progress percentage is calculated using a weighted cumulative algorithm, with the following formula:

[0165] ;

[0166] in This represents the weight of the i-th stage. This indicates the percentage of completion for this stage. The list of completed subtasks uses a dynamic array structure to record detailed information such as the completion status, completion time, and execution result of each subtask in real time.

[0167] Resource consumption metrics at this stage are collected in real time via the system monitoring API, including key performance parameters such as CPU utilization, memory usage, disk I / O rate, and network bandwidth usage. After receiving state update events via a pre-set cache, an optimistic locking mechanism is used for concurrency control, ensuring the atomicity and consistency of state updates through version number comparison and conditional updates.

[0168] Asynchronous tasks synchronously refresh the lifetime of their unique task identifier each time they successfully update their current state, and the state update frequency and synchronization level are dynamically adjusted by a preset cache. The lifetime refresh is based on dynamic lifetime management and task lifecycle prediction technology. After each successful state update, the expected completion time is recalculated based on the task's current execution progress and historical execution data, and the lifetime value is adjusted accordingly.

[0169] The formula for calculating survival time is:

[0170] ,in The expected completion time, For the current time, This provides a safety buffer period. The dynamic adjustment mechanism uses intelligent algorithms to analyze task execution patterns, system load, and historical statistics to automatically optimize update frequency and synchronization level.

[0171] The update frequency adjustment employs an adaptive control algorithm, dynamically calculating the optimal update interval based on factors such as the characteristics of the task's execution phase, priority level, and system resource status. For rapidly changing phases (such as file transfer), the update frequency can be increased to once every 5 seconds; for stable execution phases (such as compilation and building), the update frequency can be decreased to once every 60 seconds.

[0172] The preset cache dynamically adjusts the minimum time interval for status updates based on the current execution stage of the asynchronous task and the preset task priority. Different stages in the task execution process can be categorized according to dimensions such as change frequency, resource consumption, and user attention. High-change-frequency stages (such as data transmission and real-time processing) require more frequent status updates to provide timely progress feedback; low-change-frequency stages (such as waiting for dependencies and batch processing) can use a lower update frequency to conserve system resources.

[0173] Task priority assessment includes factors such as business importance (40% weight), user level (25% weight), SLA requirements (20% weight), and urgency (15% weight). Priority scores range from 0 to 100, divided into three levels: high priority (80-100), medium priority (50-79), and low priority (0-49).

[0174] The dynamic adjustment algorithm comprehensively considers stage characteristics and priority weights to calculate the optimal update interval. The adjustment formula is as follows: ,in As the basic interval for the stage, Normalization priority (0-1). This is the system load adjustment factor.

[0175] The preset cache adjusts the status update synchronization level based on the current resource utilization and cache load. Cache server monitoring uses multi-dimensional performance metrics. CPU utilization monitoring obtains real-time CPU usage through the performance counter API, including user mode, kernel mode, I / O wait, idle time, etc. Memory usage monitoring includes key metrics such as physical memory usage, virtual memory usage, cache hit rate, and page swapping frequency. Network I / O monitoring includes network performance parameters such as bandwidth utilization, packet transmission rate, connection count, latency, and packet loss rate.

[0176] Task scheduling service load monitoring assesses overall load status using metrics such as queue length, thread pool utilization, task processing speed, and resource allocation. Cache load assessment uses a comprehensive load index, calculated using the following formula:

[0177] The various indicators have been normalized, and the hit rate is calculated in reverse to reflect the load level.

[0178] Strong consistency synchronization ensures that all nodes have completely consistent data, which is suitable for critical business data; eventual consistency synchronization allows for short-term data inconsistency, and eventually achieves a consistent state through asynchronous replication, balancing performance and consistency; asynchronous write strategy prioritizes write performance, and data consistency is guaranteed by background synchronization mechanism, which is suitable for high-load scenarios.

[0179] The pre-defined cache determines whether a task is real-time or batch based on its type and executes the corresponding synchronization strategy. Task type identification employs a multi-feature fusion classification algorithm. Real-time tasks are characterized by strong user interactivity (response time requirement < 5 seconds), high time sensitivity (latency tolerance < 30 seconds), and strong business criticality (impacting user experience or business processes). Batch processing tasks are characterized by large data volume (processing data > 1GB), long execution time (expected execution time > 10 minutes), high time tolerance (can be delayed), and high resource consumption (CPU or memory utilization > 50%).

[0180] The identification algorithm employs decision tree or random forest models, and the training data includes information such as historical task execution patterns, resource usage, and user behavior. The strong synchronization strategy uses synchronous replication and a strong consistency read-write mechanism. All write operations only return a success response after successful writing on the master node and at least one slave node. Read operations are performed from the master node to ensure data up-to-dateness. The asynchronous synchronization strategy uses asynchronous replication and eventual consistency. Write operations return a response immediately after successful writing on the master node. Data replication to slave nodes is performed asynchronously, and read operations can be performed from slave nodes to distribute the load.

[0181] Continuous state update failure detection uses a sliding window statistical algorithm to count the number of update failures within a 5-minute time window. When the failure rate exceeds 30%, degradation processing is triggered. Network fluctuation detection uses multi-dimensional network quality assessment, including indicators such as latency change rate (triggered when exceeding 50%), packet loss rate (triggered when exceeding 5%), bandwidth fluctuation (triggered when exceeding 30%), and connection stability (triggered when connection reconstruction frequency exceeds the threshold).

[0182] The frequency reduction strategy employs an exponential backoff algorithm, and the reduction formula is as follows: ,in The minimum frequency for consecutive failures is no less than 10% of the original frequency. Backup update channels include multiple options such as backup network interfaces (e.g., switching from the primary network card to the backup network card), backup cache nodes (e.g., switching from the primary Redis node to the slave node), and local cache (temporarily storing state information).

[0183] Channel switching assesses channel availability through heartbeat detection, connectivity testing, and response time evaluation. Recovery monitoring combines consecutive successful updates with network quality assessment. When 10 consecutive successful updates are achieved and network latency returns to the normal range (<100ms), a gradual recovery to normal mode begins.

[0184] This embodiment provides users and the system with real-time, accurate, and detailed task execution information through multi-dimensional progress tracking and resource monitoring, significantly improving system observability and user experience. Dynamic lifetime management and frequency adjustment, through intelligent algorithms and real-time monitoring, maximize system performance while ensuring data timeliness, effectively balancing real-time performance and resource consumption. Differentiated synchronization strategies provide customized quality of service guarantees based on task characteristics and system load, ensuring that critical tasks are prioritized while ordinary tasks do not excessively consume system resources. Fault detection and adaptive recovery mechanisms, through multi-layered anomaly identification and intelligent switching strategies, ensure stable operation and rapid recovery capabilities of the system under various complex network environments and abnormal conditions.

[0185] In one embodiment of this invention, the following steps are included before starting the asynchronous task:

[0186] S710: Check the preset cache for any currently executing tasks associated with time-consuming operations;

[0187] S720: If a task is currently being executed, return the unique task identifier and initial state of the currently executing task, without starting a new asynchronous task.

[0188] The system checks for ongoing tasks associated with time-consuming operations using a pre-defined cache, based on task deduplication algorithms and status query techniques. In practice, task correlation determination employs a multi-dimensional matching algorithm, including operation type matching, target environment matching, and parameter similarity matching.

[0189] Operation type matching compares basic task type identifiers, such as service deployment, service packaging, and data migration, to ensure that only operations of the same type undergo further correlation analysis. Target environment matching checks whether the execution targets of the tasks are the same, including key resource identifiers such as target servers, deployment environments, and database instances, determining environment consistency through precise string matching or regular expression matching.

[0190] Parameter similarity matching employs parameter hash comparison and key parameter extraction techniques. Core parameters of the task (such as deployment package version, configuration file content, execution options, etc.) are standardized and then hashed. Parameter similarity is quickly determined by comparing these hash values. For complex parameter structures, a depth-first comparison algorithm is used, recursively comparing the contents of nested objects and arrays.

[0191] The inspection process first constructs query conditions, generating query key values ​​based on the operation characteristics of the current request. Then, it performs range queries or pattern matching queries through the cached API to obtain all potentially related currently executing tasks. The query results are processed by a correlation scoring algorithm to calculate the matching degree between each candidate task and the current request. Tasks with a matching degree exceeding a preset threshold are considered duplicate tasks. To improve query efficiency, the system employs an index optimization strategy, creating secondary indexes in the cache based on dimensions such as operation type, target environment, and parameter hash, supporting fast multi-condition queries.

[0192] If a task is already in progress, the system returns information about the existing task and prevents new tasks from starting. When a duplicate task is detected, the system first verifies the validity and execution status of the existing task to ensure that the returned task is indeed in a normal execution state and not abnormally suspended or invalid. Validity verification includes several aspects such as state consistency checks, timestamp verification, and execution thread liveness checks.

[0193] State consistency check ensures the accuracy of state information by comparing the state information in the cache with the task state in the actual execution environment; timestamp verification checks the last update time of the task, and tasks that have not been updated after a preset time threshold may have terminated abnormally; execution thread liveness check queries the system API to see if the corresponding execution thread or process is still running.

[0194] Upon successful verification, a detailed response is returned to the client. This response includes the unique identifier of the existing task, its current execution status, execution progress, estimated completion time, and status query interface. The response uses a standardized JSON structure for easy client parsing and processing. Simultaneously, duplicate task detection events are logged, including the original request information, detection results, and returned task information, facilitating subsequent analysis and optimization.

[0195] To enhance user experience, the response also includes a friendly notification indicating that the same task is being executed, avoiding user confusion. In certain scenarios, task merging is supported, allowing multiple identical requests to be associated with the same task, and a callback mechanism to notify all relevant requesters upon task completion.

[0196] The task deduplication strategy adopts a layered filtering approach. The first layer performs fast basic matching, quickly filtering candidate tasks by accurately matching key fields such as operation type and target identifier. The second layer performs detailed parameter comparison, using a deep comparison algorithm to analyze the similarity of task parameters. The third layer performs contextual analysis, considering factors such as task execution environment, dependencies, and time windows.

[0197] The matching algorithm supports two modes: fuzzy matching and exact matching. Fuzzy matching is suitable for tasks with slightly different but essentially the same parameters, while exact matching is suitable for scenarios requiring strict consistency. Similarity calculation uses a weighted scoring formula, with different types of parameters having different weights; core parameters have higher weights, while optional parameters have lower weights.

[0198] This embodiment employs a distributed deduplication strategy, distributing deduplication checks across multiple cache nodes using a consistent hashing algorithm to avoid single-point performance bottlenecks. The cached data is organized in a hierarchical structure, sharded and stored according to operation type, time window, and other dimensions to improve query efficiency. Exception handling and boundary condition management ensure the robustness and reliability of the deduplication mechanism. When the cache service is unavailable, a degradation strategy is adopted, which can either skip deduplication checks and execute the task directly, or use the local cache for limited deduplication checks. In case of network latency or timeouts, a reasonable timeout threshold is set to avoid request blocking caused by deduplication checks. In case of inconsistent task states, a state synchronization and repair process is triggered to ensure that the state information in the cache is consistent with the actual execution state. Concurrent request processing employs atomic operations and locking mechanisms to prevent duplicate execution caused by multiple identical requests simultaneously undergoing deduplication checks.

[0199] This embodiment automatically deletes expired task records and removes duplicate information, preventing cached data from growing indefinitely and effectively solving resource waste and conflict problems in asynchronous task processing. It can also accurately identify duplicate task requests, avoiding repeated execution of the same operations and significantly improving system resource utilization efficiency. A robust validity verification mechanism ensures that the returned existing task information is accurate and reliable, providing a consistent user experience for clients.

[0200] This embodiment not only prevents the waste of system resources, but also improves the user experience and avoids the poor experience caused by users repeatedly submitting requests.

[0201] In one embodiment of this invention, the method further includes the following steps:

[0202] S810: In response to receiving a retry request, clear the existing state associated with the unique task identifier in the preset cache before starting the asynchronous task.

[0203] In response to receiving a retry request, the system clears the existing state associated with the unique task identifier from the preset cache before starting the asynchronous task. In practice, the identification of retry requests employs a dedicated request identification and verification mechanism. Retry requests typically contain key information such as specific request header identifiers, retry reason codes, and the original task identifier.

[0204] First, the retry request is validated for validity. If validation passes, the current state of the task is analyzed to determine if a retry is appropriate. For example, a failed task can be retried directly, a task currently executing may need to be terminated before retrying, and a task that has already completed successfully requires special re-execution permissions. The retry strategy also includes protective mechanisms such as retry limit, retry interval control, and retry condition judgment to prevent resource waste caused by infinite retries.

[0205] Clears existing states associated with the unique task identifier from the preset cache. The state clearing operation uses a batch deletion mechanism to ensure that all related state information is completely cleared. The clearing scope includes all cached entries related to the task, such as basic task state information, execution progress records, intermediate result data, error log information, and performance statistics.

[0206] The cleanup operation first identifies all relevant cache keys through pattern matching or prefix lookup. After identification, a batch delete command (such as Redis's DEL or HDEL command) is used to delete all relevant entries at once, avoiding inconsistencies caused by partial deletion.

[0207] The deletion operation employs a transaction mechanism, wrapped by the MULTI / EXEC command, to ensure its atomicity. In a distributed caching environment, the clearing operation needs to be synchronized to all relevant cache nodes, ensuring data consistency through master-slave replication or cluster synchronization mechanisms. The clearing process also includes a backup mechanism, backing up existing state information to a temporary storage area before deletion for recovery in case of operation failure.

[0208] The state cleanup adopts a layered approach. First, it cleans up volatile state information (such as current progress and temporary data), then it cleans up core state information (such as task status and configuration parameters), and finally it cleans up historical records and log information. The cleanup order is designed with data dependencies and rollback requirements in mind, ensuring effective recovery in case of anomalies during the cleanup process.

[0209] The cleanup operation employs a combination of soft and hard deletion strategies. Important historical data is soft-deleted, marked as deleted but the data content is retained for easy auditing and troubleshooting. Temporary data and cached information are hard-deleted to completely free up storage space.

[0210] This embodiment provides comprehensive error recovery and re-execution capabilities for asynchronous task processing systems. The retry request identification and verification mechanism ensures the legality and security of retry operations, preventing malicious or abnormal retry requests from impacting the system. This embodiment not only improves the system's fault tolerance and user experience but also provides flexible error recovery methods for complex asynchronous task processing scenarios, ensuring the ultimate successful execution of critical business operations.

[0211] This application also provides an electronic device, characterized in that it includes:

[0212] The memory is configured to store instructions; and

[0213] The processor is configured to retrieve instructions from memory and, when executing instructions, implement the aforementioned asynchronous task and cache-based status polling method.

[0214] In this embodiment, the electronic device can be a tablet computer, desktop computer, laptop computer, handheld computer, wearable device, laptop computer, ultra-mobile personal computer (UMPC), netbook, or other device with a processor. Of course, the electronic device can also be a server. This application embodiment does not impose any special limitations on the specific form of the electronic device.

[0215] This application also provides a machine-readable storage medium, characterized in that the machine-readable storage medium stores instructions for causing the machine to execute the above-described asynchronous task and cache-based state polling method.

[0216] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0217] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0218] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0219] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0220] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0221] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0222] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0223] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0224] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for polling the status based on asynchronous tasks and cache, characterized in that, The method comprises the following steps: in response to receiving an execution request of a time-consuming operation, generating a unique task identifier associated with the time-consuming operation, wherein the time-consuming operation comprises service deployment or service packaging; starting the time-consuming operation as an asynchronous task; storing an initial state associated with the unique task identifier in a preset cache, the initial state being used to indicate that the asynchronous task is being executed; returning the unique task identifier and the initial state to a requester of the execution request; in response to receiving a state query request including the unique task identifier, retrieving a current state associated with the unique task identifier from the preset cache; and returning the current state to a requester of the state query request; wherein the asynchronous task is used to update the current state associated with the unique task identifier in the preset cache during execution or after execution is completed, comprising the following steps: the asynchronous task triggers a state update event when completing each key execution stage or detecting a state change, the state update event being used to carry any one or more of the current progress percentage of the asynchronous task, a list of completed sub-tasks, and a resource consumption indicator of the current stage, wherein the preset cache is used to receive the state update event and update the current state according to the unique task identifier using an optimistic locking mechanism; the asynchronous task synchronously refreshes the time to live of the unique task identifier each time the current state is successfully updated; the preset cache dynamically adjusts a minimum time interval for state updating according to a current execution stage of the asynchronous task and a preset task priority; monitoring CPU utilization, memory usage and network I / O of the cache server, and overall load of the task scheduling service; tracking read-write throughput, concurrent connection number and cache hit rate of the preset cache to evaluate cache load; defining multi-level synchronization strategies, including strong consistency synchronization, eventual consistency synchronization and asynchronous writing, and setting threshold values of resource utilization and cache load for each level of strategy; when the CPU utilization, memory usage and network I / O are all below the corresponding low threshold values, and the cache load is in an idle state, the strong consistency synchronization strategy is adopted to ensure the immediate visibility of state updating; when any one of the CPU utilization, memory usage or network I / O exceeds the corresponding low threshold value but does not reach the corresponding high threshold value, or the cache load is in a preset medium range, the eventual consistency synchronization strategy is adopted to balance performance and consistency through asynchronous replication or delayed writing; when any one of the resource utilization indicators or the cache load reaches the corresponding high threshold value, the asynchronous writing strategy is adopted to prevent system overload; the preset cache determines whether the asynchronous task belongs to a real-time task or a batch processing task; if the asynchronous task belongs to a real-time task, the preset cache executes the strong synchronization strategy; if the asynchronous task belongs to a batch processing task, the preset cache executes the asynchronous synchronization strategy.

2. The method of claim 1, wherein, starting the time-consuming operation as an asynchronous task comprises: encapsulating the time-consuming operation as an executable task unit, the task unit including a unique task identifier and specific execution logic of the time-consuming operation; The task unit is submitted to a preset task scheduling service. The task scheduling service is used for maintaining a task queue and a plurality of worker thread pools, and distributing the task unit to a corresponding worker thread pool for processing according to a type and a priority of the time-consuming operation. A worker thread in the worker thread pool is used for receiving the task unit and starting specific execution logic of the time-consuming operation. After the worker thread starts the specific execution logic of the time-consuming operation, an initial execution log of the asynchronous task is written to a preset cache. The initial execution log includes a task start time, an execution thread ID, and an expected first state update time. The task scheduling service starts a monitoring process after starting the asynchronous task. The monitoring process is used for checking whether the first state update of the asynchronous task has been completed within a preset time interval, so as to ensure that the asynchronous task is successfully activated and starts to execute.

3. The method of claim 1, wherein, The preset cache includes a memory-based cache or a record for storing a task state in a database.

4. The method of claim 3, wherein, An initial state associated with a unique task identifier is stored in the preset cache, including: A task state data structure is constructed. The task state data structure includes a unique task identifier, an initial state, a task creation timestamp, a task type, and a task initiator identifier. The task state data structure is serialized into a preset format, and the serialized task state data structure is stored in the preset cache through an API of the preset cache. A time to live is set for the stored initial state, so as to automatically clean up the expired state when the asynchronous task is abnormally terminated or is not updated for a long time. When the initial state is stored, an expected completion time range of the time-consuming operation is recorded. The preset cache is used for synchronously copying the task state data structure to at least one backup cache node.

5. The method of claim 1, wherein, The asynchronous task updates a current state associated with the unique task identifier in the preset cache during an execution process or after the execution is completed, including: During the execution process of the asynchronous task, intermediate step states, error messages, and / or solutions are periodically stored in the preset cache; or After the execution is completed, a final execution result is stored in the preset cache. The final execution result includes a success or failure indication, an error message, and / or a solution.

6. The method of claim 1, wherein, Before starting the asynchronous task, the following is further included: It is checked through the preset cache whether there is an executing task associated with the time-consuming operation; In the case that there is an executing task, a unique task identifier and an initial state of the executing task are returned, and a new asynchronous task is not started.

7. The method of claim 6, wherein, The method further includes: In response to receiving a retry request, the existing state associated with the unique task identifier in the preset cache is cleared before starting the asynchronous task.

8. An electronic device, comprising: It includes: a memory configured to store instructions; and a processor configured to invoke the instructions from the memory and capable of implementing the asynchronous task and cache-based state polling method according to any one of claims 1 to 7 when the instructions are executed.

9. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing a machine to execute the asynchronous task and cache-based state polling method according to any one of claims 1 to 7.

Images