CN116578401A - Task scheduling method, system and storage medium - Google Patents

Abstract

The application provides a task scheduling method, a task scheduling system and a storage medium, and relates to the field of financial science and technology or other fields. The method comprises the following steps: determining a path of a shell script for executing the target task based on information contained in a configuration file in response to an execution operation of the target task, wherein the path of the shell script is used for describing a position of the shell script stored on a remote machine, and the information in the configuration file comprises relevant information of the shell script on the stored remote machine; generating a scheduling instruction facing to the target task, wherein the scheduling instruction carries an identification of the target task, an identification of an executor executing the target task and a path of the shell script; and sending a scheduling instruction to the executor, and receiving a task execution result returned by the executor aiming at the target task. Based on the method, the shell scripts stored in the remote machine are continuously used under the distributed scheduling architecture, so that the distributed architecture is beneficial to the use of the distributed architecture in a task scheduling scene.

Description

Task scheduling method, system and storage medium

Technical Field

The present application relates to the field of financial science and technology or other related fields, and in particular, to a task scheduling method, system and storage medium.

Background

With the continuous popularization of distributed architecture, more and more fields or scenarios introduce distributed architecture, such as task scheduling scenarios. Aiming at a task scheduling scene, the current task scheduling architecture is a centralized scheduling architecture, namely, a scheduler schedules executors of all tasks in a centralized way, and the executors of all tasks trigger jobs of corresponding tasks. Under the centralized scheduling architecture, a large number of shell scripts for performing functions such as task processing and the like are stored in a remote machine, wherein a dispatcher calls the shell scripts through java codes, and an executor triggers a job of a corresponding task according to the shell scripts, namely, executes the task.

Based on the above background, when the cloud access to the distributed scheduling architecture, how to make the distributed scheduling architecture support the scheduling of the shell scripts stored in the remote machine is important.

Disclosure of Invention

The application provides a task scheduling method, a task scheduling system and a storage medium,

in a first aspect, the present application provides a task scheduling method, which is applied to a scheduler in a task scheduling system, the task scheduling system further including an executor, the method including: determining a path of a shell script for executing the target task based on information contained in a configuration file in response to an execution operation of the target task, wherein the path of the shell script is used for describing a position of the shell script stored on a remote machine, and the information in the configuration file comprises relevant information of the shell script on the stored remote machine; generating a scheduling instruction facing to the target task, wherein the scheduling instruction carries an identification of the target task, an identification of an executor executing the target task and a path of the shell script; and sending a scheduling instruction to the executor, and receiving a task execution result returned by the executor aiming at the target task.

Through the method, the scheduler can schedule the executor to call the shell script from the remote machine based on the scheduling instruction, and then trigger the corresponding task according to the shell script. The shell script stored on the remote machine can be continuously used under the distributed scheduling architecture, and the use of the distributed architecture in a task scheduling scene is facilitated.

In a second aspect, the present application provides a task scheduling method, which is applied to an executor in a task scheduling system, the task scheduling system further includes a scheduler, and the method includes: receiving a scheduling instruction from a scheduler; calling the shell script from a remote machine based on a path of the shell script for executing the target task carried in the scheduling instruction so as to execute the target task and obtain a task execution result aiming at the target task; and sending the task execution result to the scheduler.

Through the method, the executor calls the shell script from the remote machine based on the scheduling instruction received from the scheduler, and then triggers the corresponding task according to the shell script. The shell script stored on the remote machine can be continuously used under the distributed scheduling architecture, and the use of the distributed architecture in a task scheduling scene is facilitated.

With reference to the second aspect, in some possible implementations of the second aspect, the scheduling instruction further carries a user name or a key, and after receiving the scheduling instruction from the scheduler, the method further includes: checking the scheduling instruction to determine whether the type of the target task is the task type which the executor should process, and determining whether the user has authority; after the verification is passed, the scheduling instruction is analyzed, and a path of the shell script is obtained.

