Task scheduling method, system and device, and storage medium

Abstract

The present disclosure relates to the technical field of Internet. Disclosed are a task scheduling method, system and device, and a storage medium. The task scheduling method comprises: receiving a task creation request sent by a first application, wherein the task creation request is used for indicating a second application to be called by the first application, and a delay duration, and the delay duration represents a duration for which the second application is called in a delayed manner when the second application is called in a delayed manner; on the basis of the task creation request, creating and storing a calling task for the second application; and when the storage duration of the calling task reaches the delay duration, executing the calling task to call the second application.

Description

Task scheduling method, system, device and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on October 30, 2023, with application number 202311423066.7 and invention name “Task Scheduling Method, System, Device and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present disclosure relates to the field of Internet technology, and in particular to a task scheduling method, system, device, and storage medium. Background Art

[0004] With technological advancements, the need for deferred calls has emerged in asynchronous call scenarios. A deferred call means that when Application A generates a call request for Application B, the call to Application B is not executed immediately but delayed for a period of time. This deferred call is widely used in scenarios such as payment timeout cancellation and scheduled message delivery. For example, suppose Application B has a message delivery function. Application A generates a scheduled message at 10:00 AM that needs to be sent to the user at 10:30 AM. Application A can generate a call request for Application B at 10:00 AM to send the message through Application B. However, since the message is not sent to the user until 10:30 AM, the call to Application B is not immediately executed after the call request is generated. Instead, the call to Application B must wait until 10:30 AM to send the message. This process is known as a deferred call.

[0005] Currently, the deferred call feature is usually implemented using MQ (Message Queue) methods. However, this method has limitations on the duration of the deferred call, for example, the maximum deferred call duration is only 7 days, which cannot meet the deferred call requirements in many business scenarios.

[0006] Summary of the Invention

[0007] In view of this, embodiments of the present disclosure provide a task scheduling method, a task scheduling system, an electronic device, and a computer-readable storage medium, which can solve the problem of time limitation during delayed calls.

[0008] In one aspect, the present disclosure provides a task scheduling method, the method comprising:

[0009] receiving a task creation request sent by a first application, the task creation request being used to indicate a second application to be called by the first application and a delay duration, the delay duration representing a length of time the second application is delayed in calling the second application;

[0010] Creating and saving a calling task for the second application based on the task creation request;

[0011] When the storage duration of the calling task reaches the delay duration, the calling task is executed to call the second application.

[0012] Another aspect of the present disclosure provides a task scheduling system, the system comprising:

[0013] a request receiving module, configured to receive a task creation request sent by a first application, the task creation request being used to indicate a second application to be called by the first application and a delay duration, the delay duration representing a length of time the second application is delayed in calling the second application;

[0014] A task creation module, configured to create and save a calling task for the second application based on the task creation request;

[0015] The task execution module is used to execute the calling task to call the second application when the storage time of the calling task reaches the delay time.

[0016] On the other hand, the present disclosure further provides a computer-readable storage medium, which is used to store a computer program. When the computer program is executed by a processor, the method described above is implemented.

[0017] On the other hand, the present disclosure further provides an electronic device, which includes a processor and a storage device, wherein the storage device is used to store a computer program, and when the computer program is executed by the processor, the method described above is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The features and advantages of the present disclosure will be more clearly understood by referring to the accompanying drawings, which are schematic and should not be construed as limiting the present disclosure in any way. In the accompanying drawings:

[0019] FIG1 shows a schematic diagram of calls between different applications in some technologies;

[0020] FIG2 shows a schematic diagram of a task management platform provided by an embodiment of the present application;

[0021] FIG3 shows a flowchart of a task scheduling method provided by an embodiment of the present application;

[0022] FIG4 shows a schematic diagram of a task management platform provided by another embodiment of the present application;

[0023] FIG5 shows a schematic diagram of a task queue and a message queue provided by an embodiment of the present application;

[0024] FIG6 shows a schematic diagram of calls between different applications provided by an embodiment of the present application;

[0025] FIG7 shows a module diagram of a task scheduling system provided by an embodiment of the present application;

[0026] FIG8 shows a schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0027] To make the purpose, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of the present disclosure.

