Task processing method and task processing system

Abstract

Embodiments of the present application provide a task processing method and a task processing system. The method comprises: pulling target task description information from a target message queue of a message queue set, task description information saved in each message queue of the message queue set being pulled in a concurrent manner by multiple task consumers; obtaining target task data and configuration information corresponding to the target task description information, the target task data and the configuration information being set when the target task is created, the target task description information being pushed to the target message queue according to the configuration information; and if it is determined according to the configuration information that the version of the target task description information and the target task data is consistent, processing the target task data according to the configuration information to process the target task. Embodiments of the present application can dynamically adjust the manner of processing tasks, and improve the flexibility and efficiency of processing tasks. Embodiments of the present application can be applied to various scenes such as cloud technology, artificial intelligence, intelligent transportation, and assisted driving.

Description

Technical Field

[0001] This application relates to the field of software system technology, and more specifically, to a task processing method and a task processing system. Background Technology

[0002] Task processing is a feature found in many software systems. Existing task systems generally provide fixed task processing functionality, meaning this functionality is written into the system's code. In this case, the system processes each task strictly according to the provided method. When adjustments are needed to how the system handles a task, the system must be restarted and its code upgraded.

[0003] Therefore, existing task systems cannot dynamically adjust the way they process tasks, resulting in poor flexibility in task processing; once adjustments are needed, they incur significant costs and are inefficient. Summary of the Invention

[0004] The embodiments of this application provide a task processing method and a task processing system, which at least to some extent allow for dynamic adjustment of the way tasks are processed, thereby improving the efficiency and flexibility of task processing.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to one aspect of the embodiments of this application, a task processing method is provided, the method comprising: pulling target task description information from a target message queue of a message queue set, wherein at any given time, only one task consumer among a plurality of task consumers can pull task description information from the message queues of the message queue set, such that the task description information stored in each message queue of the message queue set is pulled concurrently by the plurality of task consumers; obtaining target task data and configuration information corresponding to the target task description information, wherein the target task data and configuration information are set when the target task is created, and the target task description information is pushed to the target message queue in the message queue set according to the configuration information; when it is determined according to the configuration information that the versions of the target task description information and the target task data are consistent, processing the target task data according to the configuration information to process the target task.

[0007] According to one aspect of the embodiments of this application, a task processing apparatus is provided, the apparatus comprising: an information retrieval unit, configured to retrieve target task description information from a target message queue of a message queue set, wherein at any given time, only one task consumer among a plurality of task consumers can retrieve task description information from the message queues of the message queue set, such that the task description information stored in each message queue of the message queue set is retrieved concurrently by the plurality of task consumers; an acquisition unit, configured to acquire target task data and configuration information corresponding to the target task description information, wherein the target task data and configuration information are set when the target task is created, and the target task description information is pushed to the target message queue in the message queue set according to the configuration information; and a processing unit, configured to process the target task data according to the configuration information when it is determined, based on the configuration information, that the versions of the target task description information and the target task data are consistent, in order to process the target task.

[0008] In some embodiments of this application, based on the foregoing scheme, the processing unit is configured to: split the target task data and the target task description information to obtain subtask data and subtask description information corresponding to multiple subtasks respectively; push each subtask description information to the target message queue; pull one subtask description information from the target message queue each time and process the subtask data corresponding to the subtask description information to obtain a subtask processing result; collect the subtask description information and subtask processing result corresponding to the processed subtask data; if the number of collected subtask description information is consistent with the number of subtask description information obtained by splitting, then output the target task processing result or the processing status of the target task according to the configuration information, wherein the target task processing result is generated based on the collected subtask processing results.

[0009] In some embodiments of this application, based on the foregoing scheme, the processing unit is configured to: if the configuration information indicates that the target task is an editable task, compare the first version number in the target task description information with the second version number in the target task data; if the first version number in the target task description information is consistent with the second version number in the target task data, determine that the versions of the target task description information and the target task data are consistent.

[0010] In some embodiments of this application, based on the foregoing scheme, after processing the target task data according to the configuration information to process the target task, the processing unit is further configured to: if an abnormality occurs during the processing of the target task data, push the target task description information to the target message queue to reprocess the target task until the number of times the target task is processed reaches the number of retries included in the configuration information.

[0011] In some embodiments of this application, based on the foregoing scheme, each message queue in the message queue set has a corresponding priority, and the information retrieval unit is configured to: poll each message queue in the message queue set in descending order of priority to sequentially attempt to retrieve task description information from each message queue; attempt to retrieve task description information from a target message queue to retrieve the target task description information, wherein the attempt to retrieve task description information from the target message queue is performed when polling the target message queue in the message queue set and determining that the target message queue contains task description information.

[0012] In some embodiments of this application, based on the foregoing scheme, the information retrieval unit is configured to: if task description information is retrieved from the message queue, then re-polling each message queue in the message queue set according to priority from high to low.

[0013] In some embodiments of this application, based on the foregoing scheme, the data structure of the target message queue is a list in a specified non-relational database.

[0014] In some embodiments of this application, based on the foregoing scheme, before retrieving target task description information from the target message queue of the message queue set, the information retrieval unit is further configured to: sort the task description information in the delay queue according to the scores associated with each task description information in ascending order, wherein the data structure of the delay queue is an ordered set in the specified non-relational database, and the score is the planned execution time of the task corresponding to the task description information; whenever the score associated with the task description information at the top of the delay queue is consistent with the current time, retrieve the task description information at the top of the delay queue; after retrieving the target task description information from the delay queue, move the target task description information to the target message queue.