With reference to the first aspect, in some possible implementations of the first aspect, the executor is embedded in a java service integration (java business integration, JBI) container in a software development kit (software development kit, SDK), and calls a shell script from a remote machine based on a path of the shell script, including: and transmitting the character string for calling the shell script into the java code through the Java.runtime tool class encapsulated by the SDK, and calling the shell script from the remote machine in a mode of calling a command of the Linux operating system.

With reference to the second aspect, in some possible implementations of the second aspect, the target task includes a timing task or a dependent task.

In a third aspect, the present application provides a scheduler in a task scheduling system, comprising: the determining module is used for responding to the execution operation of the target task, determining a path of a shell script for executing the target task based on information contained in a configuration file, wherein the path of the shell script is used for describing the storage position of the shell script on a remote machine, the information in the configuration file comprises the relevant information of the shell script on the stored remote machine, and the remote machine comprises a virtual machine or a physical machine; the instruction generation module is used for generating a scheduling instruction facing the target task, wherein the scheduling instruction carries the identification of the target task, the identification of an executor executing the target task and the path of the shell script; and the receiving and transmitting module is used for sending a scheduling instruction to the executor and receiving a task execution result returned by the executor aiming at the target task.

In a fourth aspect, the present application provides an actuator in a task scheduling system, including: the receiving and transmitting module is used for receiving a scheduling instruction from a scheduler in the task scheduling system; the calling module is used for calling the shell script from the remote machine based on the path of the shell script for executing the target task carried in the scheduling instruction so as to execute the target task and obtain a task execution result aiming at the target task; the receiving and transmitting module is also used for sending the task execution result to the scheduler.

With reference to the fourth aspect, in some possible implementation manners of the fourth aspect, the executor further includes a processing module, where the processing module is configured to check the scheduling instruction to determine whether a type of the target task is a task type that should be processed by the executor, and determine whether the user has a right.

With reference to the fourth aspect, in some possible implementations of the fourth aspect, the calling module may be configured to transmit, through an SDK encapsulated java. Run tool class, a string that invokes the shell script into the java code, and invoke the shell script from the remote machine in a command that invokes the Linux operating system.

In a fifth aspect, the present application provides a task scheduling system, including a scheduler and an executor, wherein: the scheduler is for performing the method of the first aspect and any one of the possible implementations of the first aspect; the actuator is arranged to perform the method of the second aspect and any one of the possible implementations of the second aspect.

In a sixth aspect, the application provides a computer readable storage medium comprising a computer program which, when run on a computer, causes the computer to implement the method of the first aspect and any one of the possible implementations of the first aspect, and the method of the second aspect and any one of the possible implementations of the second aspect.

In a seventh aspect, the present application provides a computer program product comprising: a computer program (which may also be referred to as code, or instructions) which, when executed, causes a computer to perform the method of the first aspect and any one of the possible implementations of the first aspect, and the method of the second aspect and any one of the possible implementations of the second aspect.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

FIG. 1 is a schematic diagram of a task scheduling system according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a task scheduling method provided by an embodiment of the present application;

FIG. 3 is a schematic block diagram of an actuator provided by an embodiment of the present application;

FIG. 4 is a schematic block diagram of a scheduler provided by an embodiment of the present application;

FIG. 5 is another schematic block diagram of an actuator provided by an embodiment of the present application;

fig. 6 is another schematic block diagram of a scheduler provided by an embodiment of the present application.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

The objects, technical solutions and advantages of the embodiments of the present application will be more apparent, and the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It will be apparent that the described embodiments are some, but not all, embodiments of the application.

Thus, the following detailed description of the embodiments of the application, as presented in the figures, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

In embodiments of the present application, the terms "first," "second," and the like are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. Furthermore, the term "include" and any variations thereof are intended to cover a non-exclusive inclusion.

It should be noted that the task scheduling method, the task scheduling system and the storage medium provided by the application can be used in the field of financial science and technology. But also can be used in any field except the field of financial science and technology. The application field of the task scheduling method, the task scheduling system and the storage medium provided by the application is not limited.

