WO2024109003A1 - Task processing method and apparatus, and node - Google Patents

Abstract

A task processing method, comprising: a node acquiring an application programming interface (API) request sent by a user; creating a target task according to the API request, and storing task information of the target task in a database; executing the target task, and acquiring the execution state of the target task; and when the execution state of the target task is "failed", re-executing the target task according to the task information of the target task that is stored in the database. In this way, data (i.e. a task created for an API request) for retry self-healing is added in a database, such that a node can perform retry self-healing when the execution of a task fails, thereby ensuring the correctness of a result returned by the node.

Description

A task processing method, device and node

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 22, 2022, with application number 202211463984.8 and application name “A task processing method, device and node”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of information technology (IT) technology, and in particular to a task processing method, device and node.

Background technique

With the continuous development of technology, the service architecture has gradually evolved from a monolithic architecture to a distributed architecture, and the deployment mode of services has also evolved from a single process mode to a cluster mode to ensure the elastic expansion capability and high reliability of the software to cope with changes in users. Generally, clusters can be divided into active-standby clusters and active-active clusters. In an active-standby cluster, only the primary node works, and the standby node does not work. In an active-active cluster, each node works, and a load balancer needs to be deployed at the front end to achieve load sharing of the cluster. Compared with active-standby clusters, active-active clusters have higher performance and are more commonly used. However, in an active-active cluster, when there is a call relationship between two nodes, if the communication between the two nodes fails or the called node fails to process, the result returned to the user by one of the nodes will be inconsistent with the actual result, affecting the user experience.

Summary of the invention

The present application provides a task processing method, device, node, computer storage medium and computer product, which can reprocess the task requested by the user when the task processing fails, thereby ensuring that the result returned by the node is consistent with the actual result, thereby improving the user experience.

In a first aspect, the present application provides a task processing method that can be applied to a first node. The method may include: obtaining an application programming interface API request issued by a user; creating a target task according to the API request, and storing the task information of the target task in a database; executing the target task and obtaining the execution status of the target task; when the execution status of the target task is failed, re-executing the target task according to the task information of the target task stored in the database.

In this way, after receiving an API request, the node creates a task for the request and persists it in the database. When the task processing corresponding to the request fails, the task corresponding to the request can be retrieved from the database and re-executed. Therefore, by adding retry self-healing data (i.e., the task created for the API request) in the database, the node can retry self-healing when the task execution fails, ensuring the correctness of the result returned by the node.

In a possible implementation, after executing the target task, the method further includes: storing the execution status of the target task in a database, thereby refreshing the status of the task in the database. At this time, obtaining the execution status of the target task may include: obtaining the execution status of the target task from the database.

In a possible implementation, the method may further include: obtaining heartbeat information of the second node from a database, the heartbeat information being used to indicate whether the second node fails; when the second node fails, obtaining task information of at least one task created by the second node and not executed or failed to execute from the database; executing at least one task according to the task information of the at least one task, and storing the execution status of each task in the at least one task in the database. In this way, the situation of task processing failure caused by node failure is avoided, and the reliability of task processing is ensured.

In a possible implementation, the method may further include: when the number of times the target task is executed reaches a preset number and the last execution status is failure, outputting an alarm message, so that the user can be informed of the resource processing failure and perform manual repair.

In a possible implementation, the API request is used to request the creation of a target resource and the execution of a target task, including: creating a target resource.

In a possible implementation, the method further includes: returning the execution status of the target task to the user, so that the user can know the execution status of the task.

In a second aspect, the present application provides a task processing device. The device can be deployed on a first node. The device includes: a request acquisition module, used to acquire an application programming interface API request issued by a user; a task creation module, used to create a target task according to the API request and store the task information of the target task in a database; a task processing module, used to execute the target task and acquire the execution status of the target task; and, when the execution status of the target task is failed, re-execute the target task according to the task information of the target task stored in the database.

In a possible implementation, after executing the target task, the task processing module is further used to: store the execution status of the target task in a database; wherein, when obtaining the execution status of the target task, the task processing module is specifically used to: obtain the execution status of the target task from the database; state.

In a possible implementation, the task processing module is further used to: obtain heartbeat information of the second node from a database, where the heartbeat information is used to indicate whether the second node fails; when the second node fails, obtain task information of at least one task created by the second node and not executed or failed to execute from the database;

At least one task is executed according to the task information of at least one task, and the execution status of each task in the at least one task is stored in a database.

In a possible implementation, the task processing module is further used to: output an alarm message when the number of times the target task is executed reaches a preset number and the last execution status is failure.