[0015] In some embodiments of this application, based on the foregoing scheme, the processing unit is configured to: select the processor object indicated by the configuration information to process the target task data.

[0016] According to one aspect of the embodiments of this application, a task processing system is provided, the system comprising: a task producer, configured to create a target task according to configuration information, store target task data corresponding to the target task, and obtain target task description information according to the target task data; a message queue set, including multiple message queues for storing task description information, the multiple message queues including a target message queue; and multiple task consumers, the task consumers being able to execute the task processing method as described in the above embodiments by accessing the task producer and the message queue set.

[0017] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the task processing method as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the task processing method as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the task processing method as described in the above embodiments.

[0020] In some embodiments of this application, the configuration information is set when the target task is created, and the task description information is also pushed to the corresponding message queue based on the configuration information. Furthermore, the target task data is only processed further based on the configuration information after confirming that the versions of the target task description information and the target task data are consistent. Therefore, the entire task processing method is driven by configuration information, realizing the configurability of the task processing method. Thus, when the task processing method needs to be adjusted, there is no need to restart the system service; only the configuration information needs to be adjusted. This allows for dynamic adjustment of the task processing method, greatly improving the flexibility of task processing. Simultaneously, the ease of adjusting the configuration information also improves the efficiency of adjusting the task processing method and significantly reduces the cost of adjustment. In addition, multiple task consumers pull task description information from the message queue set concurrently, facilitating system expansion and ensuring task processing efficiency.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0023] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown;

[0024] Figure 2 A flowchart of a task processing method according to an embodiment of this application is shown;

[0025] Figure 3 An architectural block diagram of a task processing system according to an embodiment of this application is shown;

[0026] Figure 4 A flowchart illustrating the creation of a task according to an embodiment of this application is shown;

[0027] Figure 5 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 240 is provided.

[0028] Figure 6 A flowchart illustrating the processing of tasks in a real-time queue according to an embodiment of this application is shown;

[0029] Figure 7 An embodiment according to this application is shown. Figure 2 Flowchart of the steps preceding step 240;

[0030] Figure 8 A flowchart illustrating the processing of tasks in a delay queue according to an embodiment of this application is shown;

[0031] Figure 9 A flowchart illustrating the processing of target task data based on configuration information according to an embodiment of this application is shown;

[0032] Figure 10 A flowchart illustrating a processing task according to an embodiment of this application is shown;

[0033] Figure 11 A block diagram of a task processing apparatus according to an embodiment of this application is shown;

[0034] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0035] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0036] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0037] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0038] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0039] With the advent of the information age, task processing has become one of the important functions of many software systems. Here, a task can be any operation or set of operations that any software system can perform.

[0040] As business operations evolve, batch operations become necessary, such as batch creation, batch updating, and batch deletion of user data. The common approach is synchronous operation, which leads to the following problems:

[0041] (1) The processing time will increase exponentially with the amount of data in batch operations, resulting in low efficiency.

[0042] (2) The performance of business processing depends on the performance of a single machine, which is not conducive to system expansion.

[0043] (3) Failure of a single data item during processing will cause the entire operation to stop, resulting in low system availability.

[0044] The above issues lead to a poor user experience and low system maintainability.

[0045] In related technologies, the channel module based on the Golang programming language can also be used to implement lightweight asynchronous task systems. However, such asynchronous task systems have the following drawbacks:

[0046] (1) It can only be used on a single machine and cannot be applied to a distributed system. The processing capacity of the task depends on the performance of the single machine, which is not conducive to system expansion.

[0047] (2) The capabilities are too simple. It does not support task processing by priority, has no ability to delay tasks, no task failure retry mechanism, no ability to split and manage parent and child tasks, and the task processing is not flexible enough.

[0048] (3) Restarting the server will cause tasks to be lost.

[0049] Therefore, this application first provides a task processing method. The task processing method provided by the embodiments of this application can overcome the above-mentioned deficiencies. It not only supports task configurability, thereby dynamically adjusting the task processing method, but also supports functions such as task priority execution, real-time tasks, delayed tasks, task failure retries, and parent-child task splitting management. It also enables smooth system restart, ensuring that tasks are not lost during server restarts, greatly improving system availability and maintainability, and facilitating system expansion.

[0050] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown. For example... Figure 1 As shown, the system architecture 100 may include: a user terminal 110, a system server 120, a first consumer server 130, a second consumer server 120, and a third consumer server 150. Each consumer server and the user terminal 110 establishes a communication connection with the system server 120. The system server 120 is deployed with a message queue set including multiple message queues. Each consumer server is deployed with a consumer end, and the consumer ends on each consumer server concurrently retrieve task description information from the message queues on the system server 120 to execute corresponding tasks. The user terminal 110 is equipped with a client, and the system server 120 is also deployed with a server end that provides services to the client on the user terminal 110. Taking the first consumer server 130 as an example of the implementation terminal in this application embodiment, when the task processing method provided in this application is applied... Figure 1In the system architecture shown, a process can be as follows: First, the user uses a client on user terminal 110 to access the server on system server 120 and submits target task data and configuration information, thereby creating a target task on system server 120. Next, system server 120 generates target task description information corresponding to the target task data, determines the target message queue on system server 120 according to the corresponding configuration information, and sends the target task description information to the target message queue. Consumers on each consumer server poll the message queue on system server 120. When the first consumer server 130 polls the target message queue, it can retrieve the target task description information from the target message queue. Finally, the first consumer server 130 retrieves the corresponding target task data and configuration information from system server 120 according to the target task description information, and further determines whether the versions of the target task description information and the target task data are consistent according to the configuration information. If they are consistent, the target task data is processed according to the configuration information, thereby realizing the processing of the target task.