[0028] In the technical solutions of some embodiments of the present application, based on the task creation request sent by the first application, a calling task for the second application is created and saved, and when the saving time of the calling task reaches the delay time, the calling task is executed to call the second application. By uniformly monitoring and managing the creation, saving time and execution of the calling task, it is possible to implement a delayed call for the second application, while also avoiding the problem of the maximum storage period of the message queue in some technologies. That is, in the solution of the present application, the saving time of the calling task may not be restricted by the maximum storage period, and further, in the task creation request sent by the first application, the delay time may be set according to actual needs, thereby solving the problem of limited time during delayed calling and meeting the delayed calling needs in more business scenarios.

[0029] Referring to FIG1 , a schematic diagram of calls between different applications in some technologies is shown. In FIG1 , when the first application 12 needs to call the second application 13, the first application 12 can generate a first call message for the second application 13 and place the first call message into the storage container 11. The storage container 11 may already store a message queue consisting of multiple second call messages. The second call message may be generated by the first application 12 or another application before the first call message is generated. The first call message may be queued after the second call message. As the call messages in the message queue are consumed, the first application 12 can call the second application 13.

[0030] Furthermore, through the message queue, delayed calls between applications can also be realized. Specifically, in some technical solutions, the storage container 11 in Figure 1 may include multiple message queues. Each message queue may correspond to a different duration of delayed calls. For example, the call message in message queue A may be a message that needs to be consumed after 10 minutes, and the call message in message queue B may be a message that needs to be consumed after 20 minutes. If the first application 12 needs to delay calling the second application 13 by 10 minutes, the generated first call message can be placed in the message queue A, so as to realize the delayed call of the second application 13. In other technical solutions, the storage container 11 in Figure 1 may include only one message queue, but each call message has a corresponding duration for which the call needs to be delayed. Each call message in the message queue can be checked regularly through a timed task to consume each call message on time.

[0031] However, in the technology shown in Figure 1, the call message in the message queue has a maximum retention period (e.g., 7 days or 3 days). After this maximum retention period, the call message in the message queue will be deleted. Therefore, the duration of the deferred call cannot exceed this maximum retention period. This greatly limits the duration of the deferred call and cannot meet the deferred call requirements in more business scenarios. For example, it is impossible to implement a scenario where the deferred call duration is six months.

[0032] In view of this, the present application provides a task scheduling method that can solve the problem of limited duration during delayed calls. The task calling method can be applied to a task management platform. Please refer to Figure 2, which is a schematic diagram of a task management platform 21 provided for an embodiment of the present application. In Figure 2, the task management platform 21 can communicate with the first application and the second application, and is integrated with program code and storage containers. Among them, when the program code is running, the task scheduling method of the present application can be implemented to manage and execute the calling tasks between the first application and the second application. The storage container can be used to save the data generated during the execution of the method. Storage containers include but are not limited to databases, memories, caches, etc. At least some storage containers can support persistent storage of data.

[0033] Based on the above description, please refer to Figure 3, which is a flowchart of a task scheduling method provided by an embodiment of the present application. In Figure 3, the task scheduling method includes:

[0034] Step S31 : receiving a task creation request sent by a first application, where the task creation request indicates a second application to be called by the first application and a delay duration, where the delay duration represents the length of time the second application is delayed in calling the second application.

[0035] Specifically, the first application and the second application can be functional modules divided according to business functions. For example, the first application can be a special effects module that creates special effects for video files, and the second application can be an audit module that audits video files. Because different applications have different business functions, there will be cases where different applications call each other. For example, when the first application creates special effects for a video file, it can first call the second application for auditing, and then proceed with the special effects creation after the audit is passed.

[0036] In this embodiment, when a first application needs to call a second application, the first application does not need to generate a call message for the second application and place the call message in a message queue. Instead, the first application can directly send a task creation request to the task management platform 21, indicating the second application to be called and the delay duration in the task creation request. The task management platform 21 can manage the call between the first application and the second application based on the task creation request.

[0037] Step S32: Based on the task creation request, create and save a calling task for the second application.

[0038] Specifically, a call task can be created based on the communication protocol between the first and second applications. For example, if the first and second applications communicate based on the HTTP protocol, an HTTP call task can be created based on the domain name and path associated with the HTTP protocol. If the first and second applications communicate based on the RPC protocol, an RPC call task can be created based on the PSM (Protocol State Machine), IDL (Interface Description Language) file, method name, and other information associated with the RPC protocol.