In a possible implementation, the API request is used to request the creation of a target resource, and the task processing module, when executing the target task, is specifically used to: create the target resource.

In a possible implementation, the task processing module is further configured to return the execution status of the target task to the user.

In a third aspect, the present application provides a node, comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

In a fourth aspect, the present application provides a computing device, comprising: at least one memory for storing a program; at least one processor for executing the program stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect. Exemplarily, the computing device may be a node in a device cluster, such as node 1 shown in FIG. 2 .

In a fifth aspect, the present application provides a computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster executes the method described in the first aspect or any possible implementation of the first aspect.

In a sixth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

In a seventh aspect, the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

It can be understood that the beneficial effects of the second to seventh aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

The following is a brief introduction to the drawings required for describing the embodiments or prior art.

FIG1 is a schematic diagram of a working process of a node in a master-master cluster provided in an embodiment of the present application;

FIG2 is a schematic diagram of the system architecture of a task processing system of a master-master cluster provided in an embodiment of the present application;

FIG3 is a schematic diagram of resources included in an API request provided in an embodiment of the present application;

FIG4 is a schematic diagram of task processing when a node fails according to an embodiment of the present application;

5 is a schematic diagram of a change in resource state when a node processes resources provided by an embodiment of the present application;

FIG6 is a flowchart of a task processing method provided in an embodiment of the present application;

FIG7 is a schematic diagram of the structure of a task processing device provided in an embodiment of the present application;

FIG8 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

FIG. 9 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application.

Detailed ways

The term "and/or" in this article is a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and/or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The symbol "/" in this article indicates that the associated objects are in an or relationship, for example, A/B means A or B.

The terms "first" and "second" in the specification and claims herein are used to distinguish different objects rather than to describe a specific order of the objects. For example, a first response message and a second response message are used to distinguish different response messages rather than to describe a specific order of the response messages.

In the embodiments of the present application, the words "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two. For example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

Exemplarily, FIG1 shows a schematic diagram of the working process of a node in a master-master cluster. As shown in FIG1 , in order to improve resource processing performance, an asynchronous processing method is often used inside node 1. In FIG1 , a part of threads in the thread pool of node 1 can obtain one or more application programming interface (API) requests, and store the resources of each API request in the database layer (DB layer). After storing the resources of a certain API request in the database, node 1 can read the storage result from the database through the thread that processes the API request. When the storage result is a successful storage, the thread returns the request result representing the successful processing to the user. Another part of the threads in the thread pool can be used for internal processing resources, such as calling APIs of other services. In addition, after the resources of a certain API request are stored in the database, the resource handler in node 1 can call the services provided by other nodes through a thread. Finally, node 1 can send the results returned by other nodes to the user. Exemplarily, the services provided by other nodes can also be called "downstream services", that is, services located downstream of the services provided by node 1, or services that node 1 needs to call. For example, node 1 provides service 1, and node 2 provides service 2. If service 1 needs to call service 2 during operation, service 2 can be called the downstream service of service 1.

However, in Figure 1, when the resource processor in node 1 fails, or the node corresponding to the downstream service fails, etc., node 1 will find it difficult to obtain the results returned by other nodes, causing the result returned to the user by node 1 when storing the corresponding resource in its database to be inconsistent with the result it actually needs to return to the user (i.e., the result returned by other nodes).

In view of this, an embodiment of the present application provides a task processing method, which can create a task for each resource in the API request when storing the resources in the API request in the database, and store the created tasks in the database. Then, each task can be executed. When a task fails to execute, the task can be retrieved from the database and reprocessed, thereby ensuring that the resources of the API request can be processed, and then ensuring the correctness of the results returned by the node to the user. Therefore, by adding retry self-healing data to the database (i.e., tasks created for each resource in the API request), the node can retry self-healing when the task fails to execute, thereby ensuring the correctness of the results returned by the node.

Exemplarily, Fig. 2 shows an architecture of a task processing system of a master-master cluster. As shown in Fig. 2, the task processing system 200 of the master-master cluster may include: a master-master cluster 210 and a database 220. The master-master cluster 210 includes n nodes, where n≥2.

In this embodiment, each node in the master-master cluster 210 includes: a request acquisition module 211 , a task creation module 212 , a task scheduling module 213 and a task processing module 214 .

