Server and interrupt-based task scheduling method

Abstract

The embodiment of the present application provides a server and an interrupt-based task scheduling method, which acquires multiple tasks and stores them in a cache queue; when the stored tasks reach a preset length, the priorities of the multiple tasks in the cache queue are calculated according to the number of subtasks in the task, and each task is processed according to the priority; when the task processing time meets the preset reset duration, and the first task currently being processed has not yet processed the last subtask, it is determined whether there is a subtask being processed, if not, the interruption position is recorded, if so, the processing is waited for to be completed, and the interruption position is recorded; the task is re-acquired to the cache queue, and the priority of the first task is recalculated. The server of the present application suspends the processing of the current task at regular intervals, and refills the tasks in the cache queue and calculates the priority to ensure that high-priority tasks are processed first, and at the same time, the interrupted tasks can update the calculation priority based on their processing progress.

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to a server and an interrupt-based task scheduling method. Background Art

[0002] Based on the limited resources of the server, when there are multiple tasks to use these resources, due to the limited nature of resources, tasks must be selected according to certain principles to occupy resources, which is scheduling. At present, the commonly used scheduling methods are first-come-first-served and short-job-first. First-come-first-served means processing in the order of tasks, and short-job-first means scheduling according to the length of tasks. The shorter the task, the higher the priority. For tasks that need to update data efficiently on the corresponding platform, if the first-come-first-served scheduling method is adopted, if the first-come-first-served task A has a large amount of data and takes a long time to process, it will delay the subsequent task B that needs to be updated urgently. If the short-job-first scheduling method is adopted, if there are other tasks shorter than task A coming in, task A needs to be shelved all the time, which will eventually delay the update. Therefore, the above scheduling method is likely to affect the processing progress of tasks, making data updates untimely. Summary of the invention

[0003] The present application provides a server and an interrupt-based task scheduling method to solve the technical problem that the scheduling method in the prior art easily affects the processing progress of the task, resulting in untimely data update.

[0004] In a first aspect, the present application provides a server, wherein the server is configured to:

[0005] Acquire multiple tasks and store them in a cache queue, wherein the task includes multiple subtasks, and the subtask is the smallest unit of task processing;

[0006] When the tasks stored in the cache queue reach a preset length, the priorities of the multiple tasks in the cache queue are calculated according to the number of subtasks in the task, and the tasks in the cache queue are processed in descending order according to the priorities;

[0007] When the task processing time meets the preset reset time and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the interruption position is recorded; if there is a subtask being processed, the processing of the subtask is waited for to be completed and the interruption position is recorded;

[0008] The task is retrieved and stored in the cache queue, and the number of subtasks in the first task is updated using the interruption position to update the priority of the first task.

[0009] In a second aspect, the present application provides an interrupt-based task scheduling method, the method comprising:

[0010] Acquire multiple tasks and store them in a cache queue, wherein the task includes multiple subtasks, and the subtask is the smallest unit of task processing;

[0011] When the tasks stored in the cache queue reach a preset length, the priorities of the multiple tasks in the cache queue are calculated according to the number of subtasks in the task, and the tasks in the cache queue are processed in descending order according to the priorities;

[0012] When the task processing time meets the preset reset time and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the interruption position is recorded; if there is a subtask being processed, the processing of the subtask is waited for to be completed and the interruption position is recorded;

[0013] The task is retrieved and stored in the cache queue, and the number of subtasks in the first task is updated using the interruption position to update the priority of the first task.

[0014] Compared with the prior art, the beneficial effects of this application are:

[0015] The present application provides a server and an interrupt-based task scheduling method, wherein the length of a cache queue is preconfigured in the server, and tasks to be processed are obtained and stored in the cache queue. When the tasks cached in the cache queue reach a preset length, the task acquisition is stopped. The tasks stored in the cache queue can calculate their corresponding priorities according to the number of subtasks contained in each task, and are sorted and processed in order of priority from high to low. When the server starts to process tasks in the cache queue, it starts to record the task processing time. When the time meets the preset reset time, it determines whether there is a task being processed at this time. When the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the interrupt position is recorded. If there is a subtask being processed, the processing of the subtask is completed and the interrupt position is recorded. The interrupt position is used to mark the number of subtasks that have been processed in the first task currently being processed. The server re-pulls the task to the cache queue and calculates the priority of the task when the preset length is pulled to the maximum, wherein the server updates the priority of the first task according to the recorded interrupt position. In this application, the server pauses processing the current task at regular intervals, and refills the cache queue with tasks that can be stored, and calculates the priorities of the tasks in the cache queue to ensure that high-priority tasks are processed first. At the same time, the interrupted tasks can update the calculation priority based on their processing progress to avoid being shelved, thereby achieving efficient processing of tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solution of the present application, the drawings required for use in the embodiments are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 exemplarily shows a schematic diagram of a scenario of media asset data scheduling according to some embodiments;

[0018] Figure 2 exemplarily shows a schematic diagram of the display effect of media asset data going online according to some embodiments;

[0019] Figure 3 exemplarily shows a timing diagram of media asset data scheduling according to some embodiments;

[0020] Figure 4 A flowchart of an interrupt-based task scheduling method according to some embodiments is exemplarily shown in FIG.

[0021] Figure 5 A framework diagram of media asset data acquisition according to some embodiments is exemplarily shown in FIG.

[0022] Figure 6 Another flowchart of the interrupt-based task scheduling method according to some embodiments is exemplarily shown in FIG.

[0023] Figure 7 exemplarily shows a timing diagram of interrupt-based task scheduling according to some embodiments. DETAILED DESCRIPTION

[0024] In order to make the purpose and implementation method of the present application clearer, the exemplary implementation method of the present application will be clearly and completely described below in conjunction with the drawings in the exemplary embodiments of the present application. Obviously, the described exemplary embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0025] It should be noted that the brief description of terms in this application is only for the convenience of understanding the embodiments described below, and is not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their ordinary and common meanings.

[0026] The terms "first", "second", "third", etc. in the specification and claims of this application and the above drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean to limit a specific order or sequence, unless otherwise noted. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances.

[0027] The terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device comprising a list of components is not necessarily limited to all the components expressly listed but may include other components not expressly listed or inherent to such product or device.

[0028] The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0029] Figure 1 FIG. 4 is a schematic diagram of a scenario of media asset data scheduling according to some embodiments. Figure 1 As shown, the film and television content displayed by the current display device 200 usually comes from multiple partners 400. The server 300 connects to the media data from different partners 400. After obtaining the media data, the server 300 needs to perform a series of operations such as cleaning, synchronizing, and putting the data online to display the data of the partner 400 on the display device 200. Figure 2 FIG. 4 is a schematic diagram showing the display effect of media asset data online according to some embodiments. Figure 2 The server 300 provides users with diversified and rich video content through the display device 200. For the server 300, it is necessary to efficiently update the media asset data of the partner 400 to the display device 200.

[0030] Figure 3 FIG. 4 shows an exemplary timing diagram of media asset data scheduling according to some embodiments. Figure 3 The overall process of task scheduling for the online scenario of media asset capture is introduced. The server 300 includes a capture network element, a storage network element, a database, a synchronization network element and other subsystems that are connected in communication. The server 300 realizes the processing of media asset data through the above components. Among them, each network element or subsystem can be deployed on one hardware device or on multiple hardware devices. As long as each subsystem or network element can access each other, the embodiment of the present application does not make specific restrictions on this. First, the capture network element obtains data in the data generation system. Here, the data generation system can be a subsystem in the server 300 or a third-party server. Then the capture network element controls the data to be sent to the storage network element in an orderly manner according to a certain scheduling method, and the storage network element then sends the data to the database for storage. Subsequently, the synchronization network element can obtain data from the database and send it to each subsystem, and each subsystem feeds the data back to the display device 200. Finally, the display device 200 displays the data.