[0051] In some embodiments of this application, the target task is any one of the following: creating user data, deleting user data, or updating user data.

[0052] In some embodiments of this application, the message queues on the system server 120 have different priorities.

[0053] It should be understood that Figure 1 The number of user terminals, system servers, and consumer servers shown is merely illustrative. Depending on implementation needs, there can be any number of user terminals, system servers, and consumer servers. For example, system server 120 can be a server cluster consisting of multiple servers, and the number of consumer servers can be less than three or more than three.

[0054] It should be noted that, Figure 1 The illustration shown is merely one embodiment of this application. Although in Figure 1 In the embodiment, both the consumer and the message queue reside on the server. However, in other embodiments of this application, the consumer and / or message queue can reside on various terminal devices such as desktop computers, laptops, iPads, smartphones, and in-vehicle terminals. Figure 1 In the embodiment, the client and server initiating the task creation are located on different terminal devices, but in other embodiments of this application, they may also be located on the same terminal device; although in Figure 1 In the embodiment, all message queues reside on the same terminal device; however, in other embodiments of this application, the message queues in the message queue set may reside on different terminal devices. Figure 1In the embodiment, both the message queue set and the server are located on the system server 120, but it is easy to understand that they can also be located on different terminal devices. This application does not limit this in any way, and the scope of protection of this application should not be limited as a result.

[0055] It is easy to understand that the task processing method provided in the embodiments of this application is generally executed by a server, and correspondingly, the task processing device is generally located in the server. However, in other embodiments of this application, the terminal device may also have similar functions to the server, thereby executing the task processing scheme provided in the embodiments of this application.

[0056] Therefore, the solutions in this application can be applied to terminals or servers. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0057] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0058] Figure 2 A flowchart of a task processing method according to an embodiment of this application is shown. This task processing method can be executed by various computing and processing devices, such as user terminals or cloud servers. User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, wearable devices, etc. Embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving. Please refer to... Figure 2 As shown, this task processing method includes at least the following steps:

[0059] In step 240, target task description information is pulled from the target message queue of the message queue set. At any given time, only one task consumer among the multiple task consumers can pull task description information from the message queue of the message queue set, so that the task description information stored in each message queue of the message queue set is pulled concurrently by multiple task consumers.

[0060] The message queue set includes multiple message queues. Multiple task consumers may include a target task consumer. The steps in this embodiment can be executed by the target task consumer, and multiple task consumers pull data concurrently, with each task consumer residing on a different terminal device.

[0061] Multiple task consumers concurrently pull task description information from the message queues of the message queue set. This means that each task consumer can pull task description information from the message queues of the message queue set within a certain time period. However, at any given moment, only one task consumer is allowed to pull task description information from the message queues of the message queue set. Other task consumers can only pull task description information at other times.

[0062] Each task consumer can be allowed to pull task description information from any message queue in the message queue set, or one or more task consumers can be specified to pull task description information from a message queue.

[0063] Task description information is information that corresponds one-to-one with a task. It may include a task ID, task version number, and other information. When the task description includes both a task ID and a task version number, it can also be called task identification information. The task description information accurately identifies the corresponding task; it can even be the task data itself.

[0064] Figure 3 An architectural block diagram of a task processing system according to an embodiment of this application is shown. Figure 3 The task processing system shown can be used to execute the solutions of the embodiments of this application. Below, it will be combined with... Figure 3 This section will introduce the solutions of the embodiments of this application. Please refer to [link / reference]. Figure 3 As shown, the task processing system includes producers, queues, and consumers. Producers can create tasks by splitting them into subtasks or by calling CGI (Common Gateway Interface). The queues include multiple message queues, and there are multiple consumers, designated Worker1, Worker2, ..., WorkerN. The task description information corresponding to the tasks created by the producers is added to the respective message queues. Each consumer can retrieve the task description information from the message queues and execute the corresponding task. Producers and message queues can reside on the same terminal device or on different terminal devices.

[0065] Each consumer can reside on a server. Therefore, the task processing system in this embodiment is a distributed asynchronous task system. By performing concurrent operations, the impact between tasks can be reduced. Even if there are a large number of tasks to be processed, efficient processing can be achieved by conveniently adding consumers to handle the tasks. Therefore, the system is easy to expand, improving system performance and user experience.

[0066] The target task description information is generated based on the target task data after the target task is created, for example, it can be extracted from the target task data.

[0067] Figure 4 A flowchart illustrating the task creation process according to one embodiment of this application is shown. Please refer to... Figure 4 The task creation process can specifically include the following steps: First, a task is created via a CGI interface or by splitting it into subtasks, specifically based on the obtained configuration. Here, configuration refers to configuration information, which can be submitted to the system by the user when creating the task or pre-set by the system. This configuration information drives the execution method of the task and can correspond to a type of task, determining how to execute that type of task. During task creation, the corresponding task data is obtained and persistently stored in the appropriate storage module. Storage modules include three persistent storage engines: MySQL, Redis, and files. When storing task data in the storage module, the persistent storage engine used to store the task data is determined based on the configuration information, and the task data is sent to the determined persistent storage engine for storage. Then, corresponding task description information will be generated based on the task data, and the task description information will be pushed into a message queue built on Redis (Remote Dictionary Server) according to the configuration information. The message queue includes a real-time queue and a delayed queue. The real-time queue is used to store the task description information corresponding to real-time tasks, and the delayed queue is used to store the task description information corresponding to delayed tasks. Whether the task description information is pushed to the real-time queue or the delayed queue can be determined by the configuration information.