Among them, the request acquisition module 211 in each node is mainly used to obtain the API request issued by the user. Exemplarily, the user can issue an API request through the user interface provided by the node. Exemplarily, the API request may include one or more resources to be processed, such as products purchased or updated by the user or tenant. In some embodiments, after the request acquisition module 211 obtains the API request, the resources contained in the API request can be stored in the database 220 to complete the persistence of the resources. In addition, the request acquisition module 211 can also transmit the API request it obtains to the task creation module 212.

The task creation module 212 is mainly used to create tasks for the resources contained in the API request through a preconfigured function after obtaining the API request sent by the request acquisition module 211, and store the created tasks in the database 220 to complete the persistence of the created tasks. In some embodiments, each task can be associated with a user or tenant, and/or associated with a resource. In some embodiments, different tasks can be associated with the same user or tenant. In addition, different tasks can be associated with different resources. In some embodiments, when multiple resources are included in an API request, the execution order of the tasks corresponding to each resource can be determined based on the dependency relationship or superior-subordinate relationship between each resource. For example, as shown in Figure 3, if the resources included in the API request are: virtual machines, network cards and volumes purchased by tenants, since network cards and volumes need to be created before executing the creation of virtual machines, and there is no dependency relationship between the creation of network cards and volumes, therefore, tasks can be created for the three resources of creating virtual machines, creating network cards and creating volumes, and the tasks corresponding to the creation of network cards and the creation of volumes can be set in parallel, and the tasks corresponding to the creation of virtual machines need to be executed after the tasks corresponding to the creation of network cards and the creation of volumes are completed.

The task scheduling module 213 is mainly used to obtain tasks that need to be executed by the node to which it belongs (such as unprocessed tasks or failed tasks, etc.) from the database 220, and to allocate task queues according to the creation time of the tasks, the dependency between tasks, or the identification of the tasks (such as the identification of the tenant associated with the task, or the identification of the resource associated with the task, etc.). In some embodiments, when the task queues are allocated according to the creation time of the tasks, the processing order of each task in the task queue is related to the creation time of each task, wherein the earlier the creation time of the task is, the earlier the execution order of the task is, that is, the earlier it is executed. In some embodiments, when the task queues are allocated according to the identification of the task, tasks with the same identification can be allocated to the same task queue. In some embodiments, the task scheduling module 213 can allocate tasks to be processed according to the identification of the task. A task can be assigned to one task queue or multiple task queues, depending on the actual situation and is not limited here.

The task processing module 214 is mainly used to execute the tasks in each task queue assigned by the task scheduling module 213. In some embodiments, the task processing module 214 can assign different threads to different task queues, that is, execute the tasks in different task queues through different threads. In some embodiments, when executing a task, the task processing module 214 can call the API of the service provided by other nodes, and wait for the execution result of the service called by it, and store the corresponding execution status in the database 220. Exemplarily, the execution status stored in the database 220 by the task processing module 214 can be understood as the execution status of each task, so that the task scheduling module 213 can know which tasks in the database 220 are pending tasks and which are successfully processed tasks. Among them, the pending tasks may include unprocessed tasks and/or tasks that have failed to be processed. For example, when a task is successfully processed, the execution status of the service required to be called by the task obtained by the task processing module 214 is successful; when a task is failed to be processed, the execution status of the service required to be called by the task obtained by the task processing module 214 is failed. In some embodiments, the task processing module 214 can also feedback the execution status corresponding to each resource to the user.

In some embodiments, each node in the master cluster 210 may have a thread that periodically scans failed tasks from the database 220 so that the task scheduling module 213 in the corresponding node adds the failed tasks to the task queue for retry self-healing.

In this embodiment, the database 220 is mainly used to store resources, tasks, and execution status of each task stored in each node in the master cluster 210 .

In some embodiments, the database 220 may also store the operation status of each node in the main main cluster 210, so that when a node fails, the tasks required to be executed are transferred to other nodes, thereby avoiding the situation where resource processing fails due to node failure and ensuring the reliability of resource processing. For example, as shown in (A) of Figure 4, the main main cluster includes node 1, node 2 and node 3, and tasks 1 to 9 are stored in the database 220. The tasks required to be executed by node 1 are tasks 1 to 3, the tasks required to be executed by node 2 are tasks 4 to 6, and the tasks required to be executed by node 3 are tasks 7 to 9. As shown in (B) of Figure 4, when node 2 fails, node 1 can take over the tasks required to be executed by node 2, and the tasks required to be executed by node 1 are tasks 1 to 6. As a result, when node 2 fails, the tasks required to be executed by node 2 can also be transferred to other nodes for execution, ensuring the reliability of resource processing.