[0039] The task management platform 21 may save the generated calling task into a storage container and monitor the storage time of the calling task.

[0040] Step S33: When the storage duration of the calling task reaches the delay duration, the calling task is executed to call the second application.

[0041] It is understood that since the call task is stored in the storage container of the task management platform 21, and at least some storage containers support persistent storage of the call task, there is no need to limit the storage period of the call task in the storage container, and therefore, there is no need to limit the delay period. In this way, during the process of delaying the call of the second application, the delay period of the second application can be set as needed without being subject to a time limit.

[0042] In the technical solutions of some embodiments of the present application, based on the task creation request sent by the first application, a calling task for the second application is created and saved, and when the saving time of the calling task reaches the delay time, the calling task is executed to call the second application. By uniformly monitoring and managing the creation, saving time and execution of the calling task, it is possible to implement a delayed call for the second application, while also avoiding the problem of the maximum storage period of the message queue in some technologies. That is, in the solution of the present application, the saving time of the calling task may not be restricted by the maximum storage period, and further, in the task creation request sent by the first application, the delay time may be set according to actual needs, thereby solving the problem of limited time during delayed calling and meeting the delayed calling needs in more business scenarios.

[0043] The solution of this application is further described below.

[0044] In some embodiments, the second application may include multiple functional interfaces. Different functional interfaces can be used to implement different functions. When the first application calls the second application, it actually calls one or more functional interfaces provided by the second application. Therefore, the task creation request sent by the first application can be used to indicate the target functional interface to be called by the first application, as well as the interface information required when calling the target functional interface. Specifically, the interface information can further include basic interface information and interface parameter values ​​that need to be passed in when calling the target functional interface, where:

[0045] Basic interface information refers to the unchanging information of the target functional interface. That is, when calling the target functional interface multiple times, the basic interface information used for each call remains the same. Specifically, for a target functional interface based on the HTTP protocol, the basic interface information may include the domain name and path corresponding to the target functional interface; for a target functional interface based on the RPC protocol, the basic interface information may include the corresponding PSM, IDL file, method name, etc.

[0046] The interface parameter values ​​may be the values ​​of the various interface parameters determined by the first application based on the actual business scenario each time the first application calls the target functional interface. Interface parameter values ​​are allowed to vary. For example, the interface parameter values ​​for the first call to the target functional interface may be different from the interface parameter values ​​for the second call to the target functional interface.

[0047] Based on the task creation request sent by the first application, the task management platform 21 may create a calling task for the target functional interface of the second application.

[0048] In some embodiments, considering that the basic interface information of each functional interface is essentially unchanged, the basic interface information of each functional interface can be saved in advance to the task management platform 21 before the task management platform 21 receives the task creation request. In this way, the task creation request sent by the first application does not need to include the basic interface information, thereby reducing the amount of information transmitted.

[0049] This completes the description of the functional interface call.

[0050] In some embodiments, it is considered that there may be multiple different versions of the second application in the actual production test environment, and the first application usually calls one of the versions of the second application. In view of this, when there are multiple different versions of the second application, the task creation request can also be used to indicate the version identifier of the second application to be called by the first application. When the task management platform 21 creates and saves the calling task for the second application, it can use the version identifier indicated by the task creation request to identify the calling task, so that when calling the second application, the second application corresponding to the version identifier is called. Among them, the version identifier may include but is not limited to the domain name, IP address, version number, etc. of the environment where the second application is located. In this way, different versions of the second application can be isolated to prevent calling the wrong version of the second application.

[0051] This completes the description of version isolation of the second application.

[0052] Referring to FIG4 , a schematic diagram of a task management platform 41 is provided for another embodiment of the present application. In FIG4 , the task management platform 41 includes a first storage container and a second storage container. The first storage container supports timing management of call tasks that need to be executed within a preset time. The above-mentioned storage of call tasks for the second application may include:

[0053] If the delay time is not greater than the preset time, the calling task is saved in the first storage container;

[0054] If the delay duration is greater than the preset duration, the calling task is saved in the second storage container, and the calling task is moved from the second storage container to the first storage container at a specified time point, wherein the time difference between the time point when the calling task is executed and the specified time point is less than or equal to the preset duration.