[0068] In one embodiment of this application, each message queue in the message queue set has a corresponding priority.

[0069] The priorities of different message queues can vary. Both real-time and delayed queues can have corresponding priorities. For example, in a message queue set containing three message queues, the priorities of each message queue in the set can be high, medium, and low, respectively.

[0070] Figure 5 An embodiment according to this application is shown. Figure 2A flowchart detailing step 240 is provided. Please refer to [link / reference]. Figure 5 As shown, step 240 may specifically include the following steps:

[0071] In step 241, each message queue in the message queue set is polled in descending order of priority to try to pull task description information from each message queue in turn.

[0072] Each message queue in the message queue set can be non-empty, and one or more message queues can be empty. As mentioned earlier, task description information is used to identify a task; therefore, the task identified by the task description information in a high-priority message queue is a high-priority task.

[0073] There are various ways to poll the message queues in the message queue set according to their priority from high to low, as long as it ensures that the task description information in the high-priority message queues can be retrieved first.

[0074] In one embodiment of this application, polling each message queue in the message queue set according to priority from high to low includes: if task description information is retrieved from the message queue, then polling each message queue in the message queue set again according to priority from high to low.

[0075] When task description information is retrieved from a message queue and the corresponding task is processed, a higher-priority message queue may be pushed with other task description information. In this embodiment, when task description information is retrieved from a message queue, the process restarts from the highest-priority message queue in the message queue set, polling in descending order of priority, ensuring that higher-priority tasks are processed first.

[0076] In one embodiment of this application, the message queues in the message queue set are polled in descending order of priority, including: if a unique and retained task description information is retrieved from the first message queue, the polling of the message queues in the message queue set continues from the second message queue in descending order of priority, wherein the second message queue is the message queue with the highest priority among the message queues in the message queue set whose priority is lower than that of the first message queue.

[0077] The unique task description information retained in the first message queue can be either the only one pushed into the first message queue, or it can be the last one retrieved from multiple task description information in the first message queue.

[0078] If task description information is retrieved from the message queue and the message queue also contains other task description information, then after processing the task corresponding to the task description information, it is necessary to continue to retrieve other task description information from the message queue and process the corresponding tasks.

[0079] In one embodiment of this application, polling each message queue in the message queue set according to its priority from high to low includes: dividing a time window into time slices corresponding to each message queue in the message queue set to obtain multiple time slices, wherein the length of the time slice is positively correlated with the priority of the message queue corresponding to the time slice; polling the message queue corresponding to the time slice in each time slice of the current time window, so as to poll each message queue sequentially within the current time window, and after the current time window ends, continuing to poll the message queues corresponding to each time slice of the next time window in the next time window.

[0080] A time window is the length of time it takes to complete one round of polling of all message queues in the message queue set. That is, after each time window, one round of polling of all message queues in the message queue set is completed. The polling of each message queue in the message queue set is repeated cyclically, using time windows as the unit.

[0081] If there are two message queues, a high-priority message queue and a low-priority message queue, and a time window of 10 minutes, with the high-priority message queue having a time slice of 8 minutes and the low-priority message queue having a time slice of 2 minutes, then 80% of the time within the time window will be used to poll the high-priority message queue, and only 20% of the time will be used to poll the low-priority message queue, thus ensuring that high-priority tasks are executed first.

[0082] In this embodiment, since the length of the time slice is positively correlated with the priority of the message queue corresponding to the time slice, the time slice of the message queue with higher priority is longer, thereby ensuring that the tasks corresponding to the message queue with higher priority can be processed more easily.

[0083] In other embodiments of this application, the message queues in the message queue set can be polled in other ways. Specifically, a corresponding random number interval is set for each message queue in the message queue set. The length of the random number interval corresponding to each message queue is positively correlated with the priority of each message queue. When polling the message queues, a random number is randomly generated in the union of all random number intervals, and then the message queues corresponding to the random number intervals into which the random number falls are polled.

[0084] Specifically, suppose there are two message queues, a high-priority message queue and a low-priority message queue. The first random number interval corresponding to the high-priority message queue is [0, 0.8], and the second random number interval corresponding to the low-priority message queue is (0.8, 1). Then, a random number belonging to [0, 1] can be randomly generated. Based on whether this random number belongs to the first random number interval, the high-priority message queue corresponding to the first random number interval is polled; based on whether this random number belongs to the second random number interval, the low-priority message queue corresponding to the second random number interval is polled. The above embodiment also ensures that tasks corresponding to high-priority message queues are more likely to be processed first.

[0085] In step 242, an attempt is made to retrieve task description information from the target message queue in order to retrieve the target task description information. The attempt to retrieve task description information from the target message queue is made when polling the target message queue in the message queue set and determining that the target message queue contains task description information.