Fig. 1 is a schematic diagram of a task scheduling system provided by the present application. As shown in FIG. 1, in a task scheduling system, a scheduler and an executor may be included, where one scheduler may be used to schedule multiple executors to execute tasks.

The task scheduling architecture currently in common use is a centralized scheduling architecture, i.e., the scheduler and the executor are deployed on the same machine. Under the architecture of centralized scheduling, a common scheduling mode is to store a shell script for triggering tasks in a remote machine such as a virtual machine or a physical machine, the dispatcher calls the shell script from the remote machine through a java code, and an executor triggers corresponding tasks according to the shell script.

With the continuous popularization of the distributed architecture, more and more fields or scenes begin to be introduced into the distributed architecture, which also includes task scheduling scenes. Under the distributed scheduling architecture, the shell script called by the scheduler from the remote machine through the java code cannot directly trigger the corresponding task by the executor. This means that after migrating from the centralized scheduling architecture to the distributed scheduling architecture, the shell scripts stored in the remote machine cannot be directly used, which brings inconvenience to the distributed task scheduling.

In view of this, the present application provides a task scheduling method, in which an executor invokes a shell script from a remote machine based on a scheduling instruction received from a scheduler, and then triggers a corresponding task according to the shell script. Based on the method, the shell script stored on the remote machine can be continuously used under the distributed scheduling architecture, and the use of the distributed architecture in a task scheduling scene is facilitated.

Fig. 2 is a schematic flowchart of a task scheduling method according to an embodiment of the present application, where the task scheduling method may be applied to a task scheduling system, and the task scheduling system may be the task scheduling system shown in fig. 1, and the task scheduling system includes a scheduler and an executor, and the task scheduling method includes steps 201 to 205, and each step in the task scheduling method is described in detail below.

In step 201, the scheduler determines a path of a shell script for executing a target task based on information contained in the configuration file in response to an execution operation on the target task.

The path of the shell script can be used for describing the storage position of the shell script on the remote machine, and the information contained in the configuration file comprises the relevant information of the shell script on the stored remote machine.

The shell script is a file stored on a remote machine, the file stores the steps of tasks executed by the script in sequence, the shell script can be configured with execution rights, and complex tasks can be realized by combining shell control sentences.

The task type of the target task may be a timing task or a dependent task, which is not limited in the present application. The timed task refers to a task that triggers execution at a preset time, and the dependent task refers to a task that triggers execution depending on execution of other tasks.

The shell script may be stored on a remote machine, which may be a virtual machine or a physical machine, which is not limited in this regard. The physical machine is a complete computer system which is real and has the function of a complete hardware system and operates in a complete isolation environment; the virtual machine is a virtual computer system image with complete hardware system functions that runs in a completely isolated environment through software emulation.

The shell script is stored on the remote machine under a directory whose path can be pre-written into a configuration file. Information in the configuration file about the shell script including at least one task on the stock of remote machines. The related information includes a path of at least one shell script of the task stored on the remote machine, and may also include other information, for example, an identification of the task, an identification of an executor executing the task, a task type, and the like.

The configuration file may be, for example, an excel file in which relevant information of a shell script of at least one task is recorded.

As an example, the content recorded in the excel file is shown in table 1.

TABLE 1

Identification of tasks	Shell script storage path	Actuator identification	Task type
				Task 1	Path 1	Actuator 1	Timed tasks
Task 2	Path 2	Actuator 2	Dependent tasks

Task 1 is a timing task, the scheduler monitors the execution operation of task 1 at the preset time for executing task 1, and determines the storage path of the shell script for executing task 1 in the excel file in response to the execution operation.

In step 202, the scheduler generates a scheduling instruction for the target task, where the scheduling instruction may carry an identifier of the target task, an identifier of an executor executing the target task, a path of the shell script, a task type, and the like.

The scheduler generates scheduling instructions for the target tasks based on the information in the configuration file.