Among them, each node in the main cluster 210 can register its identity in the database 220 when it is started, and write heartbeats to the database 220 during the subsequent operation process, so as to determine whether the node is faulty through the heartbeat of the node, and determine the faulty node through the registered identity of the node. At this time, each node can have a thread for regularly writing heartbeats to the database 220, so as to refresh the state of the node to the database 220. In addition, each node can also have a thread that regularly queries the health status of other nodes from the database 220 to regularly query whether other nodes are faulty.

As a possible implementation, a master node may be set in the master cluster 210, and the master node periodically scans the status of other nodes from the database 220, and when a node fails, takes over the tasks that have not been successfully processed by the failed node. Exemplarily, each node in the master cluster 210 may periodically try to lock a row in the database 220, and at this time, the node that preferentially locks the row may be used as the master node. Exemplarily, in order to prevent the master node from affecting its own processing performance due to taking over the tasks of other nodes for a long time, when a node serves as a master node for a preset time, the node may give up (i.e., release) locking the row in the database 220 and not participate in the selection of the master node for a period of time.

As another possible implementation, each node in the master cluster 210 can take over the tasks that were not successfully executed by the failed node. At this time, each node can periodically query the health status of other nodes from the database 220. If node 1 detects that node 2 is faulty, node 1 can take over some of the tasks that were not successfully executed on node 2 based on its own execution capability. The tasks that node 1 did not take over can be taken over by other nodes that detect that node 2 is faulty.

Further, after the node that has failed returns to normal, the node can give priority to the tasks that belong to it but have not been successfully executed, so as to prevent its own tasks from being handled in time after being taken over by other nodes. In addition, when executing a task, the node that has returned to normal can first judge whether the task that it currently needs to execute is executed by the execution status of each task stored in the database 220, if it has been executed and the result of execution is success, then it skips the task and processes the next task. At the same time, when executing the task that it takes over, the node that takes over the task of the node that has failed can also first judge whether the task that it currently needs to execute is executed by the execution status of each task stored in the database 220, if it has been executed, then it skips the task and processes the next task. Of course, when judging that the task that it currently needs to execute has been executed, the node that takes over the task of the node that has failed can also judge whether the execution status is successful, if the execution fails, then it can continue to execute the task, otherwise it processes the next task.

In some embodiments, for complex business scenarios, there are dependencies between resource processing, and order preservation is required to simplify internal implementation. Therefore, the state constraints of resources can be used to ensure the order of internal resource processing to prevent disorder. In this embodiment, closed loop implementation can be used to make the state constraints of resources more complex, thereby ensuring the order of internal resource processing. Among them, the state of a resource can include whether the creation of the resource is successful. Success, whether the resource is deleted successfully, whether the resource is updated successfully, etc. Exemplarily, if the status after processing any resource is failed, the any resource can be reprocessed until the status after processing the any resource is successful, thereby constraining the status of the resources and ensuring the processing order of the resources. In addition, if the number of times any resource is processed reaches the preset number of times and the status after processing the any resource is still failed, an alarm message can be output, thereby letting the user know the situation of resource processing failure and perform manual repair.

Specifically, as shown in FIG5 , when a node in the master-master cluster is creating a resource, it can write the state of the resource being created into the aforementioned database 220. At this time, the state of the resource in the database 220 can be refreshed to being created, i.e., “creating” as shown in FIG5 . When the node successfully creates a resource, it can write the state of successful creation into the aforementioned database 220. At this time, the state of the resource in the database 220 can be refreshed to an available state, i.e., “available” as shown in FIG5 . When the node fails to create a resource, it knows that the resource creation has failed, and it can retry to create the resource at intervals of a preset duration (such as 10s, 20s, etc.). Among them, when the node recreates the resource, it can also write the state of retrying to create into the aforementioned database 220. At this time, the state of the resource in the database 220 can be “retrying” as shown in FIG5 . After the node is recreated and created successfully, that is, "close-loop success" shown in Figure 5, it can write the successful creation status into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to an available status, that is, "available" shown in Figure 5.

If the node still fails to create successfully after being recreated m times (m≥1), that is, "close-loop retry failed" as shown in FIG5, the node can write the creation failure status into the aforementioned database 220. At this time, the database 220 can refresh the resource status to an unavailable state, that is, "failed" as shown in FIG5. After the node fails to create a resource, it can return the creation failure information to the user so that the user can repair it. When the user completes the repair, the node can recreate the resource, that is, "re-enter the initial state after the task is successfully repaired" as shown in FIG5, and can write the resource creation status into the aforementioned database 220. At this time, the resource status in the database 220 can be refreshed to being created, that is, "creating" as shown in FIG5. .