[0031] At present, for the scheduling method of capturing media data in the network element, the first captured is first put online, also known as first come first served, that is, the media data captured by the server 300 first is updated to the display device 200 first. In this method, for example, the first media A is a cartoon with 20,000 episodes, and the later media B is a movie that needs to be put online on time at 8 o'clock. At this time, if the current throughput of the server is 200, that is, the amount of data processed per second is 200, then it takes at least 20,000 / 200=100 seconds to process the media A, so the media B needs to wait for nearly two minutes before it can be normally put online. Here, if there are multiple resources similar to the media A in front of the media B, it will greatly delay the online time of the media B. In addition, there is also a short job priority scheduling method for media data, that is, scheduling according to the length of the media data. Continuing with the above example, since the server has new media to be processed all the time, if there are media shorter than the media A coming in all the time, the media A needs to be shelved all the time. The above easy scheduling method makes the media resources update untimely, which reduces the user experience. In order to solve the above problem, an embodiment of the present application provides a server, which is configured to execute an interrupt-based task scheduling method.

[0032] In some embodiments, before performing task scheduling, the server 300 may pre-set the length of the cache queue, that is, the preset length, to limit the number of tasks to be processed in each round. Taking 30,000 as an example, the server 300 may control the cache queue to accommodate 30,000 data at a time.

[0033] In some embodiments, the server 300 may also pre-set a preset reset duration so that the server 300 may interrupt the progress of the current task processing at intervals of the preset reset duration, re-acquire the task to the cache queue, and calculate the priority of each task accordingly.

[0034] In some embodiments, the server 300 may also pre-set a preset waiting time, wherein the preset waiting time should be greater than the time required for the cache queue to store a task of a preset length. When the server 300 re-acquires a task to the cache queue, if the time to acquire the task is greater than the preset waiting time, but the number of tasks in the cache queue has not reached the preset length, the server 300 may no longer wait for acquisition and directly calculate the priority of each task already acquired in the cache queue.

[0035] The process of interrupt-based task scheduling is described below with reference to the accompanying drawings.

[0036] Figure 4 FIG. 4 is a flow chart showing an interrupt-based task scheduling method according to some embodiments. Figure 4 As shown, the interrupt-based task scheduling process is as follows:

[0037] S401: Acquire multiple tasks and store them in a cache queue, wherein the task includes multiple subtasks, and the subtask is the smallest unit of task processing.

[0038] In some embodiments, a media asset includes a media asset shell and a media asset episode, wherein the media asset shell includes information such as the title, media asset ID, total number of episodes, director, and tag, and the media asset episode includes information such as the specific number of episodes, duration, and definition of the episode. For example, media asset A, a fifty-six-episode TV series, includes a media asset shell and fifty-six media asset episodes, with a total of fifty-seven pieces of data. Here, if media asset A is regarded as a task, then the task contains fifty-seven subtasks, wherein each subtask can be regarded as the smallest unit of processing of media asset A.

[0039] In the related art, for media asset A in the above example, the entire task is a whole, and both its media asset shell and media asset subsets must be processed before the entire task is completed. This method takes a long time to process. If other media assets with higher priority that need to be launched on time are encountered, they must wait until media asset A is processed before processing can proceed, which can easily delay the timely launch of other media assets, thereby affecting user experience.

[0040] S402: When the tasks stored in the cache queue reach a preset length, the priorities of the multiple tasks in the cache queue are calculated according to the number of subtasks in the task, and the tasks in the cache queue are processed in descending order according to the priorities.

[0041] In some embodiments, when the tasks acquired by the server 300 reach the preset length of the cache queue, such as the preset length is 30,000, and the server 300 has acquired 30,000 pieces of data, the server 300 can terminate the acquisition of the tasks and calculate the priority of each task in the cache queue.

[0042] In some embodiments, if the tasks acquired by the server 300 have not reached a preset length and the task acquisition time meets the preset waiting time, the server 300 may no longer wait for acquisition and directly calculate the priority of each task acquired in the cache queue.

[0043] The following is a detailed introduction to the calculation process of task priority.

[0044] In some embodiments, when calculating the priority of a task, it is necessary to first obtain positively correlated parameters and negatively correlated parameters, wherein the positively correlated parameters include the playback parameters of the task, the release parameters obtained according to the release time of the task, and the source parameters obtained according to the task acquisition method; the negatively correlated parameters include the number of unprocessed subtasks in the task.