[0055] Specifically, the difference between the first storage container and the second storage container is that they store call tasks for different durations. The first storage container supports storing call tasks for a preset duration. If a call task is stored in the first storage container for longer than the preset duration, it will be deleted. The second storage container supports persistent storage of call tasks.

[0056] In this embodiment, the calling task in the first storage container is stored in the form of a message queue (i.e., an MQ queue). As can be seen from the relevant description of FIG1 , since the messages in the message queue have a maximum storage period, and messages exceeding the maximum storage period will be deleted, the above-mentioned preset duration can be less than or equal to the maximum storage period. That is, if the delay duration of the calling task is within the maximum storage period, the calling task will be saved in the message queue of the first storage container, so that the calling task can be timed and managed through the message queue, thereby realizing the delayed calling of the second application.

[0057] For call tasks with a delay duration greater than a preset duration, the call task can first be saved in a second storage container. After the call task is saved in the second storage container, the call task can be monitored at multiple monitoring time points. If the time difference between a monitoring time point and the time point when the call task is executed is less than the preset duration, the monitoring time point can be used as a designated time point, and at the designated time point, the call task can be moved from the first storage container to the message queue of the second storage container. This allows for timing management of the call task through the message queue, thus enabling the delayed call of the second application. For example, assuming the maximum storage period for call tasks in the first storage container is 5 days, the preset duration can be 5 days. If the call task has a delay duration of 7 days, the call task can first be saved in the first storage container. After saving the call task in the first storage container, the call task can be monitored every half hour to determine whether the time difference between the monitoring time point and the time point when the call task is executed is less than or equal to 5 days. If so, the call task is moved from the second storage container to the first storage container. If not, the call task remains stored in the second storage container.

[0058] In the above embodiment, by setting two storage containers, the second application can be delayed with different delay durations, and the delay duration is not limited.

[0059] Furthermore, in the first storage container, if the call tasks for different applications are all placed in the same message queue, these call tasks may affect each other, resulting in delays in the calls of some applications. The delay here refers to the time when the application is actually called later than the time when the application should be called. For example, suppose that at 10 o'clock, 1 call task A for application A and 100 call tasks B for application B are generated (that is, application B has a call peak), and both call task A and call task B need to be executed at 10:30. If all 100 call tasks B are queued before call task A in the message queue, then call task A may be affected by call task B, resulting in call task A not being executed on time, for example, call task A is not executed until 10:31. Then the call to application A will be delayed by 1 minute.

[0060] In view of this, the first storage container can include multiple task queues, with different task queues used to store call tasks for different applications, and call tasks in different task queues can be executed in parallel. This can prevent call tasks for different applications from affecting each other and reduce the latency when the application is called.

[0061] Specifically, each task queue may include one or more message queues. For example, please refer to Figure 5, which is a schematic diagram of task queues and message queues provided for an embodiment of the present application. In Figure 5, task queue 1 may contain a calling task for application 1, message queue a1 may contain a calling task with a delay of 10 minutes for application 1, and message queue b1 may contain a calling task with a delay of 15 minutes for application 1. Task queue 2 may contain a calling task for application 2, message queue a2 may contain a calling task with a delay of 5 minutes for application 1, and message queue b2 may contain a calling task with a delay of 3 minutes for application 1. Of course, if calling tasks with different delay durations are saved in the same message queue, each calling task may include only one message queue.

[0062] In summary, the above-mentioned step of saving the calling task for the second application to the first storage container may include:

[0063] The calling task is saved in the task queue corresponding to the second application.

[0064] This completes the instructions for saving the calling task.

[0065] In some embodiments, after executing the calling task, the task scheduling method of the present application further includes:

[0066] If calling the second application fails, the task status of the calling task is set to a failed state, and the second application is called again; if calling the second application succeeds, the task status of the calling task can be set to a successful state.

[0067] In the event that calling the second application fails, the reliability of the application call can be ensured by re-calling the second application.

[0068] In some embodiments, the calling task may have a task level. The task level may represent the importance of the calling task. The more important the calling task is, the higher the task level may be. Calling tasks of different task levels may correspond to different re-call times. The above-mentioned re-calling of the second application may specifically include:

[0069] If the task level of the calling task is the first level, in the case where the second application is not successfully called, the second application is called again for a first preset number of times;

