Task processing method and device, electronic equipment, storage medium and program product
By using a task execution time prediction model and a dynamic polling strategy, the problem of unreasonable polling strategies in asynchronous task processing is solved, achieving efficient task status query and resource utilization, and improving user experience and system performance.
Patent Information
- Application Number
- CN202511629284.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-07
- Publication Date
- 2026-02-17
AI Technical Summary
In existing technologies, the timed polling strategy for asynchronous task processing is difficult to set properly, which leads to user delays or frequent requests after the task is completed, wasting network bandwidth and server resources, resulting in poor task processing performance.
A task execution time prediction model is adopted to predict the task execution time based on business type, parameters and data scale, dynamically adjust the polling interval, and build a dynamic polling strategy. The front-end device determines the polling interval based on the predicted time, and the server provides real-time feedback on the task status.
By employing a dynamic polling strategy, task processing efficiency was improved, resource waste and response latency were reduced, and business processing performance and user experience were enhanced.
Smart Images

Figure CN121542029A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of electronic device technology, and in particular to a task processing method, apparatus, electronic device, storage medium, and program product. Background Technology
[0002] Currently, asynchronous task processing is widely used in time-consuming business scenarios, such as big data processing and batch computing.
[0003] In existing technologies, asynchronous task processing typically employs timed polling or long-lived connection strategies to synchronize task status. Specifically, in timed polling, each front-end device periodically sends requests to the server to query the task status until the task is completed. However, this method suffers from difficulties in setting a reasonable polling interval. For example, an interval that is too long may prevent users from receiving results promptly after task completion, causing delays; an interval that is too short may trigger frequent requests, wasting network bandwidth and server resources. This results in poor task processing performance. Summary of the Invention
[0004] This application provides a task processing method, apparatus, electronic device, storage medium, and program product that can improve business processing performance.
[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, a task processing method is provided, comprising: a server receiving N business processing requests sent by N front-end devices, each business processing request containing a business type, business parameters, and business data scale of a business processing task, where N is an integer greater than 1; the server storing the N business processing tasks corresponding to the N business processing requests as asynchronous tasks sequentially into a task execution queue for execution; the server processing the business type, business parameters, and business data scale of the N business processing tasks respectively using a task execution time estimation model to obtain the estimated execution time of each business processing task; the server returning the estimated execution time of the corresponding business processing task to each front-end device; each front-end device constructing a dynamic polling strategy for the corresponding business processing task based on the received estimated execution time, and sending a task status query request to the server in a polling manner according to the dynamic polling strategy; the task status query request being used to query the execution status of the corresponding business processing task, the task status query request including the task index information of the corresponding business processing task; and the server sending the task status information of the business processing task corresponding to the front-end device to the front-end device each time it receives a task status query request from a front-end device.
[0006] In this embodiment, when N front-end devices request the server to execute corresponding business processing tasks, the server can store the business processing requests from the N front-end devices as asynchronous tasks sequentially in a task execution queue before execution. The server then estimates the execution time of each front-end device's corresponding business processing task using a task execution time estimation model and sends the estimated execution times to each front-end device. Each front-end device can determine a dynamic polling strategy for querying task status from the server based on the estimated execution time, and send task status query requests to the server in a polling manner according to this strategy. By storing and executing the business processing tasks of each front-end device as asynchronous tasks, task processing efficiency is improved. Furthermore, by determining the dynamic polling strategy based on the estimated execution time, resource waste or response latency issues caused by fixed-interval polling and long-term server resource occupation caused by fixed-time queries are avoided. This significantly improves business processing efficiency and resource utilization efficiency, thereby enhancing business processing performance.
[0007] In one possible implementation of the first aspect, each front-end device constructs a dynamic polling strategy for a corresponding business processing task based on the received estimated task execution time, including: a first front-end device determining the estimated task execution time as a time interval base, wherein the first front-end device is one of the N front-end devices; the first front-end device determines the initiation time interval for each polling based on the time interval base and a preset time interval coefficient; wherein the initiation time interval for the nth polling is obtained by multiplying the time interval base by the time interval coefficient corresponding to the nth polling, and n is a positive integer; each front-end device sends a task status query request to the server according to the dynamic polling strategy, including: the first front-end device sending the task status query request to the server at the corresponding time point according to the determined initiation time interval for each polling.
[0008] In this embodiment, the time interval base is determined based on the estimated task execution time, and the time interval for each polling is dynamically determined based on the time interval coefficient and the time interval coefficient. This quantifies the estimated execution time into a specific time interval base, providing an accurate calculation basis for subsequent dynamic polling and ensuring a high degree of matching between the polling strategy and the task characteristics.
[0009] In another possible implementation of the first aspect, the preset time interval coefficient satisfies the following: the time interval coefficient corresponding to the first polling is greater than the time interval coefficient corresponding to the second polling and all subsequent pollings.
[0010] In this embodiment, by using a time interval coefficient decreasing strategy, unnecessary frequent queries are reduced in the early stages of task execution, and query density is increased when the task is about to be completed, thus achieving the best balance between query efficiency and resource consumption.
[0011] In another possible implementation of the first aspect, the first time interval coefficient corresponding to the first polling is 0.8, the second time interval coefficient corresponding to the second polling is 0.2, and the time interval coefficient corresponding to the third polling and each subsequent polling is 0.1; the method further includes: when the number of polling requests sent by the first front-end device to the server for task status query exceeds the polling number threshold, increasing the time interval coefficient of subsequent polling.
[0012] In this embodiment, the initial time interval is set to be relatively long to avoid frequent requests in the early stages of task execution; subsequent polling increases the polling frequency by adjusting the time interval coefficient, thereby reducing query latency after task execution is completed.
[0013] In another possible implementation of the first aspect, the method further includes: the front-end device receiving task status information returned by the server; if the task status information returned by the server indicates that the task status of the business processing task corresponding to the front-end device is completed, then the front-end device stops sending task status query requests to the server and executes the business operation corresponding to the business processing task; or, if the task status information returned by the server indicates that the task status of the business processing task corresponding to the front-end device is incomplete, then the front-end device continues to determine the next polling time interval according to the dynamic polling strategy and sends a task status query request to the server according to the time interval.
[0014] In this embodiment, continuous polling ensures real-time acquisition of task status, and timely task completion identification and polling termination avoid unnecessary subsequent queries, saving network bandwidth and server resources while providing a smooth user experience.
[0015] In another possible implementation of the first aspect, the method further includes: after receiving the estimated execution time of the business processing task corresponding to the front-end device returned by the server, the front-end device starts a first timer, the first timer being used to record the waiting time consumed since the start of polling for executing the business processing task corresponding to the front-end device; the front-end device calculates the task progress information of the corresponding business processing task based on the estimated execution time of the task and the waiting time recorded by the timer; the front-end device displays a progress feedback component on the front-end interface based on the task progress information, the progress feedback component including the estimated remaining execution time of the corresponding business processing task and a graphical progress bar.
[0016] In this embodiment of the application, the front-end device can display the task progress information of the first business processing task on the task status interface according to the task status information returned by the server, so that the user can have an intuitive perception of the task execution status and enhance the human-computer interaction performance.
[0017] In another possible implementation of the first aspect, the task status information includes the actual execution time of the corresponding business processing task; after the front-end device displays the progress feedback component on the front-end interface, the method further includes: after receiving the task status information of the business processing task corresponding to the front-end device returned by the server, the front-end device recalculates the task progress information of the business processing task corresponding to the front-end device based on the actual execution time of the corresponding business processing task in the task status information, and updates the progress feedback component based on the task progress information.
[0018] In this embodiment, the front-end device can recalculate and update the task progress information of the business processing task based on the actual execution time of the business processing task returned by the server. In this way, progress calibration based on real data improves the accuracy of progress feedback.
[0019] In another possible implementation of the first aspect, the method further includes: after the server completes a business processing task, it obtains task data for the business processing task, the task data including the business type, business parameters, business data scale, and actual task execution time of the business processing task; the server processes the task data and adds it to the training set of the task execution time prediction model; when the amount of data in the training set reaches a preset threshold, the server retrains the task execution time prediction model using the updated training set.
[0020] In this embodiment, the server can use the task information of the executed business processing tasks to incrementally learn the model. Without rebuilding the model, new data is continuously added to enhance the model, so that the task execution time prediction model is continuously adjusted and optimized, making its prediction results more and more accurate. Continuous model optimization makes the prediction accuracy improve over time, so that the model has self-learning ability, can adapt to changes in business models, and maintain long-term effectiveness and reliability.
[0021] Secondly, a task processing device is provided, comprising: a receiving module, a storage module, a processing module, and a sending module, wherein: the receiving module is used to receive N service processing requests sent by N front-end devices, each service processing request containing a service type, service parameters, and service data scale of a service processing task; the storage module is used to store the N service processing tasks corresponding to the N service processing requests as asynchronous tasks sequentially into a task execution queue for execution; the processing module is used to process the service type, service parameters, and service data scale of the N service processing tasks respectively using a task execution time prediction model to obtain the estimated execution time of each service processing task; The sending module is configured to return the estimated execution time of the corresponding business processing task to each front-end device respectively; the processing module is further configured to construct a dynamic polling strategy for the corresponding business processing task based on the received estimated execution time, and send a task status query request to the server in a polling manner according to the dynamic polling strategy; the task status query request is used to query the execution status of the corresponding business processing task, and the task status query request includes the task index information of the corresponding business processing task; the sending module is further configured to send the task status information of the business processing task corresponding to the front-end device to the front-end device each time a task status query request is received from the front-end device.
[0022] Thirdly, an electronic device is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method as described in the first aspect and any possible implementation thereof.
[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When executed by a processor, these computer instructions are used to implement the method described in the first aspect and any possible implementation thereof.
[0024] Fifthly, embodiments of this application provide a computer program product that, when run on a computer or executed by a computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be the electronic device described in the third aspect and any possible implementation thereof.
[0025] It is understood that the beneficial effects achieved by the task processing apparatus described in the second aspect, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to as the beneficial effects in the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description
[0026] Figure 1 A flowchart illustrating a task processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating another task processing method provided in an embodiment of this application; Figure 3 A flowchart illustrating another task processing method provided in an embodiment of this application; Figure 4 A flowchart illustrating another task processing method provided in an embodiment of this application; Figure 5A A schematic diagram of an interface to which the task processing method provided in the embodiments of this application can be applied; Figure 5B A schematic diagram of another interface to which the task processing method provided in the embodiments of this application can be applied; Figure 6 A flowchart illustrating another task processing method provided in an embodiment of this application; Figure 7 This is a schematic diagram illustrating the process of retraining a task execution time prediction model according to an embodiment of this application. Figure 8 A schematic diagram of a task processing system provided in an embodiment of this application; Figure 9 A schematic diagram of the timing flow of a task processing method provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.
[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0029] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.
[0030] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.
[0031] The following explains the nouns or terms used in the embodiments of this application.
[0032] Asynchronous tasks refer to computational tasks received and created by a computer system, but whose processing does not require the user or requester to synchronously wait for the result. These tasks are typically submitted to a background task queue for sequential or parallel execution. Their execution time is relatively long, and the results are obtained subsequently through callbacks, notifications, or queries. In this application, it specifically refers to time-consuming business operations such as large-scale data distribution calculations and complex report generation.
[0033] A queue is a data structure that follows the First-In-First-Out (FIFO) principle. In this application, it refers to an ordered list used to store and manage asynchronous tasks to be processed. Task queues enable business systems to buffer, schedule, and distribute submitted asynchronous tasks, and are a core component for implementing asynchronous task processing.
[0034] The task processing method provided in this application can be applied to scenarios where tasks need to be processed, such as various business scenarios that require processing highly complex, long-time asynchronous tasks.
[0035] In this scenario, business systems often need to handle business requests with large amounts of data, complex calculation logic, and unpredictable execution time, such as the distribution of maintenance fund revenue, daily batch reconciliation in the financial sector, and data cleaning and report generation for big data platforms. These tasks cannot return results immediately.
[0036] In related technologies, polling at fixed time intervals or long connections are commonly used to obtain the results of asynchronous tasks. Fixed polling intervals are difficult to set; too long an interval leads to delays in obtaining results, while too short an interval results in unnecessary consumption of server and network resources. Long connections, on the other hand, consume a large amount of server resources in high-concurrency scenarios, and connection management is complex, resulting in poor task processing performance.
[0037] The task processing method provided in this application introduces a task execution time prediction model, which provides a basis for the front-end device to dynamically adjust the polling interval and constructs a real-time task progress feedback mechanism. This significantly improves the efficiency of task status query and user interaction experience while reducing system resource consumption.
[0038] It should be noted that the task processing method provided in this application embodiment can also be applied to other scenarios with similar asynchronous processing requirements, such as cloud computing resource orchestration, media file transcoding processing, etc., and this application embodiment does not limit it in this regard.
[0039] Figure 1 This is a flowchart illustrating a task processing method provided in an embodiment of this application, as shown below. Figure 1 As shown, the task processing method may include the following steps 201 to 206: Step 201: The server receives N business processing requests sent by N front-end devices.
[0040] Each business processing request contains the business type, business parameters, and business data size of a business processing task, where N is an integer greater than 1.
[0041] In this embodiment, the server receives service processing requests from N front-end devices through a distributed interface gateway, where N is an integer greater than 1. Each service processing request includes key information such as service type, service parameters, and service data scale. The service type identifies the type of task, such as data report generation or fund revenue sharing; the service parameters contain the specific configuration parameters required for task execution; and the service data scale represents the amount of data processed by the task.
[0042] In some embodiments of this application, the server receives HTTP / HTTPS requests through an exposed RESTful API interface, and the request body is transmitted in JSON format for structured data transmission.
[0043] In some embodiments of this application, each service processing request includes the following metadata fields: business_type: String type, identifying the business category (e.g., "fund_allocation"); business_params: A JSON object containing business-specific parameters (such as algorithm version and calculation rules); data_scale: An integer value representing the number of data records to be processed or the data volume.
[0044] In some embodiments of this application, the server interface layer performs format validation and business parameter validity verification on the received requests.
[0045] For example, in the housing maintenance fund management system, the server simultaneously receives business processing requests from 10 regional management centers. Each business processing request includes fields such as: "business_type", "revenue_allocation", and "business_params": {algorithm_version: "v2.1", "calculation_period": "2024-Q1"}.
[0046] In this way, unified access management of multiple front-end devices is achieved through standardized request formats, and the structured parameter design provides accurate input features for subsequent task classification and task execution time estimation models, ensuring availability under high-load scenarios.
[0047] Step 202: The server stores the N business processing tasks corresponding to the N business processing requests as asynchronous tasks into the task execution queue and then executes them.
[0048] In some embodiments of this application, after receiving a business processing request, the server converts each business processing task into an asynchronous task and stores them in a task execution queue according to the receiving order or priority strategy. The task execution queue adopts a first-in-first-out (FIFO) scheduling strategy to ensure the orderly execution of tasks. Simultaneously, the server starts the task execution engine, retrieves tasks from the queue, and executes the corresponding business logic.
[0049] Optionally, the task execution queue is implemented using a distributed message middleware, such as RabbitMQ or Apache Kafka, to support task scheduling in high-concurrency scenarios. Each task is assigned a unique task identifier in the queue for subsequent real-time status retrieval and result querying.
[0050] In some embodiments of this application, the server manages the task execution queue based on Redis or RabbitMQ through an asynchronous task service.
[0051] In some embodiments of this application, the task execution queue includes the task index, task ID, creation timestamp, priority weight, etc. of each business processing task.
[0052] In some embodiments of this application, the server calls the task executor in a thread pool mode, consuming tasks from the task execution queue and calling the corresponding business processing engine.
[0053] For example, the server serializes the 10 received regional tasks and stores them in the Redis task queue. Then, the task executor retrieves the tasks from the queue in FIFO order and calls the amortized calculation engine for processing.
[0054] In this way, by decoupling task submission and execution through message queues, the system throughput and resilience are improved, ensuring the timely processing of important tasks.
[0055] Step 203: The server processes the business type, business parameters, and business data scale of the N business processing tasks using the task execution time estimation model to obtain the estimated execution time of each business processing task.
[0056] In this embodiment, the server is equipped with a task execution time prediction model. This model is built based on machine learning algorithms and can predict the execution time according to task characteristics. The model input includes features such as business type, business parameters, and business data scale, and the output is the estimated execution time of the task.
[0057] Specifically, the task execution time prediction model employs a multiple linear regression algorithm. By learning from historical task execution data, it establishes a mapping relationship between task characteristics and execution time. During model training, feature engineering methods are used to preprocess the input features, including one-hot encoding of business types and normalization of data size. For example, the aforementioned task execution time prediction model can be a multiple linear regression model.
[0058] For example, for a revenue sharing task with a data scale of 500,000 records, the model, combined with the current system load, predicts that the task execution time is 180 seconds.
[0059] For example, the algorithm for the multiple linear regression model is as follows: T = β0 + β1X1 + β2X2 + β3X3 + ε, where T is the estimated time, X1 is the business type code, X2 is the data size, X3 is the system load coefficient, and β0 is the model coefficient, which is obtained by training using the least squares method.
[0060] In some embodiments of this application, the server performs feature engineering on each business processing task using a task execution time prediction model to obtain the estimated execution time of each business processing task.
[0061] For example, the server performs One-Hot encoding on the business type of each business processing task using a task execution time prediction model, and performs logarithmic transformation on the data scale to obtain the estimated execution time of each business processing task.
[0062] In some embodiments of this application, the estimated execution time of the task can be the total expected execution time of the business processing task, or the expected end time of the business processing task.
[0063] Step 204: The server returns the estimated execution time of the corresponding business processing task to each front-end device.
[0064] In some embodiments of this application, the estimated execution time of the corresponding business processing task is returned to each front-end device through an HTTP long connection or WebSocket to achieve real-time response.
[0065] Step 205: Each front-end device constructs a dynamic polling strategy for the corresponding business processing task based on the received estimated task execution time, and sends task status query requests to the server in a polling manner according to the dynamic polling strategy.
[0066] The task status query request mentioned above is used to query the execution status of the corresponding business processing task. The task status query request includes the task index information or task ID of the corresponding business processing task.
[0067] In some embodiments of this application, each front-end device determines the polling time interval (or polling interval) for initiating polling with the server based on the received estimated task execution time, and sends a task status query request to the server in polling based on the polling time interval.
[0068] Understandably, the core of the dynamic polling strategy lies in dynamically adjusting the polling time interval according to different stages of task execution.
[0069] Specifically, the front-end device uses the estimated task execution time as the base for the time interval and calculates the specific time interval for each polling based on a preset time interval coefficient table. The time interval coefficient table defines the time interval coefficients corresponding to different polling numbers, with the first polling using a larger coefficient value and subsequent polling using decreasing coefficient values.
[0070] For example, for a task with an estimated execution time of 120 seconds, the front-end device calculates the first polling interval as 96 seconds (120 × 0.8), the second polling interval as 24 seconds (120 × 0.2), and the third and subsequent polling intervals as 12 seconds (120 × 0.1).
[0071] Step 206: When the server receives a task status query request from a front-end device, it sends the task status information of the business processing task corresponding to the front-end device to the front-end device.
[0072] In some embodiments of this application, the task status information of the business processing task may include: the execution duration of the business processing task, the execution progress of the business processing task, the execution success of the business processing task, the execution failure of the business processing task, and other status information.
[0073] The task processing method provided in this application embodiment allows N front-end devices to request a server to execute corresponding business processing tasks. The server can store these requests as asynchronous tasks sequentially in a task execution queue before execution. A task execution time prediction model is used to estimate the execution time of each front-end device's corresponding business processing task, and the estimated execution times are sent to each front-end device. Each front-end device can determine a dynamic polling strategy for querying task status from the server based on the estimated execution time, and send task status query requests to the server in a polling manner according to this strategy. By storing and executing the business processing tasks of each front-end device as asynchronous tasks, task processing efficiency is improved. Furthermore, determining the dynamic polling strategy based on the estimated execution time avoids resource waste or response latency issues caused by fixed-interval polling, and avoids long-term server resource occupation caused by fixed-time queries. This significantly improves business processing efficiency and resource utilization efficiency, thereby enhancing business processing performance.
[0074] In some embodiments of this application, step 205 above, in which each front-end device constructs a dynamic polling strategy for the corresponding business processing task based on the received estimated task execution time, may include the following steps 205a and 205b: Step 205a: The first front-end device determines the estimated task execution time as the time interval base.
[0075] The first front-end device is one of the N front-end devices.
[0076] Step 205b: The first front-end device determines the initiation time interval for each polling based on the time interval base and the preset time interval coefficient; wherein, the initiation time interval for the nth polling is obtained by multiplying the time interval base by the time interval coefficient corresponding to the nth polling, and n is a positive integer.
[0077] For example, combining steps 205a and 205b above, the process in step 205 where each front-end device sends a task status query request to the server according to a dynamic polling strategy may include the following step 205c: Step 205c: The first front-end device sends a task status query request to the server at the corresponding time point according to the determined time interval for each polling.
[0078] In some embodiments of this application, after receiving the estimated task execution time returned by the server, the front-end device first sets this estimated time as the base time unit of the polling strategy, i.e., the time interval base. This base serves as the basic reference value for calculating all subsequent polling intervals, ensuring a reasonable correlation between the polling frequency and the expected task execution duration.
[0079] For example, the front-end device maintains a polling policy manager that receives the estimated task execution time from the server and converts it into a time interval base with millisecond precision. This base remains constant throughout the polling cycle, providing a stable baseline reference for subsequent dynamic interval calculations. For instance, assuming the server returns an estimated task execution time of 120 seconds, the front-end device converts it to 120,000 milliseconds as the time interval base and stores it in the base register of the polling policy manager.
[0080] In this embodiment, the time interval base is determined based on the estimated task execution time, and the time interval for each polling is dynamically determined based on the time interval coefficient and the time interval coefficient. This quantifies the estimated execution time into a specific time interval base, providing an accurate calculation basis for subsequent dynamic polling and ensuring a high degree of matching between the polling strategy and the task characteristics.
[0081] In some embodiments of this application, the preset time interval coefficient satisfies the following: the time interval coefficient corresponding to the first polling is greater than the time interval coefficient corresponding to the second polling and each subsequent polling.
[0082] In some embodiments of this application, the front-end device calculates the specific initiation time interval for each poll by multiplying the time interval base by the coefficient corresponding to each polling according to a preset time interval coefficient table.
[0083] For example, a multi-stage time interval coefficient configuration is predefined, where the first poll uses a larger coefficient value, and subsequent polls use progressively smaller coefficient values. The polling strategy manager maintains a polling count counter, looks up the corresponding coefficient based on the current polling count, and calculates the specific time interval for that polling using a multiplier. For instance, with a base time interval of 120 seconds, the first polling interval is calculated as 120 seconds × 0.8 = 96 seconds; the second polling interval is 120 seconds × 0.2 = 24 seconds; and the third and subsequent polling intervals are all 120 seconds × 0.1 = 12 seconds.
[0084] In this embodiment, by using a time interval coefficient decreasing strategy, unnecessary frequent queries are reduced in the early stages of task execution, and query density is increased when the task is about to be completed, thus achieving the best balance between query efficiency and resource consumption.
[0085] For example, after the front-end device obtains the business processing task and its corresponding estimated execution time, it can begin polling the asynchronous task. The front-end device does not use traditional timed polling; instead, it dynamically adjusts the time interval for each poll based on the estimated task execution time. Specifically, the estimated task execution time is set as the time interval base. The polling time for each poll is obtained by multiplying the time interval base by the time interval coefficient. Dynamic adjustment of the time interval coefficient achieves dynamic adjustment of the time interval. For example, if the estimated task execution time is t0 and the time interval base is t0, then the time interval for the nth polling is: tn = time interval coefficient * time interval base.
[0086] For example, for the first poll (i.e. the initial poll), the server can determine the estimated execution time of the task as the time interval base and set it as the initial polling time. Subsequent polling times are obtained by multiplying the time interval base and the time interval coefficient.
[0087] In some embodiments of this application, the first time interval coefficient corresponding to the first polling is 0.8, the second time interval coefficient corresponding to the second polling is 0.2, and the time interval coefficient corresponding to the third polling and each subsequent polling is 0.1.
[0088] For example, the time interval settings for polling the asynchronous task execution status are shown in Table 1: Table 1
[0089] In this embodiment, the initial time interval is set to be relatively long to avoid frequent requests in the early stages of task execution; subsequent polling increases the polling frequency by adjusting the time interval coefficient, thereby reducing query latency after task execution is completed.
[0090] In some embodiments of this application, the front-end device sends a task status query request to the server at the corresponding time point based on the calculated polling time interval.
[0091] For example, the front-end device starts a timer to schedule the execution of query tasks according to the calculated polling interval.
[0092] For example, 96 seconds after the task starts, the timer triggers the first status query request; 24 seconds after the first query, the second query request is triggered; thereafter, a query is triggered every 12 seconds until the task is completed.
[0093] In this embodiment, the first front-end device dynamically determines the initiation time interval for each polling based on the time interval base and the preset time interval coefficient, and sends a task status query request to the server at the time of each polling initiation. In this way, the strict execution of the polling strategy is ensured through precise timing control, avoiding queries that are too early or too late, and optimizing the utilization of network resources.
[0094] In some embodiments of this application, the task processing method provided in this application may further include the following step 207: Step 207: When the number of polling requests sent by the first front-end device to the server for task status query exceeds the polling number threshold, the time interval coefficient for subsequent polling is increased.
[0095] For example, step 207 can be performed after step 206 or as a sub-step of step 206. This application embodiment does not limit this.
[0096] In some embodiments of this application, when the number of task status query requests sent by the front-end device exceeds a preset polling number threshold, the system automatically increases the time interval coefficient of subsequent polling to cope with situations where the task execution time exceeds expectations.
[0097] For example, a configurable polling count threshold is set. When the actual number of polls exceeds this threshold, the polling strategy manager initiates a coefficient adjustment procedure, increasing the time interval coefficient according to preset adjustment rules. The adjusted coefficient is applied to all subsequent polls until the task is completed. For instance, if the polling count threshold is set to 20 times, after the front-end device completes the 20th query, the time interval coefficient is adjusted from 0.1 to 0.15, extending the subsequent polling interval from 12 seconds to 18 seconds.
[0098] In this embodiment, the front-end device can dynamically adjust the time interval coefficient based on the number of times the task status query request has been sent. This prevents excessive polling caused by abnormally long tasks, protects system resources from being exhausted, and thus improves processing performance.
[0099] In some embodiments of this application, in conjunction with the above... Figure 1 ,like Figure 2 As shown, after step 206 above, the task processing method provided in this application embodiment may further include the following steps 208 and 209: Step 208: A front-end device receives the task status information returned by the server.
[0100] Step 209: If the task status information returned by the server indicates that the task status of the business processing task corresponding to a front-end device is completed, then the front-end device stops sending task status query requests to the server and executes the business operation corresponding to the business processing task.
[0101] In some embodiments of this application, after receiving the task status information returned by the server, the front-end device first parses the status content. When the status information clearly indicates that the corresponding business processing task has been completed, the front-end device immediately terminates the polling process and executes subsequent business operations related to the task.
[0102] For example, the front-end device analyzes the status information returned by the server through a status resolver to identify the task completion status flag. Once a completion status is detected, the polling controller immediately clears all pending polling timers and triggers the business result processing flow, including result display, data updates, and other operations. For instance, if the front-end device receives the task completion status during the fifth poll, it immediately stops subsequent polling, redirects to the task result display interface, and updates the local business data status.
[0103] In this embodiment, timely task completion identification and polling termination avoid unnecessary subsequent queries, saving network bandwidth and server resources, while providing a smooth user experience.
[0104] In some embodiments of this application, in conjunction with the above... Figure 1 ,like Figure 3 As shown, after step 206 above, the task processing method provided in this application embodiment may further include the following steps 210 and 211: Step 210: A front-end device receives the task status information returned by the server.
[0105] Step 211: If the task status information returned by the server indicates that the task status of the business processing task corresponding to a front-end device is incomplete, then the front-end device continues to determine the next polling interval according to the dynamic polling strategy and sends a task status query request to the server according to the time interval.
[0106] In some embodiments of this application, when the status information returned by the server indicates that the task has not been completed, the front-end device maintains a polling state, calculates the time interval for the next polling according to the dynamic polling strategy, and initiates a query request again when the time interval arrives.
[0107] For example, after receiving an incomplete status from the polling controller, the front-end device increments the polling count counter, recalculates the time interval for the next polling, and resets the polling timer. This process is repeated until the task is completed or the maximum polling limit is reached. For instance, if the front-end device receives a status indicating that the task is in progress during the third poll, calculates based on the dynamic polling strategy that the next query should be executed in 12 seconds, sets the timer accordingly, and initiates the fourth query request at the specified time.
[0108] In this embodiment of the application, continuous polling ensures the real-time acquisition of task status, providing users with accurate feedback on task execution progress.
[0109] In some embodiments of this application, in conjunction with the above... Figure 1 ,like Figure 4 As shown, after step 204 above, the task processing method provided in this application embodiment may further include the following steps 212 to 214: Step 212: After receiving the estimated execution time of the business processing task corresponding to a front-end device from the server, a front-end device starts the first timer.
[0110] The first timer mentioned above is used to record the waiting time consumed since the start of polling to execute a business processing task corresponding to a front-end device.
[0111] Step 213: A front-end device calculates the task progress information of the corresponding business processing task based on the estimated task execution time and the elapsed waiting time recorded by the timer.
[0112] Step 214: A front-end device displays a progress feedback component on the front-end interface based on the task progress information. The progress feedback component includes the estimated remaining execution time of the corresponding business processing task and a graphical progress bar.
[0113] In some embodiments of this application, after receiving the estimated task execution time, the front-end device starts a high-precision timer to record the waiting time consumed by the task since the start of polling.
[0114] In some embodiments of this application, the front-end device calculates the progress information of the task based on the estimated task execution time and the elapsed waiting time recorded by the timer, and displays it in the front-end interface in the form of a graphical progress bar and the estimated remaining time.
[0115] For example, the progress feedback system includes a timing management module, a progress calculation module, and an interface rendering module. The timing management module provides accurate time measurement functionality; the progress calculation module calculates the progress percentage and remaining time based on the ratio of elapsed time to the estimated total time; and the interface rendering module converts the calculation results into a visual progress feedback component. For instance, for a task with an estimated execution time of 120 seconds, after 60 seconds of initiation, the progress is calculated to be 50%, with an estimated remaining time of 60 seconds. The front-end interface then updates the progress bar's fill status and the remaining time display accordingly.
[0116] For example, while executing the polling strategy, the front-end device provides a task feedback mechanism to the user. In the form of a task pop-up, based on the predicted execution time and the results of the polling query, the remaining execution time and progress of the task are displayed to the user on the front-end interface. Figure 5A As shown, during the execution of business processing task A, a task pop-up window 52 (i.e., progress feedback component) is displayed on the front-end interface 51. The task pop-up window 52 includes the task number of business processing task A, the task status of business processing task A (i.e., in execution), and displays the estimated remaining execution time of business processing task A as "2 minutes and 13 seconds" and a graphical progress bar. The right side of the graphical progress bar displays the execution progress as "27%".
[0117] In combination with the above Figure 5A ,like Figure 5B As shown, after the execution of business processing task A is completed, the task pop-up window 52 includes the task status of business processing task A being updated to "completed", the display status of the graphical progress bar being updated, the execution progress displayed on the right side of the graphical progress bar changing to "100%", and the estimated remaining execution time below the graphical progress bar being updated to the cumulative execution time "3 minutes and 5 seconds".
[0118] It should be noted that the estimated remaining execution time and execution progress in the task pop-up are simulated data and not the actual feedback of the asynchronous task. The information displayed by the feedback component is adjusted by using the predicted response time of the task and polling the specific return results of the asynchronous task to make the information displayed by the feedback component match the actual execution status of the asynchronous task.
[0119] The execution flow of steps 212 to 214 is illustrated below. For example, as shown... Figure 6 As shown, the execution process includes the following steps: Step 61: Obtain the estimated task execution time T.
[0120] Step 62: Initialize the progress feedback component.
[0121] For example, after initialization, the estimated remaining execution time is T, and the asynchronous task execution progress is 0%.
[0122] For example, component initialization involves setting a timer to record the elapsed time t during component initialization, and controlling the progress display based on the estimated task execution time and the timer duration.
[0123] Step 63: Dynamically display the task progress.
[0124] For example, the estimated remaining execution time is Tt, the asynchronous task execution progress is t / T, and the upper limit of the task progress is controlled.
[0125] For example, the task progress limit is set to 95%, the task execution time limit is set to 95%*T, and when t>95%*T, the task progress and remaining time are paused for updating until the task execution is found to be complete.
[0126] Step 64: Poll the status of asynchronous tasks.
[0127] For example, determine whether the task has been completed. If yes, proceed to step 65; otherwise, continue with step 63.
[0128] Step 65: Show that the task has been completed.
[0129] For example, at this point, the remaining execution time is expected to be 0, and the asynchronous task execution progress is 100%.
[0130] For example, when the task execution is completed, the progress feedback component is set to the final state, that is, the expected remaining execution time is 0 and the asynchronous task execution progress is 100%.
[0131] This allows users to have a general idea of the remaining time for task execution, and by using a simulated progress bar to display the expected progress of the task in real time, it provides progress feedback to users, enhancing the interactivity of the system and the smoothness of the user experience.
[0132] In this embodiment of the application, the front-end device can display the task progress information of the first business processing task on the task status interface according to the task status information returned by the server, so that the user can have an intuitive perception of the task execution status and enhance the human-computer interaction performance.
[0133] In some embodiments of this application, the task status information includes the actual execution time of the corresponding business processing task; for example, after step 214, the task processing method provided in this application embodiment may further include the following step 215: Step 215: After receiving the task status information of the business processing task corresponding to a front-end device from the server, a front-end device recalculates the task progress information of the business processing task corresponding to the front-end device based on the actual execution time of the corresponding business processing task in the task status information, and updates the progress feedback component based on the task progress information.
[0134] In some embodiments of this application, after receiving the task status information returned by the server, the front-end device extracts the actual execution time data contained therein, recalculates the task progress information based on this real data, and updates the display content of the progress feedback component accordingly.
[0135] For example, the front-end device compares the estimated execution time with the actual execution time and adjusts the progress calculation algorithm according to the degree of difference. In cases of large deviations, the actual execution time is used as a new benchmark for progress recalculation to ensure the accuracy of progress display.
[0136] For example, when the actual execution time of a task is significantly longer than the estimated time, the front-end device recalculates the remaining time based on the actual execution progress and adjusts the progress bar's speed to better reflect the actual execution status of the task.
[0137] In this embodiment, the front-end device can recalculate and update the task progress information of the business processing task based on the actual execution time of the business processing task returned by the server. In this way, progress calibration based on real data improves the accuracy of progress feedback.
[0138] In some embodiments of this application, the task processing method provided in this application may further include steps 216 to 218: Step 216: After the server completes a business processing task, it obtains the task data of the business processing task. The task data includes the business type, business parameters, business data scale, and actual task execution time of the business processing task. Step 217: The server processes the task data and adds it to the training set of the task execution time prediction model; Step 218: When the amount of data in the training set reaches a preset threshold, the server uses the updated training set to retrain the task execution time prediction model.
[0139] In some embodiments of this application, after completing a business processing task, the server collects complete execution data for that task, including the business type, business parameters, business data scale, and actual task execution time. This data is then standardized and added to the training dataset of the task execution time prediction model. When the amount of data in the training dataset reaches a preset threshold, the server retrains the prediction model using the updated training set to optimize the model parameters.
[0140] For example, the server extracts key features and actual execution times from completed tasks, and cleans, normalizes, and performs feature engineering on the collected data. When a data volume threshold is reached, an incremental learning process is initiated to update the model parameters. For instance, execution data for all completed tasks is collected daily. When 1000 new data entries are accumulated, the model retraining process is automatically triggered, using the enhanced training set to optimize the task execution time prediction model and improve the prediction accuracy for subsequent tasks.
[0141] The following is an exemplary description of the process for retraining the task execution time prediction model provided in the embodiments of this application, such as... Figure 7 As shown, the retraining process may include the following steps: Step 41: Data collection.
[0142] Step 42: Data preprocessing.
[0143] Step 43: Model loading.
[0144] Step 44: Model retraining.
[0145] Step 45: Save the model.
[0146] In combination with the above Figure 7 After the asynchronous task in the business system is completed, the requested data needs to be cached. The task execution time is recorded after the asynchronous task is finished, and the two are assembled to form the original dataset. The business system periodically pushes the cached dataset to the task execution time prediction model service. After collecting data, the task execution time prediction model processes and filters out irrelevant data. Based on the dataset, the task execution time prediction model forms a new training set. When the training set data reaches a certain size, the task execution time prediction model system reads and loads the model file from the hard drive, uses the dataset to retrain the linear regression model, and saves the trained task execution time prediction model to the model file. This process is repeated continuously to retrain the model.
[0147] It should be noted that the purpose of retraining the model is to reduce the bias of the prediction results and reduce the offset of the linear regression task execution time prediction model. Retraining can also be understood as relearning.
[0148] In this embodiment, the server can use the task information of the executed business processing tasks to incrementally learn the model. Without rebuilding the model, new data is continuously added to enhance the model, so that the task execution time prediction model is continuously adjusted and optimized, making its prediction results more and more accurate. Continuous model optimization makes the prediction accuracy improve over time, so that the model has self-learning ability, can adapt to changes in business models, and maintain long-term effectiveness and reliability.
[0149] In some embodiments of this application, the task execution time estimation model is trained based on historical task data; the aforementioned historical task data includes the business type, business parameters, and business data scale of at least one historical business processing task. Exemplarily, the task processing method provided in the embodiments of this application may further include the following steps A1 and A2: Step A1: The server obtains at least one training sample. Each training sample includes task data and actual task execution time for a business processing task. The task data includes: business type, business parameters, business data scale, and corresponding system load.
[0150] Step A2: The server trains the above linear regression model based on at least one training sample to establish a mapping relationship between task data and task execution time, thereby obtaining the above task execution time prediction model.
[0151] It should be noted that for asynchronous tasks involving large amounts of data and high complexity in the field of digital housing, the execution time is mainly affected by factors such as business type, data scale, and business system load. These factors have a certain linear relationship with the task execution time. Therefore, this application chooses linear regression to construct the prediction model.
[0152] In some embodiments of this application, the parameters of the model are selected as follows: Independent variables: business type, data scale, business system load; Dependent variable: i.e., the prediction target, the execution time of the asynchronous task.
[0153] In some embodiments of this application, the data collection process for the task execution time estimation model is as follows: A data collection function is added to the asynchronous task service. When an asynchronous task creation request is received, information such as the business type, business parameters, and current business system load corresponding to the asynchronous task is recorded, and the asynchronous task execution time is recorded when the asynchronous task is completed. Each time an asynchronous task generation request is received from a business processing service, the asynchronous task service collects the above information and stores it in the database after the task execution is completed. When the number of asynchronous tasks reaches a certain scale, SQL statements can be written to perform several searches and filters from the database to select the dataset containing the above information.
[0154] In some embodiments of this application, the data collection and processing process for model training is as follows: After acquiring the dataset, data processing is required. Data processing for asynchronous tasks in the digital housing field mainly involves two aspects: invalid data filtering and data size reduction. First, invalid data is filtered out, removing the following types of data: data with abnormal task execution status (e.g., data from failed executions), data with excessively short task execution times, and data with insufficient business parameter data, to avoid interference with the model. After data filtering, data size reduction is performed, such as removing irrelevant fields other than independent and dependent variables, and extracting the original business data into data size and data type categories to avoid irrelevant fields occupying unnecessary space. The processed data is divided into a training set and a test set.
[0155] In some embodiments of this application, the model training process is as follows: the dataset is input into the linear regression model for model training. After training, the prediction results corresponding to the independent variables of the test set are calculated and compared with the dependent variable (actual execution time of the task) of the data in the test set. If the error of the prediction model is large, the data is collected again and the model is trained again.
[0156] The task processing method provided in this application, based on existing polling strategies, and taking into account the characteristics of asynchronous tasks in a real estate system, constructs a linear regression prediction model based on parameters such as transaction type, data scale, and system load to predict response time. When the business system processes asynchronous tasks initiated by the front end, it returns the task number and predicted response time. The front end dynamically polls based on the predicted response time to optimize the query of asynchronous tasks. Compared with traditional fixed polling strategies and long-connection strategies, this method has the following advantages: 1. Dynamically set polling interval. Based on the prediction results of the linear regression model, the polling interval can be set more reasonably, reducing frequent requests and lowering latency; 2. Reduce network overhead and system resource consumption. The system can achieve low latency by avoiding frequent short connections and establishing long connections that consume network resources for extended periods. 3. Establish a feedback mechanism based on the estimated task execution time so that users can understand the task execution progress and the estimated completion time in a timely manner, thereby optimizing the user experience; 4. Supports dynamic optimization of business processes. After each processing step, the system can collect actual transaction information, process the data, and add it to the training set to continuously optimize the model.
[0157] Figure 8 This is a schematic diagram of a task processing system provided in an embodiment of this application. The task processing method provided in this embodiment can be applied to this task processing system. Figure 8As shown, the task processing system mainly consists of three parts: a front-end system (or front-end application, front-end project, front-end) 5001, a business system 5002, and a model module 5003 (i.e., a task execution time prediction model module or prediction model). The front-end system 5001 is responsible for initiating business requests, performing dynamic polling, and providing execution progress feedback to track task execution status. The business system 5002 includes a business processing service, an asynchronous task service, and an asynchronous task query service. The business processing service handles front-end requests, the asynchronous task service creates and manages asynchronous tasks, and the asynchronous task query service is used to query task status. The model module 5003 includes a model processing service (i.e., a processing service or prediction service), a data acquisition module, and an incremental learning module. The model prediction service is responsible for predicting asynchronous task execution time, data acquisition, and incremental learning.
[0158] The following is in conjunction with the above Figure 8 The system shown illustrates the execution flow of the task processing method provided in this application embodiment. Exemplarily, the execution flow of this task processing method may include the following steps: Step 11: When a user performs relevant business operations on the front-end device, the front-end device sends an HTTP request to the business system. The request body contains the business type, business parameters, etc. Step 12: After receiving the request, the business system parses the business parameters and determines that asynchronous processing is required. The business processing service then sends the task parameter information to the asynchronous task service. Step 13: The asynchronous task service generates asynchronous tasks, puts them into the task queue for unified management, and then returns the task number and other information to the business processing service. Step 14: The business processing service sends business parameters and other information to the task execution time prediction model service; Step 15: The task execution time prediction model service loads the task execution time prediction model, calculates the predicted execution time based on business parameters, and returns it (to the business processing service). Step 16: The business processing service combines asynchronous task information such as task number with predicted information such as predicted task execution time, and sends this information to the front-end device's HTTP request. Step 17: After receiving the response, the front-end device constructs a dynamic polling strategy based on the predicted response time and polls the asynchronous task query service through task information such as asynchronous task number; at the same time, the front-end creates a pop-up component based on the predicted response time to display the remaining execution time of the task statement and dynamically present the execution progress. Step 18: The asynchronous task query service initiates a task status query to the asynchronous task service; Step 19: The asynchronous task service returns information such as the status and execution result of the corresponding task; Step 20: The asynchronous task query service returns the task execution information to the front-end device. The front-end device judges the task execution result. If the task status is "execution completed", the front-end device stops polling and performs subsequent business operations. If the task status is "not yet executed" or "in execution", then step 17 is executed again until the task status is "execution completed".
[0159] Step 21: After each polling cycle, the query results are passed to the progress control component. The progress control component adjusts the remaining time and execution progress based on the task execution status. If the task status is "execution completed," the feedback component status is updated to "completion progress 100%." If the task status is "not yet executed" or "in execution," the remaining execution time and execution progress are updated, and the feedback component needs to be controlled to display the task as "task incomplete" until the task status is "execution completed."
[0160] The following is in conjunction with the above Figure 8 The system shown illustrates the execution timing of the task processing method provided in this application embodiment. For example... Figure 9 As shown, the timing flow of this task processing method includes the following steps: Step 31: Initiate a business request.
[0161] For example, the front-end system initiates a business request to the business processing service of the business system.
[0162] Step 32: Initiate a request to predict execution time.
[0163] Step 33: Initiate an asynchronous task request.
[0164] Step 34: Generate asynchronous tasks.
[0165] For example, after receiving a request, the business processing service performs the following two operations: it sends a request to the task execution time estimation model service to obtain the estimated execution time of the task; and it sends a request to the asynchronous task service to create an asynchronous task and store it in the execution queue.
[0166] Step 35: Return asynchronous task information.
[0167] For example, the asynchronous task service returns asynchronous task information to the business processing service.
[0168] Step 36: Return the predicted execution time.
[0169] For example, the task execution time estimation model service returns the calculated estimated execution time to the business processing service.
[0170] Step 37: Return to integrated information.
[0171] For example, the business processing service integrates the received estimated execution time with the asynchronous task information and then returns them together to the front-end system.
[0172] For example, after receiving the integration information, the front-end system initiates a dynamic polling process: Step 38: Check the task status.
[0173] For example, the front-end system calculates the polling interval based on the estimated execution time, and sends a task status query request to the asynchronous task query service when the interval is reached.
[0174] Step 39: Check the task status.
[0175] For example, the asynchronous task query service queries the asynchronous task service for the latest task status.
[0176] Step 40: Return to task status.
[0177] For example, the asynchronous task service returns the current task status to the asynchronous task query service.
[0178] Step 41: Return to task status.
[0179] For example, the asynchronous task query service returns the task status to the front-end system.
[0180] For example, the front-end system determines the returned task status.
[0181] For example, if the task is not completed, the process jumps back to step 38, and the front-end system waits for the next dynamically calculated polling interval before initiating the query again. If the task has been completed, the front-end system stops polling and performs subsequent operations based on the task execution result, and the process ends.
[0182] It should be noted that the collection, acquisition, storage, use, processing, transmission, provision, and disclosure of user personal information / data involved in the technical solution disclosed in this application all comply with the relevant provisions of national laws and regulations and do not violate public order and good morals. It should be noted that the task execution time estimation model in this application embodiment is not for a specific user and cannot reflect the personal information of a specific user.
[0183] It should be noted that the personal information used in the technical solution of this application is limited to information for which individual consent has been obtained, including but not limited to notifying and reminding users to read the relevant user agreement (notification) and sign the agreement (authorization) which includes the authorization of relevant user information before users use the function.
[0184] Figure 10 This is a schematic diagram of a task processing device provided in an embodiment of this application. Figure 10 As shown, the task processing device 600 includes: a receiving module 601, a storage module 602, a processing module 603, and a sending module 604. The receiving module 601 receives N service processing requests sent by N front-end devices, each request containing the service type, service parameters, and service data scale of a service processing task. The storage module 602 stores the N service processing tasks corresponding to the N service processing requests as asynchronous tasks sequentially into a task execution queue for later execution. The processing module 603 processes the service type, service parameters, and service data scale of the N service processing tasks using a task execution time prediction model to obtain the task execution time of each service processing task. The system includes a task status query module 604, which is configured to return the estimated execution time of the corresponding business processing task to each front-end device; a processing module 603, which is configured to construct a dynamic polling strategy for the corresponding business processing task based on the received estimated execution time, and send task status query requests to the server in a polling manner according to the dynamic polling strategy; the task status query request is used to query the execution status of the corresponding business processing task, and the task status query request includes the task index information of the corresponding business processing task; and the sending module 604, which is configured to send the task status information of the business processing task corresponding to each front-end device to each front-end device when a task status query request is received from each front-end device.
[0185] In some embodiments of this application, the above-mentioned processing module is specifically used to determine the estimated task execution time as the time interval base; determine the initiation time interval for each polling based on the time interval base and a preset time interval coefficient; wherein the initiation time interval for the nth polling is obtained by multiplying the time interval base by the time interval coefficient corresponding to the nth polling, where n is a positive integer; and send a task status query request to the server at the corresponding time point according to the determined initiation time interval for each polling.
[0186] In some embodiments of this application, the preset time interval coefficient satisfies the following: the time interval coefficient corresponding to the first poll is greater than the time interval coefficient corresponding to the second poll and each subsequent poll.
[0187] In some embodiments of this application, the first time interval coefficient corresponding to the first polling is 0.8, the second time interval coefficient corresponding to the second polling is 0.2, and the time interval coefficient corresponding to the third polling and each subsequent polling is 0.1. The above-mentioned processing module is also used to increase the time interval coefficient of subsequent polling when the number of polling requests sent to the server for task status query exceeds the polling number threshold.
[0188] In some embodiments of this application, the receiving module is further configured to receive task status information returned by the server; if the task status information returned by the server indicates that the task status of a business processing task corresponding to a front-end device is completed, then the module stops sending task status query requests to the server and executes the business operation corresponding to the business processing task; or, if the task status information returned by the server indicates that the task status of a business processing task corresponding to a front-end device is incomplete, then the module continues to determine the time interval for the next polling according to the dynamic polling strategy and sends task status query requests to the server according to the time interval.
[0189] In some embodiments of this application, the above-mentioned processing module is further configured to, after receiving the estimated execution time of a business processing task corresponding to a front-end device returned by the server, start a first timer, the first timer being used to record the waiting time consumed since the start of polling for executing a business processing task corresponding to a front-end device; calculate the task progress information of the corresponding business processing task based on the estimated execution time and the waiting time recorded by the timer; and display a progress feedback component on the front-end interface based on the task progress information, the progress feedback component including the estimated remaining execution time of the corresponding business processing task and a graphical progress bar.
[0190] In some embodiments of this application, the task status information includes the actual execution time of the corresponding business processing task; the processing module is further configured to, after displaying the progress feedback component on the front-end interface, after receiving the task status information of the business processing task corresponding to a front-end device returned by the server, recalculate the task progress information of the business processing task corresponding to the front-end device based on the actual execution time of the corresponding business processing task in the task status information, and update the progress feedback component based on the task progress information.
[0191] In some embodiments of this application, the processing module is further configured to, after completing a business processing task, obtain task data of a business processing task, the task data including the business type, business parameters, business data scale and actual task execution time of a business processing task; add the task data to the training set of the task execution time prediction model after data processing; and retrain the task execution time prediction model using the updated training set when the amount of data in the training set reaches a preset threshold.
[0192] The task processing device provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.
[0193] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 11 As shown, the electronic device 500 includes: a memory 501, a transceiver 502, and at least one processor 503.
[0194] The transceiver 502 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 502 can specifically be used to receive N service processing requests sent by N front-end devices. The memory 501 is used to store computer program code, which includes computer instructions. These computer instructions run in the aforementioned electronic device to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, portable hard drive, read-only memory, magnetic disk, or optical disk, etc.
[0195] Processor 503 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 503 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.
[0196] The memory 501, transceiver 502, and processor 503 are communicatively connected. For example, the memory 501 and transceiver 502 can be connected to the processor 503 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.
[0197] Optionally, the memory 501 can be either standalone or integrated with the processor 503. When the memory 501 is set up independently, it is connected to the processor 503 via a system bus.
[0198] This application also provides a chip for executing instructions, which is used to execute the technical solution of the task processing method in the above embodiments.
[0199] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the task processing method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the electronic device can perform the technical solution of the task processing method described in the above embodiments.
[0200] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the task processing method in the above embodiments. The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer. An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.
[0201] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.
[0202] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.
[0203] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.
[0204] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.
[0205] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.
[0206] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0207] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A task processing method characterized by, The method comprises the following steps: A server receives N service processing requests sent by N front-end devices, each service processing request containing a service type, service parameters and a service data size of a service processing task, N being an integer greater than 1; The server stores the N service processing tasks corresponding to the N service processing requests as asynchronous tasks in a task execution queue in sequence and then executes the tasks; The server processes the service type, service parameters and service data size of each service processing task by using a task execution time estimation model to obtain a task execution estimation time of each service processing task; The server returns the task execution estimation time of the corresponding service processing task to each front-end device respectively; Each front-end device constructs a dynamic polling strategy for the corresponding service processing task based on the received task execution estimation time and sends a task state query request to the server according to the dynamic polling strategy; the task state query request is used to query the execution state of the corresponding service processing task, and the task state query request contains task index information of the corresponding service processing task; The server sends task state information of the service processing task corresponding to the front-end device to the front-end device when the server receives a task state query request from the front-end device.
2. The method of claim 1, wherein, Each front-end device constructs a dynamic polling strategy for the corresponding service processing task based on the received task execution estimation time, which comprises the following steps: A first front-end device determines the task execution estimation time as a time interval base, the first front-end device being one of the N front-end devices; The first front-end device determines an initiation time interval of each polling based on the time interval base and a preset time interval coefficient; wherein the initiation time interval of the nth polling is obtained by multiplying the time interval base by the time interval coefficient corresponding to the nth polling, n being a positive integer; Each front-end device sends a task state query request to the server according to the dynamic polling strategy, which comprises the following steps: The first front-end device sends the task state query request to the server at the corresponding time point according to the determined initiation time interval of each polling.
3. The method of claim 2, wherein, The preset time interval coefficient satisfies: the time interval coefficient corresponding to the first polling is greater than the time interval coefficients corresponding to the second and subsequent pollings.
4. The method of claim 3, wherein, The first time interval coefficient corresponding to the first polling is 0.8, the second time interval coefficient corresponding to the second polling is 0.2, and the time interval coefficients corresponding to the third and subsequent pollings are all 0.1; The method further comprises the following steps: The first front-end device increases the time interval coefficient of each subsequent polling when the number of polling times of the first front-end device sending the task state query request to the server exceeds a polling frequency threshold.
5. The method of claim 1, wherein, The method further comprises the following steps: The front-end device receives the task state information returned by the server; If the task state information returned by the server represents that the task state of the service processing task corresponding to the one front-end device is completed, the one front-end device stops sending the task state query request to the server and performs the corresponding business operation corresponding to the service processing task. If the task state information returned by the server represents that the task state of the service processing task corresponding to the one front-end device is not completed, the one front-end device continues to determine the time interval of the next polling according to the dynamic polling strategy and sends the task state query request to the server according to the time interval.
6. The method of claim 1, wherein, The method further comprises: After receiving the task execution estimated time of the service processing task corresponding to the one front-end device returned by the server, the one front-end device starts a first timer, and the first timer is used to record the consumed waiting time of executing the service processing task corresponding to the one front-end device since the start of polling. The one front-end device calculates the task progress information of the corresponding service processing task based on the task execution estimated time and the consumed waiting time recorded by the timer. The one front-end device displays a progress feedback component on the front-end interface based on the task progress information, and the progress feedback component includes the predicted remaining execution time and the graphical progress bar of the corresponding service processing task.
7. The method of claim 6, wherein, The task state information includes the actual execution time of the corresponding service processing task. After the one front-end device displays the progress feedback component on the front-end interface, the method further comprises: After receiving the task state information of the service processing task corresponding to the one front-end device returned by the server, the one front-end device recalculates the task progress information of the service processing task corresponding to the one front-end device based on the actual execution time of the corresponding service processing task in the task state information, and updates the progress feedback component based on the task progress information.
8. The method of claim 1, wherein, The method further comprises: After completing the execution of one service processing task, the server obtains the task data of the one service processing task, and the task data includes the business type, business parameter, business data size, and actual task execution duration of the one service processing task. The server adds the task data after data processing to the training set of the task execution time estimation model. When the data amount of the training set reaches a preset threshold, the server re-trains the task execution time estimation model using the updated training set.
9. A task processing apparatus characterized by comprising: Comprise: A receiving module, a storage module, a processing module, and a sending module, wherein: The receiving module is configured to receive N service processing requests sent by N front-end devices, and each service processing request includes the business type, business parameter, and business data size of one service processing task. The storage module is configured to store the N service processing tasks corresponding to the N service processing requests as asynchronous tasks in a task execution queue in sequence and then execute the asynchronous tasks. The processing module is configured to: The sending module is configured to send the task state query request to the server according to the time interval. The processing module is configured to process the service type, the service parameter, and the service data scale of the N service processing tasks respectively by using a task execution time estimation model to obtain the estimated task execution time of each service processing task. The sending module is configured to return the estimated task execution time of the corresponding service processing task to each front-end device respectively. The processing module is further configured to construct a dynamic polling strategy for the corresponding service processing task based on the received estimated task execution time, and send a task state query request to the server according to the dynamic polling strategy; the task state query request is used to query the execution state of the corresponding service processing task, and the task state query request includes the task index information of the corresponding service processing task. The sending module is further configured to send the task state information of the service processing task corresponding to the front-end device to the front-end device in a case where one task state query request is fed back by the front-end device.
10. An electronic device, comprising: The electronic device comprises: a memory and at least one processor; the memory is in communication connection with the processor; the memory is configured to store computer program code, and the computer program code comprises computer instructions; when the processor executes the computer instructions, the electronic device performs the task processing method according to any one of claims 1 to 8.
11. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions are executed by the processor to implement the task processing method according to any one of claims 1 to 8.
12. A computer program product, characterised in that, When the computer program product is running on the computer / is executed by the processor of the computer, the task processing method according to any one of claims 1 to 8 is implemented.