[0045] In some embodiments, for the source parameter (Source) of the task, the server 300 may set different source parameters for the media resources according to different ways of obtaining the media resources. In some embodiments, the server 300 has different docking methods with each partner 400, that is, the server 300 obtains the media resources from the partner 400 in different ways. Figure 5 FIG. 4 is an exemplary diagram of a framework diagram for obtaining media asset data according to some embodiments. Figure 5 As shown in the figure, the ways to obtain media resources include single operation capture, full pull, incremental pull, data push, and re-capture after task failure. The process of formulating source parameters for tasks according to the acquisition method is as follows: for single operation capture tasks, it means that this task is urgent and the operation manually triggers this task. It can be scored on a 5-point scale and can be set as 5 points; full pull tasks indicate routine daily inspections and can be set as 1 point. Incremental pull tasks and data push tasks are data that has been incrementally updated by partners and have a higher priority, which can be set as 3 points; re-capture after task failure indicates that the previous task failed and the data needs to be updated immediately, which can be set as 5 points. Therefore, the source parameters for tasks can be set according to the acquisition method, as shown in Table 1.

[0046] Table 1:

[0047] Data acquisition method Operation single capture Pull all Incremental pull Data push Recapture after mission failure Fraction 5 1 3 3 5

[0048] In some embodiments, the server 300 can obtain data from the partner 400 through the message channel Kafka and store the data in the cache queue. Here, data transmission storage includes but is not limited to the data generated by the Kafka interface pushed by the partner 400 to the server 300. Any data transmission form is acceptable. It should be noted that the media resources obtained here are not limited to the media resources provided by the partner, but can also be self-owned media resources.

[0049] In some embodiments, for the playing parameter (Play) of the task, the server 300 estimates by counting the number of playing users on the display device 200. Users can watch media assets through the display device 200, search and watch through historical records, and watch through the recommendations of the display device 200. The server 300 can count the above viewing behaviors and record the number of playing users of each media asset as the playing parameter.

[0050] In some embodiments, for the release parameter (Update) of the task, the server 300 can make an estimate according to the year, with the current year being 10 points, and the release parameter decreasing by one point for each previous year until it reaches 1, that is, 1 is the minimum. That is, the release parameter of the media asset released in 2022 is 10 points, the release parameter of the media asset released in 2021 is 9 points, and so on, until it reaches 1 point. For example, for TV series A that was just released in 2022, the current status is to update two episodes every night at 8 o'clock, while for TV series B in 2000, a field in its media asset data has changed and needs to be updated synchronously to the display device. It is obvious that the user's expectation for watching TV series A is higher than the expectation for watching TV series B.

[0051] In some embodiments, for the number of unprocessed subtasks in a task (diversityJ), for the first task that was interrupted in the previous round, the server 300 obtains the number of processed subtasks in the first task based on the recorded corresponding interruption position. The number of unprocessed subtasks in the first task is obtained by subtracting the original total number of subtasks in the first task from the number of processed subtasks. The original total number of subtasks in the first task is recorded as diversityA, and the number of processed subtasks is recorded as diversityC, then: diversityJ=diversityA-diversityC. Of course, for tasks that have not yet started processing, when calculating the priority, the negative correlation parameter is the original total number of subtasks in the task.

[0052] In some embodiments, the server 300 compares the product of the positive correlation parameter with the negative correlation parameter to obtain the priority of the task. Taking media asset a as an example, the calculation formula of the priority S(a) is expressed as:

[0053]

[0054] S403: When the task processing time meets the preset reset time and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, record the interruption position; if there is a subtask being processed, wait for the subtask to be processed to be completed and record the interruption position.

[0055] S404: Re-acquire the task and store it in the cache queue, and use the interruption position to update the number of subtasks in the first task to update the priority of the first task.

[0056] In some embodiments, after the server 300 calculates the priority of each task in the cache queue and sorts the tasks in descending order of priority, the server 300 starts task processing in sequence and starts monitoring task processing time.

[0057] In some embodiments, when the monitored task processing time reaches the preset reset duration, the server 300 checks whether there is a first task being processed. If there is no first task being processed, it means that a task may have just been processed and the next task has not yet been processed, or the tasks in the current cache queue have been processed. At this time, the server 300 can directly terminate the processing flow and re-acquire a new task to store in the cache queue. For ease of description, the task that the server 300 is processing when the task processing time reaches the preset reset duration is called the first task.

