A task processing method and device, computer equipment and a readable storage medium
By splitting write tasks and verifying state transitions, the task processing problem in complex write chain scenarios is solved, improving the processing efficiency and robustness of write tasks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHUXING TECH (BEIJING) CO LTD
- Filing Date
- 2026-03-10
- Publication Date
- 2026-05-29
AI Technical Summary
In internet platforms, as the complexity of write chains increases, how to effectively handle complex write tasks has become an urgent problem to be solved, especially in write chain scenarios with multi-domain interactions, and how to improve the processing effect of write tasks.
By breaking down the write task into subtasks, determining whether each subtask is synchronous or asynchronous, and verifying the state transition results before and after subtask execution based on the task state transition relationship, the data is finally stored in the database, ensuring that the task execution process is logically clear and the responsibilities between different areas are well-defined.
It improves the processing efficiency of writing tasks, enhances the robustness of writing task execution, and ensures clear logic and efficient collaboration in task processing.
Smart Images
Figure CN122111618A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of task processing technology, and in particular to a task processing method, apparatus, computer device, and readable storage medium. Background Technology
[0002] In internet platforms, the write pipeline refers to the entire processing flow from when a client initiates a write task to when the data is finally stored in the database, such as content publishing. Typically, the write pipeline involves the collaboration of multiple system components, service layers, middleware, and persistence layers, which means it involves multi-domain interactions within the publishing pipeline.
[0003] With the development of Internet technology, write chains are becoming increasingly complex and involve more and more different write chain scenarios. Therefore, how to provide a task processing method to realize the task processing of write tasks in complex write chain scenarios and improve the task processing effect of write tasks has become an urgent technical problem to be solved. Summary of the Invention
[0004] Therefore, it is necessary to provide a task processing method, apparatus, computer device, and readable storage medium to address the above-mentioned technical problems, which can realize the task processing of write tasks in complex write link scenarios and improve the task processing effect of write tasks.
[0005] Firstly, this application provides a task processing method, including:
[0006] The write task to be processed is split into at least two sub-tasks.
[0007] Based on the dependencies between different subtasks, determine the task type of each subtask; the task type includes synchronous or asynchronous types.
[0008] For each subtask, execute the subtask and, based on the task state transition relationship and the task type of the subtask, verify the task state transition results before and after the subtask execution; and,
[0009] Based on the verification results, the execution results of the subtasks are written to the database.
[0010] Among them, the task status transition relationship includes the transition relationship between different task states of each task type within the task cycle.
[0011] In one embodiment, the task state transition result before and after the execution of a subtask is verified based on the task state transition relationship and the task type of the subtask. This includes: obtaining the target state after the execution of the subtask based on the task type of the subtask; determining the task state transition result before and after the execution of the subtask based on the starting state before the execution of the subtask and the target state after the execution of the subtask; querying the task state transition relationship based on the task state transition result and the task type of the subtask to obtain the target transition identifier corresponding to the task state transition result; wherein, each transition relationship in the task state transition relationship corresponds to a transition identifier, and the transition identifier is used to identify whether the transition relationship is allowed; and determining the verification result of the task state transition result based on the target transition identifier.
[0012] In one embodiment, the target state after the execution of a subtask is obtained according to its task type, including: if the task type of the subtask is synchronous, obtaining the target state after the execution of the subtask based on the execution result of the subtask after the subtask is completed; if the task type of the subtask is asynchronous, responding to a callback signal generated by an asynchronous thread pool or asynchronous task queue, calling back the execution result of the subtask, and obtaining the target state after the execution of the subtask based on the execution result of the subtask.
[0013] In one embodiment, when the task type of the subtask is asynchronous, executing the subtask includes: sending the subtask to an asynchronous thread pool or an asynchronous task queue so that the asynchronous thread pool or the asynchronous task queue executes the subtask.
[0014] After sending the subtask to the asynchronous thread pool or asynchronous task queue, the task processing method also includes updating the task state of the subtask from the actual initial state to the starting state.
[0015] In one embodiment, the task processing method further includes: updating the task status of the subtask to a timeout waiting state when a callback timeout is detected, and obtaining the task information of the subtask; determining the timeout processing action corresponding to the callback timeout reason represented by the task information of the subtask; and retrying the execution result of the subtask according to the timeout processing action.
[0016] In one embodiment, the execution result of the subtask is retried based on the timeout handling action, including: increasing the number of task retries and updating the next callback timeout when the timeout handling action is an execution action; updating the timeout waiting state to the first transition state; and returning to the operation of sending the subtask to the asynchronous thread pool or asynchronous task queue according to the timeout handling action, until the target state is obtained, or the increased number of task retries reaches the preset retry threshold.
[0017] In one embodiment, the execution result of the subtask is retried based on the timeout handling action, including: if the timeout handling action is an asynchronous completion callback action, increasing the callback count and updating the next callback timeout time; updating the timeout waiting state to the second transition state, and returning the execution result of the execution callback subtask based on the timeout handling action, until the target state is obtained, or the increased callback count reaches a preset callback count threshold.
[0018] In one embodiment, the task processing method further includes: if the target state is not obtained, updating the task state of the subtask from the initial state to the retry waiting state, and re-executing the subtask.
[0019] In one embodiment, executing a subtask includes: initializing the actual initial state of the subtask; determining the default initial state corresponding to the subtask based on the task state transition relationship and the task type of the subtask; and executing the subtask if the default initial state includes the actual initial state.
[0020] In one embodiment, executing a subtask includes: acquiring an execution lock for the subtask; and, if the execution lock for the subtask is acquired, executing the subtask.
[0021] Secondly, this application also provides a task processing apparatus, comprising:
[0022] The splitting module is used to split the write task to be processed into at least two subtasks.
[0023] The first determining module is used to determine the task type of each subtask based on the dependencies between different subtasks; wherein the task type includes synchronous type or asynchronous type;
[0024] The verification module is used to execute each subtask and verify the task state transition results before and after the execution of the subtask based on the task state transition relationship and the task type of the subtask.
[0025] The data storage module is used to store the data execution results of subtasks in the database based on the verification results.
[0026] Among them, the task status transition relationship includes the transition relationship between different task states of each task type within the task cycle.
[0027] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the various method embodiments provided in the first aspect.
[0028] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the various method embodiments provided in the first aspect.
[0029] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the various method embodiments provided in the first aspect.
[0030] The aforementioned task processing method, apparatus, computer equipment, and readable storage medium are pre-defined with a task state transition relationship, including the transition relationship between different task states within a task cycle for each task type. Upon receiving a write task to be processed, the task is split into at least two subtasks. Based on the dependencies between different subtasks, the task type of each subtask is determined to be synchronous or asynchronous. Then, for each subtask, after execution, the task state transition result before and after execution is verified according to the aforementioned task state transition relationship and the task type of the subtask. Specifically, it verifies whether the transition from the task state before execution to the task state after execution is allowed. Based on the verification result, the task execution result of the subtask is written to disk. In this way, by defining the different task states of subtasks of different task types during the execution of the write task, as well as the above-mentioned task state transition relationships, the execution process of each subtask of the write task can be managed. This ensures that the logic of the task execution process is clear, the responsibilities of the various collaborative domains are clear, and thus improves the robustness of the write task execution. This enables the handling of write tasks in complex write chain scenarios and improves the task handling effect of the write task. Attached Figure Description
[0031] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 Application environment diagrams for the task processing methods provided in some embodiments of this application;
[0033] Figure 2 A flowchart illustrating a task processing method provided in some embodiments of this application;
[0034] Figure 3 A flowchart illustrating the status transition of a verification task provided in some embodiments of this application;
[0035] Figure 4 This application provides a flowchart illustrating the process of handling asynchronous task callback timeouts in some embodiments.
[0036] Figure 5 A flowchart illustrating the execution of subtasks provided in some embodiments of this application;
[0037] Figure 6 A flowchart illustrating the execution of subtasks provided for other embodiments of this application;
[0038] Figure 7 A flowchart illustrating a task processing method provided in other embodiments of this application;
[0039] Figure 8 Structural block diagrams of a task processing apparatus provided in some embodiments of this application;
[0040] Figure 9 This is an internal structural diagram of a computer device provided in some embodiments of this application. Detailed Implementation
[0041] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0042] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments or any combination of multiple embodiments.
[0043] In internet platforms, the write pipeline refers to the entire processing flow from when a client initiates a write task to when the data is finally stored in the database, such as content publishing. Typically, the write pipeline involves the collaboration of multiple system components, service layers, middleware, and persistence layers, which means it involves multi-domain interactions within the publishing pipeline.
[0044] With the development of Internet technology, write chains are becoming increasingly complex and involve more and more different write chain scenarios. Therefore, how to provide a task processing method to realize the task processing of write tasks in complex write chain scenarios and improve the task processing effect of write tasks has become an urgent technical problem to be solved.
[0045] In view of this, and to solve the above-mentioned technical problems, a task processing method is provided in an exemplary embodiment, which can be applied to a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.
[0046] In one exemplary embodiment, the task processing method provided in this application can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Terminal 102 initiates a write task to server 104, which then obtains the write task and reads the task status flow relationship from the data storage system to execute a task processing method provided in this embodiment. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc.
[0047] In one exemplary embodiment, such as Figure 2 As shown, a task processing method is provided, which is applied to Figure 1 Taking server 104 as an example, the following steps are included:
[0048] S201, split the write task to be processed into at least two sub-tasks.
[0049] As mentioned earlier, in an internet platform, the starting point of the write chain is when the client initiates a write task. The client can usually send various write tasks to the server, such as content publishing, order placement, status setting, etc. The server can then receive the write tasks sent by the client as pending tasks and enter the task processing flow.
[0050] Optionally, the write task initiated by the client is written to the server's write interface. Since the server can only process the write task after reading it, reading the write task can be considered a synchronous task that the server needs to execute. Therefore, when the server detects that the write interface has received a write task, it can call the synchronization thread to read the write task from the write interface and send the execution result back to the client. This execution result indicates whether the server has read the execution result of the write task.
[0051] Typically, a write task can include multiple subtasks. The process of handling a write task involves executing each subtask separately and storing the results of each subtask in the database. For example, if the write task is a content publishing task, and the published content includes text and video, this content publishing task includes a validation subtask (such as verifying whether the publishing user is logged in, whether the text exceeds the limit, and whether the video format is correct), a data writing subtask (such as recording basic information such as the publishing user identifier, publishing time, text content, and content status (such as pending review)), a video storage subtask (such as transferring the video to a distributed file system), a video transcoding subtask (such as transcoding the video into videos of different resolutions), a cover image extraction subtask, a content review subtask (such as text review and video frame review), a tag extraction subtask, a status update subtask (such as updating pending review to published), and a published data storage subtask (such as storing the published content data in a content candidate set for push to users). These subtasks include synchronous tasks (such as the validation subtask) and asynchronous tasks (such as the content review subtask, tag extraction subtask, and cover image extraction subtask).
[0052] Therefore, upon receiving a write task to be processed, the server first splits the write task to be processed into at least two subtasks. The purpose of splitting the write task to be processed is to divide it into synchronous and asynchronous tasks in order to improve the processing efficiency of the write task.
[0053] Among them, a synchronous task refers to a task that, once initiated, must wait for the current task to complete before the next task can be executed.
[0054] An asynchronous task is a task that, once initiated, can immediately be used to execute other tasks without waiting for the task to complete. Once the asynchronous task is completed, the execution result can be obtained through a callback function or similar method.
[0055] S202, determine the task type of each subtask based on the dependencies between different subtasks.
[0056] The task types include synchronous and asynchronous types.
[0057] Taking the above content publishing task as an example, the execution of sub-tasks such as content review, tag extraction, and cover screenshot often depends on the execution results of sub-tasks such as verification. For example, content review, tag extraction, and cover screenshot can only be performed if all verifications pass.
[0058] Based on this, after obtaining at least two subtasks of the write task to be processed, the task inputs and outputs of different subtasks can be determined according to their execution content. Furthermore, based on these inputs and outputs, the dependencies between the different subtasks can be determined. This dependency is an execution dependency, meaning the execution of one subtask depends on the output of another subtask as its input. Therefore, based on these dependencies, the task type of each subtask can be determined, classifying them into synchronous and asynchronous tasks. Each subtask can be either a synchronous or asynchronous task.
[0059] S203. For each subtask, execute the subtask and verify the task state transition results before and after the subtask is executed based on the task state transition relationship and the task type of the subtask.
[0060] Among them, the task status transition relationship includes the transition relationship between different task states of each task type within the task cycle.
[0061] For each subtask, during its execution, depending on the execution conditions, the subtask's task state typically undergoes an update. That is, before and after execution, the subtask's task state transitions from its pre-execution state to its post-execution state. To ensure the reasonableness of the task state transitions before and after each subtask's execution, and thus guarantee the effectiveness of each subtask's execution, task state transition relationships can be pre-defined. These relationships include the transitions between different task states within a synchronous task's timeframe, and the transitions between different task states within a asynchronous task's timeframe. In other words, these task transition relationships define the allowed task state transitions before and after the execution of synchronous and asynchronous tasks. When an unallowed task state transition occurs, it indicates that the subtask execution has failed. Optionally, the above task state transition relationships can be represented in the form of a task state machine.
[0062] Therefore, for each subtask, the subtask is first executed to obtain the task state transition result before and after the execution of the subtask. The task state transition result is used to characterize the task state of the subtask from the task state before execution to the task state after execution. Then, according to the task state transition relationship and the task type of the subtask, the task state transition result before and after the execution of the subtask is verified to obtain the verification result.
[0063] If the verification result indicates that the verification is passed, it can be determined that the task state transition before and after the execution of the subtask is allowed; otherwise, if the verification result indicates that the verification is failed, it can be determined that the task state transition before and after the execution of the subtask is not allowed.
[0064] Optionally, if the task state transition relationship includes the allowed task state transition results under each task type, then for each subtask, the task state transition results before and after execution are searched from the allowed task state transition results under the task type of that subtask included in the task state transition relationship. If found, the verification passes; otherwise, the verification fails. Alternatively, if the task state transition relationship includes another task state that each task state under each task type is allowed to transition to, then for each subtask, the task state before execution is searched from the task states under the task type of that subtask included in the task state transition relationship. Then, the task state after execution is searched from the other task states that the task state before execution is allowed to transition to from the task state before execution included in the task state transition relationship. If found, the verification passes; otherwise, the verification fails.
[0065] In one optional embodiment, if the subtask's task type is synchronous, the subtask is executed by the aforementioned synchronization thread. Optionally, the aforementioned synchronization thread can be the main thread in the server that executes the task processing method.
[0066] In another optional embodiment, when the task type of the subtask is asynchronous, S203 above includes sending the subtask to an asynchronous thread pool or an asynchronous task queue so that the asynchronous thread pool or the asynchronous task queue executes the subtask.
[0067] Accordingly, in this embodiment, after sending the subtask to the asynchronous thread pool or asynchronous task queue, the task status of the subtask is updated from the actual initial state to the starting state.
[0068] In this embodiment, for asynchronous subtasks executed by an asynchronous thread pool or asynchronous task queue, the main thread can send the subtask to the asynchronous thread pool or asynchronous task queue, so that the receiving asynchronous thread pool or asynchronous task queue can invoke an asynchronous thread to execute the subtask. After sending the subtask to the asynchronous thread pool or asynchronous task queue, the task status of the subtask can be updated to indicate that the subtask has been processed, avoiding duplicate processing of the subtask. Specifically, the task status of the subtask can be updated from the actual initial state to the starting state. Optionally, the starting state can be an intermediate state indicating that the subtask has been sent to the asynchronous thread pool or asynchronous task queue.
[0069] S204. Based on the verification results, the task execution results of the subtasks are written to the database.
[0070] Data persistence refers to the process of writing data to non-volatile storage media (such as hard drives, data block files, etc.) through specific persistence mechanisms to achieve long-term data preservation, transaction consistency assurance, and subsequent retrieval and utilization.
[0071] For each subtask, after obtaining the above verification results, the task execution result of the subtask is persisted in the database based on the verification results.
[0072] Optionally, if the above verification result indicates that the verification passes, the task execution result of the subtask (such as the execution result when the execution is successful, the failure indicator when the execution fails, the number of retries and the retry time when retries are required, etc.) and the task status after execution are written to disk; or if the above verification result indicates that the verification fails, the task status after the execution of the subtask is set to a failed final state, and the failed final state and the log recording the disallowed task status transition result are used as the task execution result, and the data is written to disk.
[0073] Optionally, when writing the execution results of a subtask to the database, the subtask's task information will be recorded, such as task identifier, execution status, execution time, and callback time.
[0074] In the above task processing method, a pre-defined task state transition relationship is established, which includes the transition relationships between different task states of each task type within the task cycle. Upon receiving a write task to be processed, the task is split into at least two subtasks. Based on the dependencies between different subtasks, the task type of each subtask is determined to be synchronous or asynchronous. Then, for each subtask, after execution, the task state transition result before and after execution is verified according to the aforementioned task state transition relationship and the task type of the subtask. Specifically, it verifies whether the transition from the task state before execution to the task state after execution is allowed. Based on the verification result, the task execution result of the subtask is written to disk. In this way, by defining the different task states of subtasks of different task types during the execution of the write task, as well as the above-mentioned task state transition relationships, the execution process of each subtask of the write task can be managed. This ensures that the logic of the task execution process is clear, the responsibilities of the various collaborative domains are clear, and thus improves the robustness of the write task execution. This enables the handling of write tasks in complex write chain scenarios and improves the task handling effect of the write task.
[0075] Based on the above embodiments, in an exemplary embodiment, the verification of the task state transition result in S203 is further refined. Optionally, such as Figure 3 As shown, it includes the following steps:
[0076] S301, based on the task type of the subtask, obtain the target state after the subtask is executed.
[0077] For each subtask, when verifying the task state transition before and after its execution, it is necessary to first obtain the task state before and after execution. Since subtasks of different task types are executed by different threads, it is also necessary to obtain the target state after execution of the subtask based on its task type.
[0078] In one optional embodiment, S301 includes, when the task type of the subtask is synchronous, obtaining the target state of the subtask after its execution based on the execution result of the subtask. In this embodiment, since synchronous subtasks must wait for completion after initiation, the target state of the subtask after its execution can be obtained directly based on the execution result of the subtask (such as execution failure, execution success, retry execution failure, retry execution success, etc.) after the synchronous subtask is completed.
[0079] In another optional embodiment, S301 includes, when the task type of the subtask is asynchronous, responding to a callback signal generated by the asynchronous thread pool or asynchronous task queue, calling back the execution result of the subtask, and obtaining the target state after the execution of the subtask based on the execution result. In this embodiment, since the asynchronous subtask is sent to the asynchronous thread pool or asynchronous task queue for execution, it is necessary to obtain the execution result of the subtask through a callback. After the asynchronous thread pool or asynchronous task queue completes the execution of the asynchronous subtask, it can generate and feedback a callback signal through a callback thread. Responding to the callback signal, the execution result of the asynchronous subtask is called back, and the target state after the execution of the subtask is obtained based on the execution result. Optionally, responding to the callback signal generated by the asynchronous thread pool or asynchronous task queue, the execution lock of the callback task for the subtask is acquired, and if the execution lock of the callback task is acquired, the execution result of the subtask is called back. Optionally, in response to a callback signal generated by an asynchronous thread pool or asynchronous task queue, an execution lock identifier for the callback task of the subtask is generated based on the task identifier of the subtask. Then, based on this execution lock identifier, it is checked whether an execution lock exists for the callback task of the subtask (i.e., whether an execution lock with the execution lock identifier of the callback task exists). If the check result is negative, an execution lock is created for the callback task of the subtask. Once created, this signifies that the execution lock for the callback task of the subtask is acquired (i.e., lock acquisition was successful), and the callback task for the subtask can then be executed, i.e., the execution result of the subtask is recalled. Optionally, after the callback task for the subtask completes, the execution lock for the callback task of the subtask is released.
[0080] Optionally, if the execution result is successful, the above target state can be a successful final state; if the execution result is unsuccessful, the above target state can be a retry waiting state (the number of retries has not exceeded a preset threshold) or a failure final state; if the execution result is successful retry execution, the above target state can be a successful final state; if the execution result is unsuccessful retry execution, the above target state can be a retry waiting state (the number of retries has not exceeded a preset threshold) or a failure final state.
[0081] S302, if the target state is obtained, determine the task state transition result before and after the subtask is executed based on the initial state before the subtask is executed and the target state after the subtask is executed.
[0082] For each subtask, the task state transition result before and after execution is used to characterize the transition of the subtask's task state from the pre-execution state to the post-execution state. Therefore, if the target state after the subtask's execution is obtained, the task state transition result before and after execution is determined based on the initial state before execution and the target state after execution. Optionally, if the target state after the subtask's execution is not obtained, the target state after the subtask's execution is directly determined to be a failed final state.
[0083] In one optional embodiment, when the task type of the subtask is synchronous, the initial state before the subtask is executed is the actual initial state. Optionally, the aforementioned actual initial state is determined by performing state initialization on the subtask.
[0084] In another optional embodiment, when the task type of the subtask is asynchronous, the initial state before the subtask is executed is an intermediate state. This intermediate state is determined after the subtask is sent to the asynchronous thread pool or asynchronous task queue, and is used to indicate that the subtask has been sent to the asynchronous thread pool or asynchronous task queue.
[0085] In another optional embodiment, the task processing method further includes updating the task status of the subtask from the initial state to the retry waiting state and re-executing the subtask if the target state is not obtained. In this embodiment, for each subtask, in order to ensure the smooth progress of the pending write task, the subtask can be retried if the target state after execution is not obtained. Therefore, the task status of the subtask is first updated from the initial state to the retry waiting state to indicate that the subtask needs to be re-executed, and then the subtask is re-executed. Optionally, for asynchronous subtasks, after updating the task status of the subtask from the initial state to the retry waiting state, the subtask is resent to the asynchronous thread pool or asynchronous task queue.
[0086] Optionally, the retry count for the subtask can be increased, and a retry timeout can be set. Upon reaching the retry timeout, the subtask will be re-executed until the target state after execution is obtained or the increased retry count reaches a preset threshold. Optionally, the initial value of the retry count is 0, and it increases in increments of 1. The preset threshold can be set based on empirical values, experimental results from multiple trials, and the task processing requirements in actual applications; no specific limitations are imposed.
[0087] S303, based on the task status transition result and the task type of the subtask, query from the task status transition relationship to obtain the target transition identifier corresponding to the task status transition result.
[0088] In the task status transition relationship, each transition relationship corresponds to a transition identifier, which is used to identify whether the transition relationship is allowed.
[0089] The task state transition relationship includes multiple transition relationships. Each transition relationship represents a transition from one task state to another, and the corresponding transition identifier indicates whether the transition relationship is allowed, i.e., whether the transition from one task state to another represented by the transition relationship is permitted. Optionally, for each transition relationship included in the task state transition relationship, a "√" is used to indicate that the transition relationship is allowed, and an "×" is used to indicate that the transition relationship is not allowed. For example, the above task state transition relationship can be represented by the table shown in Figure 1. Taking task states a, b, and c as examples, under the synchronization type, the transition relationship from task state a to task state b and the transition relationship from task state a to task state c are allowed, while the transition relationship from task state b to task state c is not allowed. In asynchronous mode, the flow relationships from task state a to task state b, from task state a to task state c, and from task state b to task state c are all allowed.
[0090] Table 1 Task Status Transition Relationship
[0091] Task status Synchronous a Synchronous b Synchronous C asynchronous a asynchronous b asynchronous C a - √ √ - √ √ b - - × - - √ c - - - - - -
[0092] Optionally, for each subtask, firstly, based on the task type of the subtask, search for each transition relationship under that task type in the task state transition relationship. Then, from the aforementioned transition relationships, search for the transition relationship that represents the task state transition result before and after the execution of the subtask; that is, search for the transition relationship that includes the task states in the task state transition result before and after the execution of the subtask, and where the transition direction between task states is the same. In this way, the transition identifier corresponding to the aforementioned transition relationship can be obtained, which serves as the target transition identifier corresponding to the task state transition result before and after the execution of the subtask.
[0093] S304, Determine the verification result of the task status transition based on the target transition identifier.
[0094] Optionally, if the aforementioned target flow identifier flow relationship is allowed, the verification result of the task state flow result before and after the execution of the subtask can be determined to be a pass. Conversely, if the aforementioned target flow identifier flow relationship is not allowed, the verification result of the task state flow result before and after the execution of the subtask can be determined to be a fail.
[0095] In this embodiment, by obtaining the target state after the subtask is executed, the task state transition result before and after the subtask is executed is determined. By querying the target transition identifier corresponding to the above task state transition result from the task state transition relationship, the verification result of the task state transition result is determined. This can improve the efficiency and accuracy of determining the above verification result, thereby improving the task processing effect of the writing task to be processed.
[0096] Based on the above embodiments, in one exemplary embodiment, this application also provides a method for handling callback timeouts for asynchronous tasks. Optionally, such as Figure 4 As shown, it includes the following steps:
[0097] S401, if a callback timeout is detected, update the task status of the subtask to a timeout waiting state, and obtain the task information of the subtask.
[0098] For asynchronous subtasks, when the subtask is sent to the asynchronous thread pool or asynchronous task queue to wait for the asynchronous thread pool or asynchronous task queue to execute the subtask, the execution result callback time of the subtask is recorded. That is, it can be determined in advance how long (callback timeout duration) or at what latest (callback timeout moment) the callback signal should be received from the asynchronous thread pool or asynchronous task queue to call back the task execution result of the subtask.
[0099] However, in some cases, the callback for the subtask's execution result may time out because the asynchronous thread pool or asynchronous task queue has not executed the subtask, or because a callback signal has not been promptly sent back after the subtask has been executed. For example, if the task status of a certain asynchronous subtask is detected to be in the aforementioned intermediate state or waiting for retry state, and the current time has exceeded the set callback timeout period, or the time elapsed since the subtask was sent to the asynchronous thread pool or asynchronous task queue has exceeded the callback timeout period, then a callback timeout for that subtask can be determined.
[0100] Furthermore, for each asynchronous subtask, upon detecting a callback timeout, the task status of the subtask is first updated to a timeout waiting state to indicate that the callback has timed out. Then, the task information of the subtask is obtained to determine the cause of the callback timeout. Optionally, the cause of the callback timeout can be determined based on key fields in the task information of the subtask.
[0101] Optionally, the task state transition relationship can define at least one default callback state that allows retrying of subtask execution results. After updating the subtask's task state to a timeout waiting state, first determine if the aforementioned timeout waiting state exists among the default callback states in the task state transition relationship. If it exists, it means that callback retrying is allowed for this asynchronous subtask, and the subtask's task information can be further obtained. Conversely, if it does not exist, it means that callback retrying is not allowed for this asynchronous subtask, and the target state after the asynchronous subtask's execution can be directly set to a failed final state.
[0102] S402, determine the timeout handling action corresponding to the callback timeout reason represented by the task information of the subtask.
[0103] S403, based on the timeout handling action, performs a callback retry on the execution result of the subtask.
[0104] Once the callback timeout reason is determined, the corresponding timeout handling action can be determined. Optionally, if the callback timeout reason is that the task was not executed, the corresponding timeout handling action is to execute the asynchronous subtask. If the callback timeout reason is that the asynchronous thread pool or asynchronous task queue did not promptly return a callback signal after executing the subtask, the corresponding timeout handling action is to perform an asynchronous completion callback, re-calling back the task execution result of the asynchronous subtask. In this way, the execution result of the subtask can be retried based on the timeout handling action.
[0105] In one optional embodiment, S403 includes, when the timeout processing action is an execution action, increasing the number of task retries and updating the next callback timeout time; updating the timeout waiting state to the first transition state, and according to the timeout processing action, returning to the operation of sending the subtask to the asynchronous thread pool or asynchronous task queue until the target state is obtained, or the increased number of task retries reaches the preset retry number threshold.
[0106] In this embodiment, the task retries are first increased, and the next callback timeout is updated. Then, the timeout waiting time is updated to the first transition time to indicate that the subtask is undergoing a callback retries, thus avoiding concurrent callback retries for that subtask. The timeout handling action can then be invoked, returning to send the subtask to an asynchronous thread pool or asynchronous task queue, i.e., re-executing the subtask until the target state is achieved, or until the increased task retries reach a preset retry threshold. Optionally, the initial value of the task retries is 0, and it increases in increments of 1. The preset retry threshold can be set based on experience, experimental results from multiple trials, and the task processing requirements in actual applications; no specific limitations are imposed.
[0107] In another optional embodiment, S403 includes, when the timeout processing action is an asynchronous completion callback action, increasing the callback count and updating the next callback timeout time; updating the timeout waiting state to the second transition state, and returning the execution result of the callback subtask according to the timeout processing action, until the target state is obtained, or the increased callback count reaches a preset callback count threshold.
[0108] In this embodiment, the callback count is first increased, and the next callback timeout is updated. Then, the timeout period is updated to the second transition period to indicate that the subtask is undergoing a callback retrieval, thus avoiding concurrent callback retries for that subtask. This allows for asynchronous callback actions, returning the execution result of the callback subtask, i.e., calling back the execution result of the subtask until the target state is obtained, or until the increased callback count reaches a preset callback count threshold. Optionally, the initial value of the callback count is 0, and it increases in increments of 1. The preset callback count threshold can be set based on experience, experimental results from multiple trials, and the task processing requirements in actual applications; no specific limitations are imposed.
[0109] In this embodiment, when an asynchronous subtask timeout callback is detected, the execution result of the subtask can be retried by determining the timeout handling action corresponding to the timeout callback reason, so as to support the automatic retry mechanism of asynchronous subtasks, ensure the execution effect of the subtask, and thus improve the task processing effect of pending write tasks.
[0110] Based on the above embodiments, in an exemplary embodiment, the execution of the subtasks in S203 is further refined. Optionally, as... Figure 5 As shown, it includes the following steps:
[0111] S501, Initialize the actual initial state of the subtask.
[0112] For each subtask, before executing it, the actual initial state of the subtask is first initialized. Optionally, the actual initial state of the subtask is initialized as INIT (initial state).
[0113] S502, determine the default initial state of the subtask based on the task state transition relationship and the task type of the subtask.
[0114] S503 executes subtasks under the default initial state, including the actual initial state.
[0115] The task state transition relationship can define at least one default initial state that allows subtasks to execute under different task types. After initializing the actual initial state of the subtask, the default initial state of the subtask under its task type in the task state transition relationship is first determined as the default initial state corresponding to the subtask. If the default initial state includes the actual initial state of the subtask, it can be determined that the subtask is allowed to execute, and thus, the subtask can be executed. Optionally, if the task type of the subtask is synchronous, the subtask is executed directly; if the task type of the subtask is asynchronous, the subtask is sent to an asynchronous thread pool or asynchronous task queue so that the asynchronous thread pool or asynchronous task queue can execute the subtask.
[0116] In this embodiment, when the actual initial state of the initialized subtask is the task state that allows task execution as defined by the task state transition relationship, executing the subtask can ensure the accuracy of the subtask execution, avoid misjudgment of the subtask, and promptly detect the accuracy of the actual initial state of the initialized subtask, avoiding subtask execution failure caused by state initialization errors at the beginning of subtask execution. Thus, the execution effect of the subtask is ensured, thereby improving the task processing effect of the pending write tasks.
[0117] Based on the above embodiments, in an exemplary embodiment, the execution of the subtasks in S503 is further refined. Optionally, as... Figure 6 As shown, it includes the following steps:
[0118] S601, acquire the execution lock for the subtask.
[0119] For each subtask, when executing the subtask, the execution lock for that subtask is acquired first.
[0120] Optionally, for each subtask, an execution lock identifier for the subtask is generated based on the task identifier of the subtask, and the existence of an execution lock for the subtask is checked based on the execution lock identifier of the subtask (i.e., whether there is an execution lock with the execution lock identifier of the subtask). If the detection result is that there is no execution lock, the execution lock for the subtask is created. After creation, it indicates that the execution lock for the subtask is acquired, that is, the execution lock for the subtask is successfully acquired (i.e., the lock is successfully acquired).
[0121] S602, if the execution lock of the subtask is acquired, execute the subtask.
[0122] Optionally, if the execution lock of the subtask is acquired and the task type of the subtask is synchronous, the subtask is executed directly; if the execution lock of the subtask is acquired and the task type of the subtask is asynchronous, the subtask is sent to the asynchronous thread pool or the asynchronous task queue so that the asynchronous thread pool or the asynchronous task queue can execute the subtask.
[0123] Optionally, after the subtask is completed, release the execution lock of the subtask.
[0124] In this embodiment, by executing the subtask after acquiring the execution lock, duplicate execution of the subtask can be avoided when multiple identical subtasks exist. Optionally, for other identical subtasks that failed to acquire the lock, a message indicating that the task has been executed can be sent.
[0125] Based on the above embodiments, in an exemplary embodiment, such as Figure 7 As shown, the method for processing this character includes the following steps:
[0126] S701 splits the write task to be processed into at least two subtasks.
[0127] S702, determine the task type of each subtask based on the dependencies between different subtasks.
[0128] The task types include synchronous and asynchronous types.
[0129] S703. For each subtask, initialize the actual initial state of the subtask; determine the default initial state corresponding to the subtask based on the task state transition relationship and the task type of the subtask; and acquire the execution lock of the subtask if the default initial state includes the actual initial state.
[0130] S704: If the execution lock of the subtask is acquired and the task type of the subtask is synchronous, the subtask is executed, and after the subtask is completed, the target state after the execution of the subtask is obtained according to the execution result of the subtask.
[0131] S705: If the execution lock of the subtask is acquired and the task type of the subtask is asynchronous, the subtask is sent to the asynchronous thread pool or asynchronous task queue so that the asynchronous thread pool or asynchronous task queue executes the subtask and updates the task state of the subtask from the actual initial state to the starting state; in response to the callback signal generated by the asynchronous thread pool or asynchronous task queue, the execution result of the subtask is called back, and the target state after the execution of the subtask is obtained according to the execution result of the subtask.
[0132] S706, for each subtask, if the task type of the subtask is asynchronous, if a callback timeout is detected, update the task status of the subtask to a timeout waiting state, and obtain the task information of the subtask; determine the timeout handling action corresponding to the callback timeout reason represented by the task information of the subtask.
[0133] S707: When the timeout handling action is an execution action, increase the number of task retries and update the next callback timeout time; update the timeout waiting state to the first transition state, and according to the timeout handling action, return to the operation of sending the subtask to the asynchronous thread pool or asynchronous task queue until the target state is obtained, or the increased number of task retries reaches the preset retry threshold.
[0134] S708, when the timeout handling action is an asynchronous callback action, increase the callback count and update the next callback timeout time; update the timeout waiting state to the second transition state, and return the execution result of the callback of the subtask according to the timeout handling action, until the target state is obtained, or the increased callback count reaches the preset callback count threshold.
[0135] S709: For each subtask, if the target state is not obtained, update the task state of the subtask from the initial state to the retry waiting state, and re-execute the subtask.
[0136] S710: For each subtask, query the task state transition relationship based on the task state transition result and the task type of the subtask to obtain the target transition identifier corresponding to the task state transition result, and determine the verification result of the task state transition result based on the target transition identifier.
[0137] The task status transition relationship includes the transition relationship between different task states of each task type within the task cycle; each transition relationship in the task status transition relationship corresponds to a transition identifier, and the transition identifier is used to identify whether the transition relationship is allowed.
[0138] S711, for each subtask, writes the task execution result of the subtask into the database based on the verification result.
[0139] The specific implementation methods of S701-S711 are the same as those in the above embodiments, and will not be repeated here.
[0140] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.
[0141] Based on the same inventive concept, this application also provides a task processing apparatus for implementing the task processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more task processing apparatus embodiments provided below can be found in the limitations of the task processing method described above, and will not be repeated here.
[0142] In one exemplary embodiment, such as Figure 8 As shown, a task processing device is provided, including: a splitting module 810, a first determination module 820, a verification module 830, and a database insertion module 840, wherein:
[0143] The splitting module 810 is used to split the write task to be processed into at least two subtasks.
[0144] The first determining module 820 is used to determine the task type of each subtask based on the dependencies between different subtasks; wherein the task type includes synchronous type or asynchronous type;
[0145] The verification module 830 is used to execute each subtask and verify the task state transition results before and after the execution of the subtask based on the task state transition relationship and the task type of the subtask.
[0146] The data storage module 840 is used to store the data of the task execution results of the subtasks into the database based on the verification results; among them, the task status flow relationship includes the flow relationship between different task statuses of each task type within the task cycle.
[0147] In one exemplary embodiment, the verification module 830 includes:
[0148] The acquisition unit is used to acquire the target state after the subtask is executed, based on the task type of the subtask.
[0149] The first determining unit is used to determine the task state transition result before and after the execution of the subtask based on the initial state before the subtask is executed and the target state after the execution, when the target state is obtained.
[0150] The query unit is used to query the task state transition relationship based on the task state transition result and the task type of the subtask to obtain the target transition identifier corresponding to the task state transition result; wherein, each transition relationship in the task state transition relationship corresponds to a transition identifier, and the transition identifier is used to indicate whether the transition relationship is allowed;
[0151] The verification unit is used to determine the verification result of the task status transition based on the target transition identifier.
[0152] In an exemplary embodiment, the acquisition unit is specifically used to: when the task type of the subtask is synchronous, after the subtask is completed, acquire the target state after the subtask is executed based on the execution result of the subtask; when the task type of the subtask is asynchronous, respond to the callback signal generated by the asynchronous thread pool or the asynchronous task queue, call back the execution result of the subtask, and acquire the target state after the subtask is executed based on the execution result of the subtask.
[0153] In an exemplary embodiment, the verification module 830 is specifically used to: when the task type of the subtask is asynchronous, send the subtask to an asynchronous thread pool or an asynchronous task queue so that the asynchronous thread pool or the asynchronous task queue executes the subtask;
[0154] The task processing device also includes:
[0155] The first update module is used to update the task status of the subtask from its actual initial state to its starting state after the subtask is sent to the asynchronous thread pool or asynchronous task queue.
[0156] In one exemplary embodiment, the task processing apparatus further includes:
[0157] The second update module is used to update the task status of the subtask to a timeout waiting state when a callback timeout is detected, and to obtain the task information of the subtask.
[0158] The second determining module is used to determine the timeout handling action corresponding to the callback timeout reason represented by the task information of the subtask;
[0159] The callback module is used to retry the execution result of the subtask based on the timeout handling action.
[0160] In an exemplary embodiment, the callback module is specifically used to: increase the number of task retries and update the next callback timeout when the timeout processing action is an execution action; update the timeout waiting state to the first transition state, and according to the timeout processing action, return to the operation of sending the subtask to the asynchronous thread pool or asynchronous task queue until the target state is obtained, or the increased number of task retries reaches the preset retry threshold.
[0161] In an exemplary embodiment, the callback module is specifically used to: increase the number of callbacks and update the next callback timeout when the timeout processing action is an asynchronous callback action; update the timeout waiting state to the second transition state, and return the execution result of the callback subtask according to the timeout processing action, until the target state is obtained, or the increased number of callbacks reaches the preset callback number threshold.
[0162] In one exemplary embodiment, the task processing apparatus further includes:
[0163] The third update module is used to update the task status of the subtask from the initial state to the retry waiting state and re-execute the subtask if the target state is not obtained.
[0164] In one exemplary embodiment, the verification module 830 includes:
[0165] An initialization unit is used to initialize the actual initial state of a subtask.
[0166] The second determining unit is used to determine the default initial state of the subtask based on the task state transition relationship and the task type of the subtask.
[0167] An execution unit is used to execute subtasks, given the default initial state and the actual initial state.
[0168] In an exemplary embodiment, the execution unit is specifically configured to: acquire the execution lock of the subtask; and, if the execution lock of the subtask is acquired, execute the subtask.
[0169] Each module in the aforementioned task processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.
[0170] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as task status transitions. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network. When the computer program is executed by the processor, it implements a task processing method.
[0171] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0172] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of various instances of the task processing method described above.
[0173] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of each instance of the task processing method described above.
[0174] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of various instances of the task processing method described above.
[0175] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0176] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0177] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0178] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A task processing method, characterized in that, The method includes: The write task to be processed is split into at least two sub-tasks. Based on the dependencies between different subtasks, determine the task type of each subtask; wherein, the task type includes synchronous type or asynchronous type; For each subtask, the subtask is executed, and the task state transition results before and after execution are verified according to the task state transition relationship and the task type of the subtask; and, Based on the verification results, the task execution results of the subtasks are stored in the database. The task state transition relationship includes the transition relationship between different task states of each task type within the task cycle.
2. The method according to claim 1, characterized in that, The step of verifying the task state transition results before and after the execution of the subtask based on the task state transition relationship and the task type of the subtask includes: Based on the task type of the subtask, obtain the target state after the subtask is executed; Given the target state, the task state transition result before and after the execution of the subtask is determined based on the initial state before the execution of the subtask and the target state after the execution. Based on the task status transition result and the task type of the subtask, a query is performed from the task status transition relationship to obtain the target transition identifier corresponding to the task status transition result; wherein, each transition relationship in the task status transition relationship corresponds to a transition identifier, and the transition identifier is used to identify whether the transition relationship is allowed; The verification result of the task status transition is determined based on the target transition identifier.
3. The method according to claim 2, characterized in that, The step of obtaining the target state after the execution of the subtask according to the task type of the subtask includes: If the task type of the subtask is synchronous, after the subtask is completed, the target state after the subtask is executed is obtained based on the execution result of the subtask. If the task type of the subtask is asynchronous, in response to the callback signal generated by the asynchronous thread pool or asynchronous task queue, the execution result of the subtask is called back, and the target state after the execution of the subtask is obtained based on the execution result of the subtask.
4. The method according to claim 3, characterized in that, When the task type of the subtask is asynchronous, executing the subtask includes: The subtask is sent to the asynchronous thread pool or the asynchronous task queue so that the asynchronous thread pool or the asynchronous task queue executes the subtask; After sending the subtask to the asynchronous thread pool or the asynchronous task queue, the method further includes: Update the task state of the subtask from the actual initial state to the starting state.
5. The method according to claim 4, characterized in that, The method further includes: If a callback timeout is detected, the task status of the subtask is updated to a timeout waiting state, and the task information of the subtask is obtained. Determine the timeout handling action corresponding to the callback timeout reason represented by the task information of the subtask; Based on the timeout handling action, the execution result of the subtask is retried via callback.
6. The method according to claim 5, characterized in that, The step of retrying the execution result of the subtask based on the timeout handling action includes: If the timeout handling action is an execution action, increase the number of task retries and update the timeout time for the next callback. Update the timeout waiting state to the first transition state, and according to the timeout handling action, return to the operation of sending the subtask to the asynchronous thread pool or asynchronous task queue until the target state is obtained, or the increased number of task retries reaches the preset retry threshold.
7. The method according to claim 5, characterized in that, The step of retrying the execution result of the subtask based on the timeout handling action includes: If the timeout handling action is an asynchronous callback action, the callback count is increased and the next callback timeout is updated; The timeout waiting state is updated to the second transition state, and the execution result of the subtask is returned according to the timeout handling action until the target state is obtained, or the number of callbacks increases to a preset callback number threshold.
8. The method according to claim 2, characterized in that, The method further includes: If the target state is not obtained, the task state of the subtask is updated from the initial state to the retry waiting state, and the subtask is re-executed.
9. The method according to any one of claims 1-8, characterized in that, The execution of the subtask includes: Initialize the actual initial state of the subtask; Based on the task state transition relationship and the task type of the subtask, determine the default initial state corresponding to the subtask; If the default initial state includes the actual initial state, the subtask is executed.
10. The method according to any one of claims 1-8, characterized in that, Executing the subtask includes: Acquire the execution lock for the subtask; If the execution lock of the subtask is acquired, the subtask is executed.
11. A task processing device, characterized in that, The device includes: The splitting module is used to split the write task to be processed into at least two sub-tasks. The first determining module is used to determine the task type of each subtask based on the dependencies between different subtasks; wherein the task type includes synchronous type or asynchronous type; The verification module is used to execute the subtask for each subtask and verify the task state transition results before and after the execution of the subtask according to the task state transition relationship and the task type of the subtask. The data storage module is used to store the execution results of the subtasks into the database based on the verification results. The task state transition relationship includes the transition relationship between different task states of each task type within the task cycle.
12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.
13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.
14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.