For example, the target task is task 1, and the generated scheduling instruction may be "task 1; path 1; an actuator 1; timing tasks).

In step 203, the scheduler sends scheduling instructions to the executor, which receives scheduling instructions from the scheduler.

Optionally, the scheduling instruction may further include a user name and a key, and the executor may verify the scheduling instruction after receiving the scheduling instruction.

The checking may include determining whether the type of the target task is a task type that should be processed by the executor based on the task type in the scheduling instruction.

In an example, the task type in the scheduling instruction is a timing task, and the task type to be processed by the executor is the timing task, and the verification is passed.

For another example, the task type in the scheduling instruction is a timed task, the task type that the executor should process is a dependent task, and the verification is not passed.

In addition, the target task can be configured by the user, and the authority of the configuration task of different users is different, and the scheduling instruction can further comprise the user name and the key of the user configuring the target task. The way of checking may therefore also include determining whether the user has the right to schedule the actuator based on the user name and the key in the scheduling instruction.

If one of the above checks is not passed, the executor may not execute the scheduling instruction.

If the above checks are all passed, the executor may parse the scheduling instruction and obtain a path of the shell script from the scheduling instruction.

In step 204, the executor invokes the shell script from the remote machine based on the path of the shell script to execute the target task, and obtains a task execution result for the target task.

After obtaining the path of the shell script, the executor can call the shell script from the directory corresponding to the remote machine based on the path. And further executing the target task to obtain a task execution result aiming at the target task, wherein the task execution result of the target task can comprise successful execution or failure execution.

Alternatively, the executor may be embedded in the JBI container in the SDK manner, so the manner of calling the shell script may be that the string calling the shell script is transmitted to the java code through the java. Run tool class encapsulated by the SDK, and the shell script is called from the remote machine in the manner of calling the command of the Linux operating system.

In step 205, the executor sends the task execution result to the scheduler.

The task execution result can be used for triggering other dependent tasks, and the task scheduling method can be executed again under the condition that other dependent tasks are triggered.

Based on the task scheduling method, the executor calls the shell script from the remote machine based on the scheduling instruction received from the scheduler, and then triggers the corresponding task according to the shell script. The shell script stored on the remote machine can be continuously used under the distributed scheduling architecture, and the use of the distributed architecture in a task scheduling scene is facilitated.

Fig. 3 is a schematic block diagram of an actuator provided by an embodiment of the present application. The actuator 300 may include a transceiver module 310 and a call module 320.

The transceiver module 310 is configured to receive, from a scheduler in the task scheduling system, a scheduling instruction, where the scheduling instruction is a scheduling instruction for a target task generated by the scheduler in response to an execution operation on the target task based on information included in a configuration file, where the scheduling instruction carries an identifier of the target task, an identifier of an executor, and a path of a shell script for executing the target task, where the path of the shell script is used to describe a location where the shell script is stored on a remote machine, and information included in the configuration file includes information related to the shell script on an inventory of remote machines.

And the calling module 320 is configured to call the shell script from the remote machine based on the path of the shell script, so as to execute the target task, and obtain a task execution result for the target task.

The transceiver module 310 is further configured to send the task execution result to the scheduler.

Optionally, the executor 300 may further include a processing module 330, where the processing module 330 may be configured to check the scheduling instruction to determine whether the type of the target task is a task type that the executor should process, and determine whether the user has permission.

Alternatively, the calling module 320 may be configured to transfer, through the tool class of java. Runtime encapsulated by the SDK, a string for calling the shell script into the java code, and call the shell script from the remote machine in a manner of calling a command of the Linux operating system.

Fig. 4 is a schematic block diagram of a scheduler provided by an embodiment of the present application. The scheduler 400 may include a determination module 410, an instruction generation module 420, and a transceiver module 430.

The determining module 410 is configured to determine, in response to an execution operation on a target task, a path of a shell script for executing the target task based on information included in a configuration file, where the path of the shell script is used to describe a location of the shell script stored on a remote machine, and the information in the configuration file includes information about the shell script on the remote machine stored in an inventory.