[0058] In some embodiments, when the monitored task processing time reaches the preset reset time, the server 300 determines that there is a first task currently being processed, and further the server 300 needs to determine whether the subtask in the first task currently being processed is the last subtask in the first task. If the last subtask in the first task is currently being processed, the server 300 controls the processing of the current subtask and does not record the interruption position. After the processing of the current subtask, that is, the processing of the first task, the server 300 re-acquires a new task and stores it in the cache queue.

[0059] In some embodiments, when the monitored task processing time reaches the preset reset time, the server 300 determines that the first task is currently being processed and the last subtask has not been processed. The server 300 further determines whether there is a subtask being processed. If there is no subtask being processed, it means that one subtask in the first task (not the last subtask) has just been processed and completed. The server 300 can directly record the interruption position and re-acquire a new task to store in the cache queue. If there is a subtask being processed (not the last subtask), the server 300 waits for the subtask to be processed, records the interruption position, and re-acquires a new task to store in the cache queue.

[0060] For example, when the task processing time reaches the preset reset time of 5 minutes, the server 300 determines that the 42th episode of TV series A (a total of 42 episodes) is being processed. At this time, the server 300 can control the processing of the 42nd episode to be completed, and then suspend the processing flow, and re-acquire new tasks to store in the cache queue. When the task processing time reaches the preset reset time of 5 minutes, the server 300 determines that the 20th episode of TV series A (a total of 42 episodes) is being processed. At this time, the server 300 can control the processing of the 20th episode to be completed, record the interruption position of the 20th episode, suspend the processing flow, and re-acquire new tasks to store in the cache queue. When using the interruption position to calculate the negative correlation parameter of TV series A, 42 episodes-20 episodes=22 episodes are used, and 22 is the negative correlation parameter of TV series A when updating the calculation priority.

[0061] In some embodiments, when the monitored task processing time reaches the preset reset time, the server 300 re-pulls the task and stores it in the cache queue. As mentioned above, if there is a first task that was interrupted in the previous round in the cache queue, when the cache queue is full of tasks again, the priority of the first task needs to be updated according to the interruption position. If there is no first task that was interrupted in the cache queue, but there are tasks whose priorities have been calculated in the previous round and have not yet been processed, the priorities of these tasks will not be re-calculated.

[0062] As described above, when the task processing time reaches the preset reset time, the server 300 determines whether to record the interruption position according to the situation of the currently processed task, and determines when to terminate the current processing flow and re-acquire a new task to the cache queue.

[0063] In some embodiments, the server 300 monitors the task processing time and detects in real time how much the current task processing time reaches the preset reset time, that is, determines how much of the preset reset time is left by the monitored task processing time. When the remaining time is the preset processing time and there is no subtask being processed, the server 300 calculates the actual processing time of the next subtask. The server 300 compares the preset processing time with the actual processing time. When the ratio is greater than or equal to the preset value, the server 300 controls the start of processing the next subtask, and after the next subtask is processed, the interruption position is recorded. If the ratio is less than the preset value, the server 300 controls the stop of processing the next subtask and records the interruption position.

[0064] For example, assuming that the preset processing time is 20 milliseconds, when there are 20 milliseconds left in the processing task time from the preset reset time, and a subtask is currently processed, the server 300 estimates the actual processing time of the next subtask, assuming that the actual processing time is 25 milliseconds. Assuming that the preset value is 60%, the server 300 compares 20 milliseconds with 25 milliseconds and obtains 80%, which means that the remaining preset processing time can enable the server 300 to complete 80% of the next task. At this time, the server 300 can control the next task to continue to be processed, and when the preset reset time is reached, the task is controlled to complete the remaining 20% ​​and then the processing flow is terminated. For another example, the server 300 estimates that the actual processing time of the next subtask is 35 milliseconds. The server 300 compares 20 milliseconds with 35 milliseconds and obtains 57%, which means that the remaining preset processing time can enable the server 300 to complete 57% of the next task. At this time, the server 300 can control to stop processing the next task, that is, terminate the processing flow.

[0065] The process of interrupt-based task scheduling is further described below with reference to the accompanying drawings.