[0070] If the task level of the calling task is the second level, in the case where the second application is not successfully called, the second application is called again a second preset number of times;

[0071] The first level is lower than the second level, and the first preset number of times is less than the second preset number of times.

[0072] Specifically, in this embodiment, the first level can be a normal level, and the first preset number can be a limited number, such as 10 times or 50 times. That is, when the task level of the calling task is the first level, the maximum number of times the second application is re-called is a limited number. If the second application is still called unsuccessfully after the second application is called a limited number of times, the second application can be stopped from being called. Of course, if the second application is successfully called within the limited number of times, the second application will be stopped from being called after the second application is successfully called. For example, assuming that the second preset number is 50 times, then if the second application is still called unsuccessfully after the second application is called 50 times, the second application will be stopped from being called. Alternatively, within the range of 50 times, for example, if the second application is successfully called for the 25th time, the second application can be stopped from being called after the 25th call.

[0073] The second level may be a high priority level, and the second preset number may be an infinite number of times. That is, when the calling task is a high priority level, the second application may be called again an infinite number of times until the calling of the second application succeeds.

[0074] When the second application is successfully re-called, the task status of the calling task may be updated from a failed state to a successful state.

[0075] It is understandable that the task level of the calling task and the number of readjustments corresponding to each task level can be set according to actual conditions, and this application does not impose any restrictions on this.

[0076] In summary, when the task level of the calling task is relatively high, the second application can be re-called more times to ensure that the call to the second application can be as successful as possible; and when the task level of the calling task is relatively low, the second application can be re-called relatively fewer times to avoid resource waste.

[0077] In some embodiments, when the second application is re-called a third preset number of times and each call fails, an alarm message indicating the failure of calling the second application may be generated, and the alarm message may be displayed and / or sent.

[0078] Specifically, the alarm information can be displayed in the maintenance interface for maintenance personnel to view, or the alarm information can be sent to the maintenance personnel via SMS, email, etc., to prompt the maintenance personnel to investigate and resolve the cause of the failure to call the second application, ensure that the second application can be successfully called, and improve business reliability.

[0079] Specifically, the third preset number of times can be set according to actual needs, and this application does not impose any restrictions on this.

[0080] This concludes the explanation of the failure of the second application call.

[0081] With reference to FIG2 or FIG4, it can be understood that after the calls between different applications are managed by the task management platform, the task management platform can obtain the call data between different applications. Specifically, these call data may include but are not limited to the call tasks between different applications, the execution time of the call tasks, the task status of the call tasks (i.e., success or failure), etc. Therefore, after analyzing and summarizing the call data obtained by the task management platform, the call status between applications and the good or bad status of each called application can be analyzed. Specifically, the task scheduling method of the present application may also include:

[0082] The task information of executed call tasks is counted and displayed according to the specified time dimension. The task information includes one or more of the following:

[0083] The traffic used when executing the call task;

[0084] The success rate and / or failure rate of executing the called tasks;

[0085] The delay in executing the calling task.

[0086] Specifically, the specified time dimension can be hours, days, months, etc. For example, in units of hours, the task information of the call tasks executed every hour is counted and displayed.

[0087] In this way, the calling situation between applications can be analyzed through the displayed task information.

[0088] The solution of the present application is further described below in conjunction with a specific embodiment.

[0089] Please refer to Figure 6, which is a schematic diagram of calls between different applications provided by an embodiment of the present application. In Figure 6, calls between applications can be roughly divided into the following steps:

[0090] Step S611: register the application.

[0091] Specifically, the maintenance personnel can send an application registration request to the task management platform 61 through the client to register the second application to be called by the first application. The main purpose of application registration is to create an application identifier for the second application on the task management platform 61. The task management platform 61 can save the application identifier of the second application.

[0092] Step S612: calling task registration.

[0093] Specifically, the purpose of registering a call task is to pre-save certain non-changing information required for creating the call task in the task management platform 61. For example, the basic interface information of the target functional interface to be called by the first application can be pre-save in the task management platform 61. This eliminates the need to send this non-changing information when the first application sends a task creation request, thus reducing the amount of information transmitted. The task management platform 61 can obtain the non-changing information required to create the call task based on the registration information of the call task.