After completing the creation of resources, when a node in the master cluster needs to delete resources, the node can write the state of deleting resources into the aforementioned database 220. At this time, the state of the resource in the database 220 can be refreshed to being deleted, that is, "deleting" shown in Figure 5. When the node successfully deletes the resource, it can write the state of successful deletion into the aforementioned database 220. At this time, the state of the resource in the database 220 can be refreshed to deleted, that is, "deleted" shown in Figure 5. When the node fails to delete the resource, it knows that the resource deletion has failed, and it can retry to delete the resource at intervals of a preset time (such as 10s, 20s, etc.). Among them, when the node deletes the resource again, it can also write the state of retrying deletion into the aforementioned database 220. At this time, the state of the resource in the database 220 can be "retrying" as shown in Figure 5, and the state of deleting resources can be written into the aforementioned database 220. At this time, the state of the resource in the database 220 can be refreshed to being deleted, that is, "deleting" shown in Figure 5. After the node is deleted again and the deletion is successful, that is, "close-loop success" shown in Figure 5, the status of successful deletion can be written into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to deleted, that is, "deleted" shown in Figure 5.

If the node still fails to delete successfully after re-deleting m times (m≥1), that is, "close-loop retry failed" as shown in Figure 5, it can write the deletion failure status into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to an unavailable state, that is, "failed" as shown in Figure 5. After the node fails to delete the resource, it can return the deletion failure information to the user so that the user can repair it. When the user completes the repair, the node can delete the resource again, that is, "re-enter the initial state after the task is successfully repaired" as shown in Figure 5, and can write the status of deleting the resource into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to being deleted, that is, "deleting" as shown in Figure 5.

After completing the creation of resources, when a node in the master-master cluster needs to update resources, the node can write the status of the resource being updated into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to being updated, that is, "modifying" shown in Figure 5. When the node successfully updates the resource, it can write the status of the successful update into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to updated, that is, "available" shown in Figure 5. When the node fails to update the resource, it knows that the resource update has failed, and it can retry to update the resource at a preset time interval (such as 10s, 20s, etc.). Among them, when the node re-updates the resource, it can also write the status of the retrying update into the aforementioned database 220. At this time, the status of the resource in the database 220 can be "retrying" as shown in Figure 5. After the node is re-updated and the update is successful, that is, "close-loop success" shown in Figure 5, it can write the successful update status into the aforementioned database 220. At this time, the status of the resource in the database 220 can be refreshed to updated, that is, "available" shown in Figure 5.

If the node still fails to update successfully after re-updating m times (m≥1), that is, "close-loop retry failed" as shown in Figure 5, it can write the update failure status to the aforementioned database 220. At this time, the database 220 can refresh the status of the resource to an unavailable state, that is, "failed" as shown in Figure 5. After the node fails to update the resource, it can return the update failure information to the user so that the user can repair it. When the user completes the repair, the node can re-update the resource, that is, "re-update after successful task repair" as shown in Figure 5. The resource state being updated can be written into the aforementioned database 220. At this time, the resource state in the database 220 can be refreshed to being updated, i.e., "modifying" as shown in FIG. 5 .

In FIG5 , only when the state of a resource is available (ie, available), the update operation or the delete operation is allowed for the resource, thereby performing state constraints.

In addition, if there is a dependency between two resources and the two resources are located on different nodes, the status of the two resources will be updated to the available state (i.e., available) only when the status of the two resources is both available (i.e., available). When the status of any one of the two resources is unavailable (i.e., failed), the status of the two resources can be updated to the unavailable state (i.e., failed). In this way, the status constraint is performed.

In addition, when the time consumed by the retry is long, the user can perform other operations on the node during this period. In some embodiments, the operation to be performed in the retry is related to the operation that failed to be performed before the retry. For example, if the operation that failed to be performed before the retry was to create a resource, then the operation to be performed in the retry is to create a resource; if the operation that failed to be performed before the retry was to update a resource, then the operation to be performed in the retry is to update a resource.

Furthermore, the state of a resource can be associated with the result of task processing corresponding to the resource. When the state of a resource is unavailable, there is a high probability that the task corresponding to the resource cannot be processed successfully. When the state of a resource is available, there is a high probability that the task corresponding to the resource can be processed successfully. Therefore, when the task corresponding to a resource is processed successfully, the state of the resource can be refreshed to an available state. When the task processing corresponding to a resource is identified, the state of the resource can be refreshed to an unavailable state, and at the same time, an attempt can be made to re-execute the operations required before this operation, such as creating resources, updating resources, etc. In this way, it is ensured that when the task corresponding to the resource is re-executed, it can be executed successfully, thereby improving reliability.