[0066] Figure 6 Another flowchart of the interrupt-based task scheduling method according to some embodiments is exemplarily shown in FIG. Figure 6 As shown, the server 300 can pull data from the data generation system and store it in the cache queue. Here, the data generation system can refer to the third-party server of the partner, or it can be the server 300 itself. The server 300 determines whether the amount of data in the cache queue has reached the preset length. If it has reached the preset length, the priority of each data in the cache queue can be calculated. If the preset length has not been reached, and the time for obtaining the data has reached the preset waiting time, the server 300 can no longer obtain data and directly calculate the priority of each data in the cache queue. Of course, if the preset length has not been reached, the server 300 can continue to obtain data. After calculating the priority of each data in the cache queue, the server 300 can clean, synchronize and process online in the order of the priority of each data in the queue from high to low. While processing the data, the server 300 monitors the data processing time. If the data processing time reaches the preset reset time, it is determined whether there is data being processed. If there is data being processed, the server 300 controls the processing of the data currently being processed. After the processing is completed, the server 300 decides whether to save the interrupt position according to whether the data is the last data in the current task. If the interruption position is saved, when the server 300 pulls all the data into the cache queue again, the priority of the data whose processing is interrupted is updated according to the interruption position.

[0067] Figure 7 FIG. 4 illustrates an example of a timing diagram of interrupt-based task scheduling according to some embodiments. Figure 7In order to realize the task scheduling process based on interruption, the capture network element is provided with a data pulling module, a cache queue, a processing module, an up / down module and a judgment module. Among them, the data pulling module can receive the data pushed by the data generation system, and can also actively obtain data from the data generation system. The data pulling module puts the obtained data into the cache queue. When the pulled data meets the preset length of the cache queue, or the data pulling data reaches the preset waiting time, the processing module calculates the priority of the data in the cache queue, and processes it in order from high to low according to the calculated data priority. The online module cleans and stores it in this order, that is, sends it to the storage network element. During the data processing process, the judgment module determines whether the preset reset time is met, or whether the cache queue is empty. If the preset reset time is met, the judgment module sends a message notification to the processing module, so that the processing module controls the stopping of data storage, and obtains the interruption position, which is used to update the priority of the data being interrupted. At the same time, the processing module sends a message notification to the data pulling module, so that the data pulling module re-acquires the data to the preset length of the cache queue. If the cache queue is empty, the judgment module can directly send a message notification to the data pulling module to enable the data pulling module to reacquire data to the preset length of the cache queue. After the data pulling module re-pulls data to the cache queue, the above process is repeated.

[0068] In this application, the server pauses processing the current task at regular intervals, and refills the cache queue with tasks that can be stored, and calculates the priorities of the tasks in the cache queue to ensure that high-priority tasks are processed first. At the same time, the interrupted tasks can update the calculation priority based on their processing progress to avoid being shelved, thereby achieving efficient processing of tasks.

[0069] Corresponding to the above method, the present application also provides a task scheduling method based on interruption, the method comprising: the server 300 acquires multiple tasks and stores them in a cache queue, wherein the task contains multiple subtasks, and the subtask is the smallest unit of task processing. When the tasks stored in the cache queue reach a preset length, the server 300 calculates the priority of the multiple tasks in the cache queue according to the number of subtasks in the task, and processes each task in the cache queue in order from high to low according to the priority. When the task processing time meets the preset reset time length and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the server 300 records the interruption position, and if there is a subtask being processed, the server 300 waits for the subtask to be processed and records the interruption position. The server 300 re-acquires the task and stores it in the cache queue, and uses the interruption position to update the number of subtasks in the first task to update the priority of the first task.

[0070] In some embodiments, when acquiring multiple tasks and storing them in a cache queue, the method further includes: if the tasks stored in the cache queue do not reach a preset length and the task acquisition time meets a preset waiting time, the server 300 calculates the priority of the multiple tasks in the cache queue.

[0071] Since the above embodiments are all described by citing and combining with other embodiments, different embodiments have the same parts, and the same and similar parts between the embodiments in this specification can be referred to each other. No further detailed description is given here.

[0072] It should be noted that, in this specification, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a circuit structure, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such circuit structure, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the circuit structure, article or device including the element.

[0073] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the disclosure of the invention herein. The present application is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present application and include common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the content of the claims.

[0074] The above implementation modes of the present application do not constitute a limitation on the protection scope of the present application.