The instruction generating module 420 is configured to generate a scheduling instruction for a target task, where the scheduling instruction carries an identifier of the target task, an identifier of an executor used for executing the target task in the task scheduling system, and a path of the shell script.

And the transceiver module 430 is configured to send a scheduling instruction to an executor to obtain a task execution result for the target task, where the executor is configured to call the shell script from the remote machine based on the path of the shell script, so as to execute the target task, and obtain the task execution result.

Fig. 5 is another schematic block diagram of an actuator provided by an embodiment of the present application. As shown in fig. 5, the actuator 500 may include at least one processor 510 for implementing the functions of the actuator in the method provided by the present application. Reference is made specifically to the detailed description in the method examples, and details are not described here.

The actuator 500 may also include a memory 520 for storing program instructions and/or data. Memory 520 is coupled to processor 510. The coupling in the present application is an indirect coupling or communication connection between devices, units or modules, which may be in electrical, mechanical or other form for the exchange of information between the devices, units or modules. Processor 510 may operate in conjunction with memory 520. Processor 510 may execute program instructions stored in memory 520. At least one of the at least one memory may be included in the processor.

The actuator 500 may also include a communication interface 530 for communicating with other devices via a transmission medium, such that the apparatus for use in the actuator 500 may communicate with other devices. The communication interface 530 may be, for example, a transceiver, an interface, a bus, a circuit, or a device capable of implementing a transceiver function. Processor 510 may receive and transmit data and/or information using communication interface 530 and may be used to implement the task scheduling method described in the corresponding embodiment of fig. 2.

The specific connection medium between the processor 510, the memory 520, and the communication interface 530 is not limited in the present application. The present application is illustrated in fig. 5 as being coupled between processor 510, memory 520, and communication interface 530 via bus 540. The connection of the bus 540 to other components is shown by a bold line in fig. 5, and is merely illustrative and not limiting. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one thick line is shown in fig. 5, but not only one bus or one type of bus.

Fig. 6 is another schematic block diagram of a scheduler provided by an embodiment of the present application. As shown in fig. 5, the scheduler 600 may include at least one processor 610 for implementing the functions of the executor in the method provided by the present application. Reference is made specifically to the detailed description in the method examples, and details are not described here.

The scheduler 600 may also include a memory 620 for storing program instructions and/or data. The memory 620 is coupled to the processor 610. The coupling in the present application is an indirect coupling or communication connection between devices, units or modules, which may be in electrical, mechanical or other form for the exchange of information between the devices, units or modules. The processor 610 may operate in conjunction with the memory 620. The processor 610 may execute program instructions stored in the memory 620. At least one of the at least one memory may be included in the processor.

The scheduler 600 may also include a communication interface 630 for communicating with other devices over a transmission medium so that the apparatus for use in the scheduler 600 may communicate with other devices. The communication interface 630 may be, for example, a transceiver, an interface, a bus, a circuit, or a device capable of implementing a transceiver function. The processor 610 may utilize the communication interface 630 to transceive data and/or information and is used to implement the task scheduling method described in the corresponding embodiment of fig. 2.

The specific connection medium between the processor 610, the memory 620, and the communication interface 630 is not limited to the above-described one in the present application. The present application is illustrated in fig. 6 as being coupled between processor 610, memory 620, and communication interface 630 via bus 640. Bus 640 is shown in bold in fig. 6, and the manner in which other components are connected is illustrated schematically and not by way of limitation. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one thick line is shown in fig. 6, but not only one bus or one type of bus.

In the embodiment of the present application, the processor may be a general purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or execute the methods, steps and logic blocks disclosed in the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of a method disclosed in connection with the present application may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in a processor for execution.

According to the method provided by the application, the application further provides a computer readable storage medium, wherein the computer readable storage medium stores program code, when the program code runs on a computer, the program code causes the computer to execute the task scheduling method described in the corresponding embodiment of fig. 2.