The above is an introduction to the resource processing system of the master-master cluster provided in an embodiment of the present application. Based on the above content, a task processing method provided in an embodiment of the present application is introduced below.

Exemplarily, FIG6 shows a process of a task processing method. The method may be executed by any node in the aforementioned master-master cluster 210. As shown in FIG6, the task processing method may include the following steps:

S601: Obtain an application programming interface (API) request issued by a user.

In this embodiment, the user can issue the required request through the user interface provided by the node. For example, when the user needs to purchase a product, the user can issue a request to purchase the product in the user interface provided by the node. After the user issues the request, the node obtains the request. Exemplarily, the request issued by the user can be, but is not limited to, the API request described above. Exemplarily, the API request can be used to create a resource, such as creating a virtual machine, etc., or it can be a request to purchase a product or service, such as purchasing clothes and other goods, etc., or it can be a request to pay money, such as initiating a payment transaction through a financial application (application, APP).

S602: Create a target task according to the obtained API request, and store the task information of the target task in a database.

In this embodiment, after obtaining the request sent by the user, the node can create a task for the request through a preconfigured function, thereby obtaining a target task. Exemplarily, the target task is associated with the API request. For example, when the API request is used to create a resource, the target task is the task of creating the resource; when the API request is used to purchase a product or service, the target task is the task of purchasing a product or service; when the API request is used to request payment, the target task is the task of paying the money.

Furthermore, after obtaining the target task, the node can store the task information of the target task in the database to complete the persistence of the target task, so that when it is known that the target task processing fails, the task can be obtained from the database and re-executed, or, when a node fails, the task to be executed is transferred to other nodes through the database to ensure the reliability of task processing. Exemplarily, the task information of the target task may include the task type and/or task content, etc. For example, when the target task is a task to create a virtual machine, the task information of the target task may include the size of the hard disk in the virtual machine, the type of operating system, the type and parameters of the central processing unit, the network bandwidth, etc.; when the target task is a task to pay money, the task information of the target task may include the amount of money to be paid, etc.

S603: Execute the target task and obtain the execution status of the target task.

In this embodiment, after persisting the target task in the database, the node can execute the target task and store the execution status of the target task in the database. Exemplarily, the node can obtain the execution status of the target task from the database, such as whether the execution is successful or failed. Of course, after the node executes the target task, it can also know the execution status of the target task, and the node does not need to obtain the execution status of the target task from the database.

In some embodiments, when the API request is used to request the creation of a target resource, the node can create the target resource when executing the target task. For example, when the API request is used to request the creation of a virtual machine, the node can create the virtual machine when executing the target task.

S604: When the execution status of the target task is failed, re-execute the target task according to the task information of the target task stored in the database. Task.

In this embodiment, when the node learns that the execution status of the target task is failed, it can re-acquire the task information of the target task from the database and re-execute the target task. In some embodiments, when the number of times the target task is executed reaches a preset number of times and the last execution status is failed, an alarm message can be output. This allows the user to learn about the failure of resource processing and perform manual repairs.

In this way, after receiving the API request, the node creates a task for the request and persists it in the database. When the task fails to be processed, the task information of the task can be retrieved from the database and re-executed until it succeeds. Therefore, by adding retry self-healing data (i.e., the task created for the API request) in the database, the node can retry self-healing when the task fails to execute, ensuring the correctness of the result returned by the node.

In some embodiments, after executing the target task, the node may return the execution status of the target task obtained by executing it to the user, so that the user can be informed of the task execution status.

In some embodiments, when there are multiple nodes, each node can write its own heartbeat information into the database. The heartbeat information can be used to characterize whether a node fails. Each node can obtain the heartbeat information of other nodes from the database. When a node (hereinafter referred to as "node 1") obtains the heartbeat information of another node (hereinafter referred to as "node 2"), if it is determined that node 2 fails, node 1 can obtain the task information of M (M≥1) tasks created by node 2 and not executed or failed to execute from the database, and, according to the task information of these M tasks, execute these M tasks, and store the execution results of each task in the M tasks in the database. Thus, the situation of task processing failure caused by node failure is avoided, and the reliability of task processing is guaranteed.

Furthermore, to avoid repeated processing of tasks, for any task to be executed among the M tasks, before executing the task to be executed, node 1 may first determine whether the execution status of any task to be executed stored in the database is failed or not executed.