[0094] In this embodiment, the registration information for the calling task may include the application identifier of the second application, the customized task identifier of the calling task, the communication protocol (such as HTTP or RPC) required for calling the target functional interface, basic interface information of the target functional interface, and the task level of the calling task. The task identifier of the calling task may be the same as the interface identifier of the target functional interface.

[0095] The task management platform 61 can establish a corresponding relationship between the task identifier of the calling task and the registration information. In this way, when the calling task is subsequently created, the corresponding registration information can be obtained based on the task identifier of the calling task.

[0096] It should be noted that if the first application needs to call the same target functional interface of the second application multiple times, it is only necessary to register the calling task before calling the target functional interface for the first time, that is, there is no need to register the calling task when calling the target functional interface subsequently. In simple terms, when calling the target functional interface subsequently, the calling task can be created based on the calling task registered for the first time. For example, before the first application calls the functional interface A of the second application for the first time, a calling task with the task identifier AA can be registered on the task management platform, and the basic interface information of functional interface A, the communication protocol required to call functional interface A, the task level, etc. are used as the registration information of calling task AA. When calling functional interface A for the second or third time, there is no need to register the calling task again, and the calling task can be created directly based on the registration information of calling task AA.

[0097] Step S613: Create a calling task.

[0098] In this embodiment, the task creation request sent by the first application may include the task identifier of the calling task, the delay duration of the calling task, and the interface parameter values ​​required to be passed in when calling the target functional interface. After receiving the task creation request, the task management platform 61 may determine whether the calling task to be created is a registered calling task. If so, it may obtain the basic interface information required to call the target functional interface from the registration information of the calling task. Based on the basic interface information and the interface parameter values, it may create and save the calling task for the second application.

[0099] Specifically, the task management platform 21 can determine whether the target calling task identified by the task identifier in the task creation request exists in the registered calling tasks based on the task identifier in the task creation request. If so, the target function interface to be called, the basic interface information of the target function interface, the communication protocol required to call the target function interface, etc. are obtained from the registration information of the target calling task, and the calling task is created based on the interface parameter value in the task creation request and the basic interface information, communication protocol, etc. obtained from the registration information of the calling task. The principle of sending the interface parameter value through the first application can be found in the above-mentioned related description and will not be repeated here.

[0100] After the call task is created, if the delay duration of the call task is less than or equal to the preset duration, the call task can be saved in the message queue of the first storage container to delay the call of the second application. If the delay duration of the call task is less than or equal to the preset duration, the call task is saved in the second storage container so that the call task can be moved from the second storage container to the first storage container at a specified time.

[0101] Step S614: Execute the task. That is, execute the calling task based on the delay time to call the second application. The relevant principles can be found in the above description and will not be repeated here.

[0102] Step S615: manage tasks.

[0103] In this embodiment, management tasks may include the following aspects:

[0104] 1) A task record for the calling task is created in the second storage container. The task record includes, but is not limited to, the task status of the calling task (e.g., not executed, successfully executed, failed, etc.), the execution time of the calling task, the task level of the calling task, etc. After the calling task in the first storage container is completed, the task record in the second storage container can be updated. Because the second storage container can persist the task record, it facilitates the task management platform 61 to analyze and collect statistics on the calling tasks.

[0105] 2) monitoring the calling tasks stored in the second storage container so as to move the calling tasks from the second storage container to the first storage container at a specified time point;

[0106] 3) Managing the failed calling task so as to call the second application again according to the preset number of times corresponding to the task level of the calling task.

[0107] This completes the entire description of the task scheduling method of this application.

[0108] Corresponding to the element path repair method, the present application also provides a task scheduling system for a front-end page. Please refer to Figure 7, which is a module diagram of the task scheduling system provided by an embodiment of the present application. The task scheduling system includes:

[0109] a request receiving module, configured to receive a task creation request sent by a first application, the task creation request including a second application to be called by the first application and a delay duration, the delay duration representing a length of time the second application is delayed in calling the second application;

[0110] A task creation module, configured to create and save a calling task for the second application based on the task creation request;

[0111] The task execution module is used to execute the calling task to call the second application when the storage time of the calling task reaches the delay time.

[0112] Please refer to Figure 8, which is a schematic diagram of an electronic device provided in one embodiment of the present application. The electronic device includes a processor and a memory, wherein the memory is used to store a computer program. When the computer program is executed by the processor, the above method is implemented.