Claims

1. A server, characterized in that: The server is configured to: Acquire multiple tasks and store them in a cache queue, wherein the task includes multiple subtasks, and the subtask is the smallest unit of task processing; When the tasks stored in the cache queue reach a preset length, positively correlated parameters and negatively correlated parameters used in calculating the priority are obtained, wherein the positively correlated parameters include the playback parameters of the task, the screening parameters obtained according to the screening time of the task, and the source parameters obtained according to the task acquisition method, and the negatively correlated parameters include the number of unprocessed subtasks in the task; Compare the product of the positive correlation parameter with the negative correlation parameter to obtain the priority of the task; Processing each task in the cache queue in order of priority from high to low; When the task processing time meets the preset reset time and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the interruption position is recorded; if there is a subtask being processed, the processing of the subtask is waited for to be completed and the interruption position is recorded; The task is retrieved and stored in the cache queue, and the number of subtasks in the first task is updated using the interruption position to update the priority of the first task.

2. The server according to claim 1, characterized in that: When acquiring multiple tasks to store in the cache queue, the server is further configured to: If the tasks stored in the cache queue do not reach a preset length, and the task acquisition time satisfies a preset waiting time, the priorities of the multiple tasks in the cache queue are calculated.

3. The server according to claim 1, characterized in that: In the step of recording the interruption position when the task processing time meets the preset reset time and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the server is configured to: Monitoring the task processing time, and when the preset processing time is less than the preset reset time and there is no subtask being processed currently, calculating the actual processing time of the next subtask; When the ratio of the preset processing time to the actual processing time is greater than or equal to a preset value, starting to process the next subtask, and after the next subtask is processed, recording the interruption position; When the ratio of the preset processing time to the actual processing time is less than the preset value, the processing of the next subtask is stopped and the interruption position is recorded.

4. The server according to claim 1, characterized in that: In the step of obtaining the negative correlation parameter, the server is configured to: Acquire the number of subtasks in the first task that have been processed according to the interruption position; The number of unprocessed subtasks in the first task is obtained by subtracting the original total number of subtasks in the first task from the number of processed subtasks.

5. The server according to claim 1, characterized in that: The server is also configured to: When the task processing time does not meet the preset reset time length and the cache queue is empty, the task is retrieved and stored in the cache queue.

6. The server according to claim 1, characterized in that: The server is also configured to: When the task processing time meets the preset reset time and the task currently being processed is the last subtask in the first task, control the processing of the last subtask in the first task; After the last subtask in the first task is processed, the interruption position is not recorded, and the task is retrieved and stored in the cache queue.

7. The server according to claim 1, characterized in that: After the re-acquisition task is stored in the cache queue, the server is further configured to: The tasks in the cache queue whose priorities have been calculated and whose processing has not yet started are controlled not to recalculate their priorities.

8. A task scheduling method based on interruption, characterized in that: The method comprises: Acquire multiple tasks and store them in a cache queue, wherein the task includes multiple subtasks, and the subtask is the smallest unit of task processing; When the tasks stored in the cache queue reach a preset length, positively correlated parameters and negatively correlated parameters used in calculating the priority are obtained, wherein the positively correlated parameters include the playback parameters of the task, the screening parameters obtained according to the screening time of the task, and the source parameters obtained according to the task acquisition method, and the negatively correlated parameters include the number of unprocessed subtasks in the task; Compare the product of the positive correlation parameter with the negative correlation parameter to obtain the priority of the task; process each task in the cache queue in descending order of the priority; When the task processing time meets the preset reset time and the first task currently being processed has not yet processed the last subtask, if there is no subtask being processed, the interruption position is recorded; if there is a subtask being processed, the processing of the subtask is waited for to be completed and the interruption position is recorded; The task is retrieved and stored in the cache queue, and the number of subtasks in the first task is updated using the interruption position to update the priority of the first task.

9. The interrupt-based task scheduling method according to claim 8, characterized in that: When acquiring multiple tasks and storing them in the cache queue, the method further includes: If the tasks stored in the cache queue do not reach a preset length, and the task acquisition time satisfies a preset waiting time, the priorities of the multiple tasks in the cache queue are calculated.

Images