It is understandable that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Based on the method in the above embodiment, the embodiment of the present application also provides a task processing device.

Exemplarily, FIG7 shows a task processing device. The resource processing device can be but is not limited to being deployed in any node in the aforementioned master-master cluster. As shown in FIG7, the task processing device 700 includes: a request acquisition module 701, a task creation module 702, and a task processing module 703. Among them, the request acquisition module 701 is used to obtain an application programming interface API request issued by a user. The task creation module 702 is used to create a target task according to the API request and store the task information of the target task in a database. The task processing module 703 is used to execute the target task and obtain the execution status of the target task; and when the execution status of the target task is failed, the target task is re-executed according to the task information of the target task stored in the database. Exemplarily, the request acquisition module 701 can be but is not limited to the request acquisition module 211 in FIG2, the task creation module 702 can be but is not limited to the task creation module 212 in FIG2, and the task processing module 703 can be but is not limited to the task processing module 214 in FIG2.

In some embodiments, after executing the target task, the task processing module 703 is further used to: store the execution status of the target task in a database. When acquiring the execution status of the target task, the task processing module is specifically used to: acquire the execution status of the target task from the database.

In some embodiments, the task processing module 703 is also used to: obtain heartbeat information of the second node from the database, the heartbeat information is used to characterize whether the second node fails; when the second node fails, obtain task information of at least one task created by the second node and not executed or failed to execute from the database; execute at least one task according to the task information of at least one task, and store the execution status of each task in the at least one task in the database.

In some embodiments, the task processing module 703 is further used to: output an alarm message when the number of times the target task is executed reaches a preset number and the last execution status is failure.

In some embodiments, when the API request is used to request the creation of a target resource, the task processing module 703 is specifically used to create the target resource when executing the target task.

In some embodiments, the task processing module is further used to: return the execution status of the target task to the user.

In some embodiments, the request acquisition module 701, the task creation module 702 and the task processing module 703 can all be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the request acquisition module 701 is described below by taking the request acquisition module 701 as an example. Similarly, the implementation of the task creation module 702 and the task processing module 703 can refer to the implementation of the request acquisition module 701.

As an example of a software functional unit, the request acquisition module 701 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the request acquisition module 701 may include code running on multiple hosts/virtual machines/containers. It should be noted that Multiple hosts/virtual machines/containers for running the code can be distributed in the same region or in different regions. Furthermore, multiple hosts/virtual machines/containers for running the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Generally, one region can include multiple AZs.

Similarly, multiple hosts/virtual machines/containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

As an example of a hardware functional unit, the request acquisition module 701 may include at least one computing device, such as a server, etc. Alternatively, the request acquisition module 701 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The multiple computing devices included in the request acquisition module 701 can be distributed in the same region or in different regions. The multiple computing devices included in the acquisition module 1001 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the request acquisition module 701 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

It should be noted that, in other embodiments, the request acquisition module 701 can be used to execute any step in the aforementioned task processing method, the task creation module 702 can be used to execute any step in the method provided by the above embodiments, and the task processing module 703 can be used to execute any step in the method provided by the above embodiments; the steps that the request acquisition module 701, the task creation module 702, and the task processing module 703 are responsible for implementing can be specified as needed, and all functions of the task processing device 700 are realized by respectively implementing different steps in the method provided by the above embodiments through the request acquisition module 701, the task creation module 702, and the task processing module 703.

The present application also provides a computing device 800. As shown in FIG8 , the computing device 800 includes: a bus 802, a processor 804, a memory 806, and a communication interface 808. The processor 804, the memory 806, and the communication interface 808 communicate with each other through the bus 802. The computing device 800 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 800.

The bus 802 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, FIG8 is represented by only one line, but does not mean that there is only one bus or one type of bus. The bus 804 may include a path for transmitting information between various components of the computing device 800 (e.g., the memory 806, the processor 804, and the communication interface 808).

Processor 804 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

The memory 806 may include a volatile memory, such as a random access memory (RAM). The processor 104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

The memory 806 stores executable program codes, and the processor 804 executes the executable program codes to respectively implement the functions of the request acquisition module 701, the task creation module 702, and the task processing module 703, thereby implementing all or part of the steps of the method in the above embodiment. That is, the memory 806 stores instructions for executing all or part of the steps in the method in the above embodiment.

Alternatively, the memory 806 stores executable codes, and the processor 804 executes the executable codes to respectively implement the functions of the task processing device 700, thereby implementing all or part of the steps in the above-mentioned embodiment method. That is, the memory 806 stores instructions for executing all or part of the steps in the above-mentioned embodiment method.