[0086] The priority of the target message queue can be arbitrary. The message queues in the message queue set are polled sequentially according to their priority. This will always result in polling the message queue containing the task description information, or the target message queue containing the target task description information.

[0087] When polling a message queue, if the message queue does not contain task description information, the message queue will be skipped and polling will continue for lower priority message queues.

[0088] In one embodiment of this application, the data structure of the target message queue is a list in a specified non-relational database.

[0089] Specifically, the specified non-relational database can be Redis, and the data structure of the target message queue can be a List in Redis.

[0090] Redis is a key-value store that supports various value types, including String, List, Set, ZSet (sorted set), and Hash. These data types support push / pop, add / remove, intersection, union, difference, and more complex operations, all of which are atomic.

[0091] Once the task description information is retrieved from the message queue, the corresponding task will be executed immediately. Therefore, the message queue can also be called a real-time queue.

[0092] Figure 6A schematic flowchart illustrating the processing of tasks in a real-time queue according to an embodiment of this application is shown. Please refer to... Figure 6 As shown, if the message queue set contains high-priority List queues and low-priority List queues, the processing of tasks in these List queues specifically includes the following steps: First, a task scheduler is provided specifically for real-time queue task scheduling; the task scheduler can be a coroutine. Next, the high-priority List queue is read; if a task can be read from this queue, it is processed until the task processing is complete. If no task can be read from a high-priority List queue, the low-priority List queue is read; if a task can be read from this queue, it is processed until the task processing is complete. After the task processing is complete, the task scheduler continues to loop through the above operations. This is easy to understand. Figure 6 In this example, the tasks in the List queue are specifically task description information.

[0093] Figure 7 An embodiment according to this application is shown. Figure 2 A flowchart of the steps preceding step 240. (For example...) Figure 7 As shown, the following steps may be included before step 240:

[0094] In step 210, the task description information in the delay queue is sorted in ascending order according to the score associated with each task description information. The data structure of the delay queue is an ordered set in a specified non-relational database, and the score is the planned execution time of the task corresponding to the task description information.

[0095] In this step, the task description information corresponding to the delayed task is pre-stored in the delay queue.

[0096] A sorted set, also known as a ZSet or Sorted Set in Redis, is a collection of elements that are associated with a score. This score can be a timestamp representing the planned execution time, calculated by summing the current timestamp with the timestamp of the delay duration.

[0097] Since the score represents the planned execution time, sorting the task description information according to the scores associated with each task description information from smallest to largest will place the task description information corresponding to the task with the shortest delay time (the one whose planned execution time is closest to the current time) at the top.

[0098] In step 220, whenever the score associated with the task description information at the top of the delay queue matches the current time, the task description information at the top of the delay queue is retrieved from the delay queue.

[0099] Since the task description information at the top of the delay queue corresponds to the task that needs to be executed first, it is only necessary to compare the score associated with the task description information at the top with the current time. Whenever the task description information at the top is taken out of the delay queue, it will be pushed to the corresponding message queue.

[0100] In step 230, after retrieving the target task description information from the delay queue, the target task description information is moved to the target message queue.

[0101] Move the target task description information from the delay queue to the target message queue so that the target task can be processed in a timely manner like other tasks.

[0102] In this embodiment of the application, the ordered set data structure is used to achieve delayed processing of tasks, which can ensure that tasks can be processed at the planned time.

[0103] In other embodiments of this application, multiple delay queues with different priorities may be set up, and then each delay queue may be polled in descending order of priority.

[0104] Figure 8 A flowchart illustrating the processing of tasks in a delayed queue according to an embodiment of this application is shown. See also... Figure 8 As shown, the process includes the following steps: First, a delayed task scheduler is provided, specifically for scheduling tasks in the delayed queue. The delayed task scheduler can be a coroutine. Next, the ZSet queue is sorted by score, and data within the current time is retrieved, i.e., task description information whose score matches the current time is retrieved. If task description information corresponding to a task is retrieved, the task description information is moved to the real-time queue List. Then, the delayed task scheduler continues to execute the above operations in a loop.

[0105] Please continue reading. Figure 2 As shown, in step 250, target task data and configuration information corresponding to the target task description information are obtained. The target task data and configuration information are set when the target task is created, and the target task description information is pushed to the target message queue in the message queue set according to the configuration information.

[0106] Target task data and configuration information can be stored in the same location or in different locations. The configuration information can contain multiple information items, one of which can be used to indicate to which message queue in the message queue set the producer should push the target task description information to.

[0107] Target task data refers to the raw data of the task, containing various information such as the operations to be performed. Target task description information can be extracted from the target task data. Target task data can also be the same as the target task description information.

[0108] In step 260, when it is determined from the configuration information that the versions of the target task description information and the target task data are consistent, the target task data is processed according to the configuration information to process the target task.

[0109] In one embodiment of this application, determining that the versions of the target task description information and the target task data are consistent based on the configuration information includes: if the configuration information indicates that the target task is an editable task, then comparing the first version number in the target task description information with the second version number in the target task data; if the first version number in the target task description information is consistent with the second version number in the target task data, then determining that the versions of the target task description information and the target task data are consistent.

[0110] The configuration information may also include an information item indicating whether the corresponding task is an editable task.

[0111] As mentioned earlier, task description information can include a version number, and task data can also contain a version number. If, when pushing target task description information to the target message queue, the first version number of the target task description information is V1, and the second version number in the target task data is also V1; however, after retrieving the target task description information, the second version number in the target task data changes to V2, it indicates that the target task data has changed. In this case, the target task has been altered, and execution of the target task needs to be stopped. Furthermore, in some cases, if the target task data has been deleted, execution of the target task also needs to be stopped.