According to the method provided by the application, the application also provides a computer program product comprising: computer program code. The computer program code, when run on a computer, causes the computer to perform the task scheduling method described in the corresponding embodiment of fig. 2.

The technical scheme provided by the application can be realized in whole or in part by software, hardware, firmware or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, a network device, a terminal device, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired, such as coaxial cable, fiber optic, digital subscriber line (digital subscriber line, DSL), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium such as digital video disc (digital video disc, DVD), or a semiconductor medium, etc.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. A task scheduling method, characterized in that it is applied to a scheduler in a task scheduling system, the task scheduling system further comprising an executor, the task scheduling method comprising:

determining a path of a shell script for executing a target task based on information contained in a configuration file in response to an execution operation of the target task, wherein the path of the shell script is used for describing a position of the shell script stored on a remote machine, and the information in the configuration file comprises relevant information of the shell script stored on the remote machine;

generating a scheduling instruction facing the target task, wherein the scheduling instruction carries an identification of the target task, an identification of an executor executing the target task and a path of the shell script;

and sending the scheduling instruction to the executor, and receiving a task execution result returned by the executor aiming at the target task.

2. A task scheduling method, characterized in that the method is applied to an executor in a task scheduling system, the task scheduling system further comprises a scheduler, and the task scheduling method comprises:

receiving a scheduling instruction from the scheduler;

calling the shell script from a remote machine based on a path of the shell script for executing the target task carried in the scheduling instruction so as to execute the target task and obtain a task execution result aiming at the target task;

and sending the task execution result to the scheduler.

3. The task scheduling method according to claim 2, wherein the scheduling instruction further carries a user name or a key, and the method further comprises, after receiving the scheduling instruction from the scheduler:

checking the scheduling instruction to determine whether the type of the target task is the task type which the executor should process, and determining whether the user has permission;

and after the verification is passed, analyzing the scheduling instruction to obtain the path of the shell script.

4. A task scheduling method according to claim 2 or 3, wherein the executor is embedded in a java service integration JBI container in the form of a software development kit SDK, and the calling the shell script from the remote machine based on the path of the shell script comprises:

and transmitting the character string for calling the shell script to a java code through a Java tool class encapsulated by the SDK, and calling the shell script from the remote machine in a mode of calling a command of a Linux operating system.

5. A task scheduling method according to claim 2 or 3 wherein the target task comprises a timed task or a dependent task.

6. A scheduler in a task scheduling system, comprising:

a determining module, configured to determine, in response to an execution operation on a target task, a path of a shell script for executing the target task based on information included in a configuration file, where the path of the shell script is used to describe a location where the shell script is stored on a remote machine, information in the configuration file includes information about a stock of shell scripts on the remote machine, and the remote machine includes a virtual machine or a physical machine;

the instruction generation module is used for generating a scheduling instruction facing the target task, wherein the scheduling instruction carries an identification of the target task, an identification of an executor executing the target task and a path of the shell script;

and the receiving and transmitting module is used for sending the scheduling instruction to the executor and receiving a task execution result returned by the executor aiming at the target task.

7. An actuator in a task scheduling system, comprising:

the receiving and transmitting module is used for receiving a scheduling instruction from a scheduler in the task scheduling system;

the calling module is used for calling the shell script based on the path of the shell script for executing the target task carried in the scheduling instruction so as to execute the target task and obtain a task execution result aiming at the target task;

the receiving and transmitting module is further configured to send the task execution result to the scheduler.

8. A task scheduling system comprising a scheduler and an actuator, wherein:

the scheduler is configured to perform the task scheduling method according to claim 1;

the executor is configured to execute the task scheduling method according to any one of claims 2 to 5.

9. A computer readable storage medium comprising a computer program which, when run on a computer, causes the computer to perform the task scheduling method of any one of claims 1 to 5.

10. A computer program product comprising a computer program which, when run, causes a computer to perform the task scheduling method of any one of claims 1 to 5.