The communication interface 803 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 800 and other devices or communication networks.

The present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device cluster includes at least one computing device. The computing device can also be a terminal device such as a desktop computer, a laptop computer or a smart phone.

As shown in Fig. 9, the computing device cluster includes at least one computing device 800. The memory 806 in one or more computing devices 800 in the computing device cluster may store the same instructions for executing all or part of the steps in the above embodiment method.

In some possible implementations, the memory 806 of one or more computing devices 800 in the computing device cluster may also store partial instructions for executing all or part of the steps in the above-mentioned embodiment method. In other words, the combination of one or more computing devices 800 may jointly execute instructions for executing all or part of the steps in the above-mentioned embodiment method.

It should be noted that the memory 806 in different computing devices 800 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the task processing apparatus 700. That is, the instructions stored in the memory 806 in different computing devices 800 can implement the functions of one or more of the aforementioned request acquisition module 701, task creation module 702, and task processing module 703.

In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network.

Based on the method in the above embodiment, the embodiment of the present application provides a node. The node may include: at least one memory for storing a program; and at least one processor for executing the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method in the above embodiment.

Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

Based on the method in the above embodiment, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)), etc.

It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

Claims (16)

A task processing method, characterized in that it is applied to a first node, and the method comprises: Obtaining the application programming interface API request issued by the user; Create a target task according to the API request, and store the task information of the target task in a database; Execute the target task and obtain the execution status of the target task; When the execution status of the target task is failure, the target task is re-executed according to the task information of the target task stored in the database. The method according to claim 1, characterized in that after executing the target task, the method further comprises: Storing the execution status of the target task in the database; The obtaining the execution status of the target task includes: The execution status of the target task is obtained from the database. The method according to claim 1 or 2, characterized in that the method further comprises: Acquire heartbeat information of the second node from the database, where the heartbeat information is used to indicate whether a fault occurs in the second node; When the second node fails, obtaining from the database task information of at least one task that was created by the second node and has not been executed or has failed to be executed; According to the task information of the at least one task, the at least one task is executed, and the execution status of each task in the at least one task is stored in the database. The method according to any one of claims 1 to 3, characterized in that the method further comprises: When the number of times the target task is executed reaches a preset number and the last execution status is failure, an alarm message is output. The method according to any one of claims 1 to 4, characterized in that the API request is used to request the creation of a target resource, and the executing the target task comprises: Create the target resource. The method according to any one of claims 1 to 5, characterized in that the method further comprises: The execution status of the target task is returned to the user. A task processing device, characterized in that it is deployed on a first node, and comprises: A request acquisition module is used to acquire an application programming interface (API) request issued by a user; A task creation module, used to create a target task according to the API request and store the task information of the target task in a database; The task processing module is used to execute the target task and obtain the execution status of the target task; and when the execution status of the target task is failure, re-execute the target task according to the task information of the target task stored in the database. The device according to claim 7 is characterized in that, after executing the target task, the task processing module is further used to: store the execution status of the target task in the database; Wherein, when acquiring the execution status of the target task, the task processing module is specifically used to: acquire the execution status of the target task from the database. The device according to claim 7 or 8, characterized in that the task processing module is further used to: Acquire heartbeat information of the second node from the database, where the heartbeat information is used to indicate whether a fault occurs in the second node; When the second node fails, obtaining from the database task information of at least one task that was created by the second node and has not been executed or has failed to be executed; According to the task information of the at least one task, the at least one task is executed, and the execution status of each task in the at least one task is stored in the database. The device according to any one of claims 7 to 9, characterized in that the task processing module is further used to: When the number of times the target task is executed reaches a preset number and the last execution status is failure, an alarm message is output. The device according to any one of claims 7 to 10, characterized in that the API request is used to request the creation of a target resource, and the task processing module, when executing the target task, is specifically used to: Create the target resource. The device according to any one of claims 7 to 11, characterized in that the task processing module is further used to: The execution status of the target task is returned to the user. A node, characterized by comprising: at least one memory for storing a program; at least one processor, configured to execute the program stored in the memory; Wherein, when the program stored in the memory is executed, the processor is used to execute the method according to any one of claims 1-6. A computing device cluster, characterized in that it includes at least one computing device, each computing device includes a processor and a memory; The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1-6. A computer-readable storage medium stores a computer program, and when the computer program runs on a processor, the processor executes the method according to any one of claims 1 to 6. A computer program product, characterized in that when the computer program product runs on a processor, the processor is caused to execute the method according to any one of claims 1 to 6.