[0112] In this embodiment, the reliability of task processing is ensured by detecting the task version based on the configuration information. In addition, the configuration information can be used to flexibly adjust whether the task can be modified, thereby improving the user experience.

[0113] Figure 9 A flowchart illustrating the processing of target task data based on configuration information according to one embodiment of this application is shown. Figure 9 As shown, the specific steps include:

[0114] In step 910, the target task data and target task description information are split into subtask data and subtask description information corresponding to multiple subtasks respectively.

[0115] like Figure 3 and Figure 4As shown, tasks can also be created by splitting them into subtasks. The subtask description information can be the subtask ID.

[0116] In step 920, the description information of each subtask is pushed to the target message queue.

[0117] The subtask ID can be pushed to the target message queue. In other embodiments of this application, the description information of each subtask can be pushed to different message queues.

[0118] In step 930, a subtask description is retrieved from the target message queue each time, and the subtask data corresponding to the subtask description is processed to obtain the subtask processing result.

[0119] By processing the data of each subtask, the execution of each subtask can be achieved, and the corresponding subtask processing results can be obtained.

[0120] In step 940, subtask description information and subtask processing results corresponding to the processed subtask data are collected.

[0121] In one embodiment of this application, collecting subtask description information and subtask processing results corresponding to the processed subtask data includes: saving the subtask description information corresponding to the processed subtask data to a hash data structure with the ID in the target task description information as the key; and saving the subtask processing results corresponding to the processed subtask data to a set data structure.

[0122] A hash data structure is the same as the hash data structure in Redis databases, and a set data structure is the same as the Set data structure in Redis databases. By using a hash data structure to store subtask description information, efficient access can be achieved.

[0123] In step 950, if the number of collected subtask description information is consistent with the number of subtask description information obtained from the splitting, the target task processing result or the processing status of the target task is output as a callback according to the configuration information, wherein the target task processing result is generated based on the collected subtask processing results.

[0124] If the number of subtask descriptions collected is the same as the number of subtask descriptions obtained from the breakdown, it means that all subtasks have been processed.

[0125] The result of the target task can be obtained by combining the results of the subtasks. The processing status of the target task can be that all subtasks have been completed. Configuration information can determine whether the result of the target task processing or the processing status of the target task is output as a callback, and it can also determine the recipient of the callback output, such as the party that called the execution of the target task.

[0126] In this embodiment of the application, the task can also be split into multiple sub-tasks and executed separately, which can effectively handle large-scale tasks and ensure task processing capabilities.

[0127] In one embodiment of this application, processing target task data according to configuration information includes: selecting a processor object indicated by the configuration information to process the target task data.

[0128] The configuration information also determines which processor object is used to process the target task data. Please see below. Figure 3 As shown, the task processing part also includes multiple Handlers, which are processor objects. Furthermore, whether it's creating a task, pushing task description information to the message queue, or having a consumer process the task, all rely on storage. Therefore, the storage layer permeates all parts of the task processing system.

[0129] In one embodiment of this application, after processing the target task data according to the configuration information to process the target task, the method further includes: if an exception occurs during the processing of the target task data, pushing the target task description information to the target message queue to reprocess the target task until the number of times the target task is processed reaches the number of retries contained in the configuration information.

[0130] Even after retrieving the task description information from the message queue and starting to execute the corresponding task, if an exception occurs during execution, the task description information needs to be pushed back to the appropriate message queue to ensure that the task can be executed correctly. Figure 3 In addition, consumers can also handle exceptions while processing tasks.

[0131] In this embodiment of the application, the number of retries when task processing exceptions are flexibly configured using configuration information is also allowed, ensuring that the task can be executed reliably.

[0132] In one embodiment of this application, the method further includes: if a system restart instruction is received before the target task data is processed, the processing of the target task data is stopped, and the target task description information is pushed to the target message queue.

[0133] In this embodiment of the application, in the event of a system restart, by stopping the processing of target task data and pushing the target task description information to the target message queue, the loss of target task processing data caused by the system restart can be avoided. Even if the system restarts, the target task will not be missed, thereby achieving a smooth system restart.

[0134] Figure 10A flowchart illustrating a processing task according to an embodiment of this application is shown. The following is in conjunction with... Figure 10 Introducing the specific workflow for handling tasks:

[0135] 1. First, retrieve the task description information from the queue.

[0136] 2. Next, load the task data to retrieve the task data corresponding to the task description information from storage.

[0137] 3. Next, read the configuration, perform version detection based on the configuration, and select the task processor indicated in the configuration to process the task data when the version detection is passed, so as to perform task processing.

[0138] 4. During task processing, tasks can be created by splitting them into subtasks. The set of subtask IDs obtained from the split is recorded, and all subtask IDs are added back to the queue. Business processing is performed on each subtask. Using the parent task ID as the key, the processing result of each subtask is saved to a hash data structure, and the IDs of completed subtasks are added to a set data structure. It is determined whether the number of completed subtasks is consistent with the number of subtasks obtained from the split. If they are consistent, the parent task is considered complete, and the completion function of the parent task is called. The processing result of the parent task can be obtained by summarizing the processing results of the subtasks.

[0139] 5. Based on the configuration, task callbacks can be performed, which can output the parent task processing result or the parent task processing status, and finally the task is completed.