[0113] The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0114] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the methods described in the embodiments of the present invention. The processor executes the non-transitory software programs, instructions, and modules stored in the memory to perform various processor functions and data processing, thereby implementing the methods described in the aforementioned method embodiments.

[0115] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include a memory remotely located relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0116] One embodiment of the present application further provides a computer-readable storage medium, which is used to store a computer program. When the computer program is executed by a processor, the above method is implemented.

[0117] Although the embodiments of the present disclosure have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A task scheduling method, comprising: receiving a task creation request sent by a first application, wherein the task creation request is used to indicate a second application to be called by the first application and a delay duration, wherein the delay duration represents a delay duration for calling the second application when calling the second application in a delayed manner; Based on the task creation request, create and save a calling task for the second application; When the storage duration of the calling task reaches the delay duration, the calling task is executed to call the second application.

2. The method according to claim 1, wherein the second application includes a plurality of functional interfaces, and the task creation request is used to indicate a target functional interface to be called by the first application, and an interface parameter value to be passed in when calling the target functional interface; The creating and saving the calling task for the second application includes: Determine whether the calling task to be created is a registered calling task, and if so, obtain basic interface information required for calling the target function interface from the registration information of the calling task; Based on the basic interface information and the interface parameter value, a calling task for the second application is created and saved.

3. The method according to claim 1, wherein in the case where there are multiple different versions of the second application, the task creation request is further used to indicate a version identifier of the second application to be called by the first application; The creating and saving the calling task for the second application includes: The calling task is identified using the version identifier indicated by the task creation request, so that when the second application is called, the second application corresponding to the version identifier is called.

4. The method according to any one of claims 1 to 3, wherein the method is applied to a task management platform, the task management platform comprises a first storage container and a second storage container, and the first storage container supports timing management of calling tasks that need to be executed within a preset time period; Saving the calling task for the second application includes: If the delay duration is not greater than the preset duration, saving the calling task to the first storage container; If the delay duration is greater than the preset duration, the calling task is saved in the second storage container, and the calling task is moved from the second storage container to the first storage container at a specified time point, wherein the time difference between the time point when the calling task is executed and the specified time point is less than or equal to the preset duration.

5. The method according to claim 4, wherein the first storage container comprises a plurality of task queues, different task queues are used to store calling tasks for different applications, and calling tasks in different task queues are allowed to be executed in parallel; Saving the calling task for the second application to the first storage container includes: The calling task is saved in the task queue corresponding to the second application.

6. The method according to any one of claims 1 to 3, wherein after executing the calling task, the method further comprises: If calling the second application fails, the task state of the calling task is set to a failed state, and the second application is called again.

7. The method of claim 6, wherein the calling task has a task level; The re-calling the second application comprises: If the task level of the calling task is the first level, in the case where the second application is not successfully called, re-calling the second application a first preset number of times; If the task level of the calling task is the second level, in the case where the second application is not successfully called, re-calling the second application a second preset number of times; The first level is lower than the second level, and the first preset number of times is less than the second preset number of times.

8. The method of claim 6, wherein when the second application is re-called a third preset number of times and each call fails, the method further comprises: Generate alarm information indicating failure in calling the second application, and display and / or send the alarm information.

9. The method according to claim 6, wherein the method is applied to a task management platform, the task management platform is used to manage and execute calling tasks between different applications, and the method further comprises: The task information of the executed calling tasks is counted and displayed according to the specified time dimension, wherein the task information includes one or more of the following: The traffic used when executing the calling task; The success rate and / or failure rate of executing the called tasks; The delay in executing the calling task.

10. A task scheduling system, comprising: The request receiving module is used to receive a task creation request sent by a first application, wherein the task creation request is used to indicate a second application to be called by the first application and a delay time, wherein the delay time represents a delay in calling the second application. In the case of a delay in calling the second application, the length of time during which the calling of the second application is delayed; A task creation module, used for creating and saving a calling task for the second application based on the task creation request; The task execution module is used to execute the calling task to call the second application when the storage time of the calling task reaches the delay time.

11. A computer-readable storage medium, wherein the computer-readable storage medium is used to store a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

12. An electronic device comprising a processor and a storage device, wherein the storage device is used to store a computer program, and when the computer program is executed by the processor, the method according to any one of claims 1 to 9 is implemented.

Images