[0140] 6. Repeat the above steps. If an exception occurs (returns an error) during any step, the task description information will be put back into the queue to retry the task. The number of retries can also be configured.

[0141] In summary, the task processing method provided in this application embodiment implements task processing based on Redis's List / ZSet data structures. During task processing, it achieves functions such as task configurability, priority-based task execution, real-time tasks, delayed tasks, task failure retries, and parent-child task splitting management. This allows for efficient and flexible dynamic adjustment of task processing methods. Furthermore, the task processing system upon which this method is based supports concurrent operations, reducing the impact between tasks. Moreover, the entire system is no longer limited to single-machine capabilities; it can be deployed on multiple machines simultaneously, breaking the bottleneck of single-machine performance. Leveraging the capabilities of server machine clusters, it achieves efficient task processing, allowing for easy scaling up and down of servers. The system also supports smooth restarts, ensuring availability and maintainability, thus improving overall system task processing performance and enhancing user experience. The task processing method provided in this application embodiment can process over 20 million tasks per day on average, with a peak daily processing capacity exceeding 55 million tasks.

[0142] The following describes an embodiment of the apparatus described in this application, which can be used to execute the task processing method described above in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the task processing method described above in this application.

[0143] Figure 11 A block diagram of a task processing apparatus according to an embodiment of this application is shown;

[0144] Reference Figure 11 As shown, a task processing apparatus 1100 according to an embodiment of this application includes: an information retrieval unit 1110, an acquisition unit 1120, and a processing unit 1130. The information retrieval unit 1110 is used to retrieve target task description information from a target message queue of a message queue set. At any given time, only one task consumer among multiple task consumers can retrieve task description information from the message queues of the message queue set, allowing the multiple task consumers to retrieve task description information stored in each message queue of the message queue set concurrently. The acquisition unit 1120 is used to acquire target task data and configuration information corresponding to the target task description information. The target task data and configuration information are set when the target task is created, and the target task description information is pushed to the target message queue in the message queue set according to the configuration information. The processing unit 1130 is used to process the target task data according to the configuration information when it is determined that the versions of the target task description information and the target task data are consistent, in order to process the target task.

[0145] In some embodiments of this application, based on the foregoing scheme, the processing unit 1130 is configured to: split the target task data and the target task description information respectively to obtain subtask data and subtask description information corresponding to multiple subtasks respectively; push each of the subtask description information to the target message queue; pull one subtask description information from the target message queue each time, and process the subtask data corresponding to the subtask description information to obtain the subtask processing result; collect the subtask description information and subtask processing result corresponding to the processed subtask data; if the number of collected subtask description information is consistent with the number of subtask description information obtained by splitting, then output the target task processing result or the processing status of the target task according to the configuration information, wherein the target task processing result is generated based on the collected subtask processing results.

[0146] In some embodiments of this application, based on the foregoing scheme, the processing unit 1130 is configured to: if the configuration information indicates that the target task is an editable task, compare the first version number in the target task description information with the second version number in the target task data; if the first version number in the target task description information is consistent with the second version number in the target task data, determine that the versions of the target task description information and the target task data are consistent.

[0147] In some embodiments of this application, based on the foregoing scheme, after processing the target task data according to the configuration information to process the target task, the processing unit 1130 is further configured to: if an abnormality occurs during the processing of the target task data, push the target task description information to the target message queue to reprocess the target task until the number of times the target task is processed reaches the number of retries included in the configuration information.

[0148] In some embodiments of this application, based on the aforementioned scheme, each message queue in the message queue set has a corresponding priority, and the information retrieval unit 1110 is configured to: poll each message queue in the message queue set from high to low priority in turn, so as to attempt to retrieve task description information from each message queue in turn; attempt to retrieve task description information from the target message queue, so as to retrieve the target task description information, wherein the attempt to retrieve task description information from the target message queue is performed when polling the target message queue in the message queue set and determining that the target message queue contains task description information.

[0149] In some embodiments of this application, based on the aforementioned scheme, the information retrieval unit 1110 is configured to: if task description information is retrieved from the message queue, then re-polling each message queue in the message queue set according to priority from high to low.

[0150] In some embodiments of this application, based on the foregoing scheme, the data structure of the target message queue is a list in a specified non-relational database.

[0151] In some embodiments of this application, based on the foregoing scheme, before retrieving the target task description information from the target message queue of the message queue set, the information retrieval unit 1110 is further configured to: sort the task description information in the delay queue according to the score associated with each task description information in ascending order, wherein the data structure of the delay queue is an ordered set in the specified non-relational database, and the score is the planned execution time of the task corresponding to the task description information; whenever the score associated with the task description information at the top of the delay queue is consistent with the current time, retrieve the task description information at the top of the delay queue; after retrieving the target task description information from the delay queue, move the target task description information to the target message queue.

[0152] In some embodiments of this application, based on the foregoing scheme, the processing unit 1130 is configured to: select the processor object indicated by the configuration information to process the target task data.

[0153] Figure 12 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0154] It should be noted that, Figure 12 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0155] like Figure 12As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1203. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. An Input / Output (I / O) interface 1205 is also connected to bus 1204.

[0156] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0157] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0158] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0159] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0160] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0161] In another aspect, this application also provides a task processing system, which includes:

[0162] The task producer is used to create target tasks based on configuration information, store target task data corresponding to the target tasks, and obtain target task description information based on the target task data.

[0163] The message queue set includes multiple message queues for storing task description information, and the multiple message queues include the target message queue;

[0164] Multiple task consumers can execute the methods described in the above embodiments by accessing task producers and message queue sets.

[0165] In one aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0166] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0167] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0168] It is understood that in the specific implementation of this application, data related to task processing is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0169] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

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

Claims

1. A task processing method, characterized in that, The method includes: The task description information in the delay queue is sorted in ascending order according to the score associated with each task description information. The data structure of the delay queue is an ordered set in a specified non-relational database, and the score is the planned execution time of the task corresponding to the task description information. Whenever the score associated with the task description information at the front of the delay queue matches the current time, the task description information at the front of the delay queue is retrieved. After retrieving the target task description information from the delay queue, the target task description information is moved to the target message queue; The target task description information is pulled from the target message queue of the message queue set. At any given time, only one of the multiple task consumers can pull the task description information from the message queue of the message queue set, so that the task description information stored in each message queue of the message queue set is pulled by the multiple task consumers in a concurrent manner; the data structure of the target message queue is a list in the specified non-relational database. Obtain target task data and configuration information corresponding to the target task description information. The target task data and configuration information are set when the target task is created. The target task description information is pushed to the target message queue in the message queue set according to the configuration information. When it is determined from the configuration information that the versions of the target task description information and the target task data are consistent, the target task data is processed according to the configuration information to process the target task.

2. The task processing method according to claim 1, characterized in that, The step of processing the target task data according to the configuration information to process the target task includes: The target task data and the target task description information are split into subtask data and subtask description information corresponding to multiple subtasks respectively. The description information of each subtask is pushed to the target message queue; Each time, a subtask description information is retrieved from the target message queue, and the subtask data corresponding to the subtask description information is processed to obtain the subtask processing result; Collect subtask description information and subtask processing results corresponding to the processed subtask data; If the number of subtask descriptions collected is consistent with the number of subtask descriptions obtained from the splitting, then the target task processing result or the processing status of the target task is output as a callback according to the configuration information, wherein the target task processing result is generated based on the collected subtask processing results.

3. The task processing method according to claim 1, characterized in that, The step of determining that the versions of the target task description information and the target task data are consistent based on the configuration information includes: If the configuration information indicates that the target task is an editable task, then the first version number in the target task description information is compared with the second version number in the target task data; If the first version number in the target task description information is consistent with the second version number in the target task data, then it is determined that the versions of the target task description information and the target task data are consistent.

4. The task processing method according to claim 1, characterized in that, After processing the target task data according to the configuration information to process the target task, the method further includes: If an anomaly occurs during the processing of the target task data, the target task description information is pushed to the target message queue to reprocess the target task until the number of processing attempts for the target task reaches the number of retries included in the configuration information.

5. The task processing method according to claim 1, characterized in that, Each message queue in the message queue set has a corresponding priority. Retrieving target task description information from the target message queue in the message queue set includes: The message queues in the message queue set are polled in descending order of priority to try to retrieve task description information from each message queue in turn. An attempt is made to retrieve task description information from the target message queue, wherein the attempt to retrieve task description information from the target message queue is performed when polling the target message queue in the message queue set and determining that the target message queue contains task description information.

6. The task processing method according to claim 5, characterized in that, The step of polling each message queue in the message queue set in descending order of priority includes: If task description information is retrieved from the message queue, then the message queues in the message queue set are re-polled in descending order of priority.

7. The task processing method according to any one of claims 1-6, characterized in that, The step of processing the target task data according to the configuration information includes: Select the processor object indicated by the configuration information to process the target task data.

8. A task processing system, characterized in that, The system includes: The task producer is used to create target tasks according to configuration information, store target task data corresponding to the target tasks, and obtain target task description information according to the target task data. A message queue set, including multiple message queues for storing task description information, wherein the multiple message queues include a target message queue; Multiple task consumers, which can perform the task processing method as described in any one of claims 1 to 7 by accessing the task producer and the message queue set.

9. A task processing device, characterized in that, The device includes: The information retrieval unit is used to retrieve target task description information from the target message queue of the message queue set. At any given time, only one task consumer among multiple task consumers can retrieve task description information from the message queues of the message queue set, so that the task description information stored in each message queue of the message queue set is retrieved concurrently by the multiple task consumers. The data structure of the target message queue is a list in a specified non-relational database. The acquisition unit is used to acquire target task data and configuration information corresponding to the target task description information. The target task data and configuration information are set when the target task is created, and the target task description information is pushed to the target message queue in the message queue set according to the configuration information. The processing unit is configured to process the target task data according to the configuration information when it is determined that the versions of the target task description information and the target task data are consistent, so as to process the target task. Before retrieving the target task description information from the target message queue of the message queue set, the information retrieval unit is further configured to: sort the task description information in the delay queue according to the scores associated with each task description information in ascending order, wherein the data structure of the delay queue is an ordered set in the specified non-relational database, and the score is the planned execution time of the task corresponding to the task description information; whenever the score associated with the task description information at the top of the delay queue is consistent with the current time, retrieve the task description information at the top of the delay queue; after retrieving the target task description information from the delay queue, move the target task description information to the target message queue.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the task processing method as described in any one of claims 1 to 7.

11. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the task processing method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, wherein a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions to cause the computer device to perform the task processing method as described in any one of claims 1 to 7.

Images