A task scheduling system and method for alleviating serverless computing cold start problem

Abstract

This invention discloses a task scheduling system and method to alleviate the cold start problem in serverless computing, comprising at least a container status tracking module, a request arrival prediction module, and a request scheduling module. The container status tracking module is implemented by deploying a container status tracker on the master node of the cluster, tracking container status based on container status information and scheduling decisions on worker nodes. The request arrival prediction module uses historical request data in the system and a time series prediction model to predict task arrival status within a future period, controlling the pre-creation or deletion of containers. The request scheduling module schedules newly arriving requests reasonably based on container status information and request arrival information, and controls the creation and deletion of containers. This method comprehensively considers the lifecycle status of containers and the prediction of future task request arrival status, assigning an optimal worker node to each task for processing, minimizing the overall average response time of the task, and has broad application value and promising prospects in the field of serverless computing.

Description

Technical Field

[0001] This invention belongs to the technical fields of cloud computing, computers and serverless computing, and mainly relates to a task scheduling system and method to alleviate the cold start problem of serverless computing. Background Technology

[0002] Serverless computing is gaining popularity due to container-based virtualization. In serverless computing, traditional monolithic applications are broken down into finer-grained functions, each serving a specific type of request by instantiating one or more specific containers on a worker. Containers are easy to deploy, resource-intensive, and have fast startup times, which gives serverless computing its advantages: no explicit configuration, pay-as-you-go, and elastic scaling, automatically increasing or decreasing the number of containers based on load. However, elastic scaling is not fast enough when the number of containers needs to be increased due to cold starts. Cold starts require multiple preparations before sending requests, including starting containers, initializing specific runtimes such as Python, and loading related function code. When elastic scaling is needed, these preparations significantly delay function execution.

[0003] To mitigate the response latency caused by cold start, the common solution in serverless computing is to keep containers that have completed their service requests running in memory for a fixed period (e.g., 15 or 20 minutes). This allows idle containers to be reused when new tasks arrive, avoiding a cold start. However, this strategy cannot adapt to dynamically changing serverless computing environments and frequently changing function call patterns.

[0004] To address the cold start problem in serverless computing, many researchers have proposed different solutions, but all of them have varying degrees of shortcomings.Oakes (E. Oakes, L. Yang, D. Zhou, et al. SOCK: Rapid Task Provisioning with Serverless-Optimized Containers. in: 2018 USENIX Annual Technical Conference. Boston, USA: USENIX, 2018. 57–70.) et al. optimized containers by removing two namespaces; Akkus (IE Akkus, R. Chen, I. Rimac, et al. SAND: Towards High-Performance Serverless Computing. in: 2018 USENIX Annual Technical Conference. Boston, USA: USENIX, 2018. 923–935.) et al. ran multiple functions in a single container; Pre-warming (Squeezing) The Milliseconds (https: / / medium.com / openwhisk / squeezing-the-milliseconds-howto-make-serverless-platforms-blazing-fast-aea0e9951bd0.) pre-creates containers with custom language runtimes, but these solutions weaken the isolation or flexibility of containers; AWS uses a lightweight virtual machine monitor (A. Agache, M. Brooker, A. Iordache, et al. Firecracker: Lightweight Virtualization for Serverless Applications. in: 17th USENIX Symposium on Networked Systems Design and Implementation. Santa Clara, USA: USENIX, 2020. 419–434.) to speed up virtual machine startup; however, virtual machines perform worse than containers; Cadden (J. Cadden, T. Unger, Y. Awad, et al. SEUSS: Rapid Serverless Deployment Using Environment Snapshots. Computer Research) Repository et al. (2019.) used snapshots to provide fast startup for unikernels; however, single-core is less flexible than containers, for example, it is difficult to debug applications in a unikernel.These sandboxing techniques may sacrifice isolation, flexibility, or performance, and cannot avoid delays caused by loading function code. Summary of the Invention

[0005] This invention addresses the problems in existing technologies by providing a task scheduling system and method to alleviate the cold start problem in serverless computing. It includes at least a container status tracking module, a request arrival prediction module, and a request scheduling module. The container status tracking module is implemented by deploying a container status tracker on the master node of the cluster, tracking container status based on container status information and scheduling decisions on worker nodes. The request arrival prediction module uses historical request data in the system and a time series prediction model to predict task arrival rates over a future period, controlling the pre-creation or deletion of containers. The request scheduling module, based on the container status information tracked by the container status tracking module and the request arrival information predicted by the request arrival prediction module, rationally schedules newly arriving requests and controls the creation and deletion of containers. This method comprehensively considers the container lifecycle status and the prediction of future task request arrival rates, assigning an optimal worker node to each task for processing and minimizing the overall average response time of the task.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is: a task scheduling system for alleviating the cold start problem of serverless computing, comprising at least a container status tracking module, a request arrival prediction module, and a request scheduling module;

[0007] The container status tracking module is implemented by deploying a container status tracker in the master node of the cluster, which tracks the container status based on the container status information and scheduling decisions on the worker nodes.

[0008] The request arrival prediction module: based on historical request data in the system, uses a time series prediction model to obtain the task arrival status within a future period, and controls the pre-creation or deletion of containers; the task arrival status includes at least the type of request arriving and the number of requests of a certain type arriving;

[0009] The request scheduling module: based on the container status information tracked by the container status tracking module and the request arrival information predicted by the request arrival prediction module, it reasonably schedules newly arriving requests and controls the creation and deletion of containers. The scheduling is carried out by polling and trying four methods: affinity worker nodes with available containers, non-affinity worker nodes with no available containers but sufficient computing resources to create new containers, non-affinity worker nodes with no available containers and insufficient computing resources to create new containers but which can release resources by evict other containers, and random worker nodes, to find the most suitable worker node to schedule and control the requests.

[0010] To achieve the above objectives, the present invention also adopts the following technical solution: a task scheduling method to alleviate the cold start problem of serverless computing, comprising the following steps:

[0011] S1. Create an empty container state information table using the tracker in the container state tracking module;

[0012] S2. Create an empty task arrival information table using the predictor in the request arrival prediction module;

[0013] S3. An empty task waiting queue is created by the decision-maker in the request scheduling module;

[0014] S4. When a new task arrives, the decision-maker queries the container status from the container status information table;

[0015] S5. If a worker node with an available container is found for the request, assign the request to that worker node and proceed to step S10.

[0016] S6. The decision-maker adds the task to the task waiting queue;

[0017] S7. The decision-maker selects a worker node for creating a new container for the request based on the container status information table and the task arrival information table, and sends a notification to that node;

[0018] S8. The worker node creates the corresponding container based on the notification received from the decision maker. After creation, the reporter on the worker node sends a report to the tracker in the scheduler.

[0019] S9. Once an available container becomes available during the creation process, the decision-maker immediately removes the task from the waiting queue;

[0020] S10. The decision-maker in the scheduler assigns tasks to worker nodes that have available containers;

[0021] S11. After the task is processed by the container, the result is returned to the scheduler. The tracker in the scheduler retrieves the result from two additional attributes, rt. running and rt paused Obtain the container status information on the working node and update the container status information table accordingly;

[0022] S12. The predictor reads the historical arrival data of the task from the cloud database, predicts the arrival information of the task in the next time slice, and updates the task arrival information table.

[0023] S13. Based on the task arrival information table, the scheduler sends eviction requests to worker nodes for containers that will not arrive within a future time period, and at the same time pre-creates containers that cannot meet the concurrent task requests.

[0024] S14. After a container is evicted, the reporter on the worker node sends a report to the tracker, and the tracker updates the container status information table accordingly based on the report.

[0025] Compared with existing technologies, this invention offers the following advantages: It discloses a task scheduling system and method to alleviate the cold start problem in serverless computing. By sensing the container lifecycle and predicting task arrival times over a future period, it reduces the frequency of cold starts and lowers the overall request response time. This invention records container status information on all worker nodes using a data structure, ensuring the scheduler can perceive the container lifecycle. Recording future task arrival information using a data structure ensures accurate strategies for container warm-up and deletion. This method comprehensively considers container availability, resource availability, and future task arrival times, accurately and rationally prioritizing task allocation to affinity worker nodes and optimizing container creation and deletion management, thereby reducing overall response latency when the cluster processes tasks. It has broad application value and promising prospects in the field of serverless computing. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the serverless computing cluster task scheduling structure in this invention;

[0027] Figure 2 This is a flowchart of the working node selection process in Embodiment 2 of the present invention;

[0028] Figure 3 This is a task scheduling flowchart in Embodiment 2 of the present invention;

[0029] Figure 4 This is a flowchart of the scheduling method for alleviating the cold start problem of serverless computing according to the present invention. Detailed Implementation

[0030] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0031] Example 1

[0032] A task scheduling system for mitigating the cold start problem in serverless computing includes at least a container state tracking module, a request arrival prediction module, and a request scheduling module; wherein,

[0033] Container status tracking module: The tracker deployed on the master node establishes a data structure that records the container status information on all nodes. It uses information from each task, scheduling decisions, response information after task completion, and proactive reports from worker nodes to update the container status information in the data structure in real time.

[0034] First, each request processed by the system carries two additional attributes, rt. running and rt paused These two attributes are used to record the number of containers on the worker node that are processing the same type of task and the number of available containers on the worker node that are processing the same type of task. After the container finishes processing the request, the container status information on the worker node is returned to the master node through these two attributes. The master node tracks the container status based on the returned container status information and scheduling decisions. If a container is deleted, the reporter on its worker node reports the information to the tracker in the master node.

[0035] The specific steps by which the container state tracking module implements the container state tracking function are as follows:

[0036] A1. Include two additional attributes, rt, for each request processed by the system. running and rt paused ;

[0037] A2. Maintain a table in the container tracker to store container status. The table includes the worker node name, the type of container currently running, the number of containers of a certain type currently running, the available container types, and the number of available containers of a certain type. The data structure of the container status information table is shown in the following table:

[0038] name type describe workerID unsigned int Unique identifier of a working node containerType string Container Types pausedContaiers unsigned int Number of free and available containers runningContainers unsigned int Number of running containers

[0039] A3. After each request is processed, it is returned to the master node. The tracker updates the container status table in A2 using the two additional attributes in A1, as well as the type of the request itself and the worker node that processed the request.

[0040] A4. When a container in a worker node is deleted, the reporter on that worker node sends the container type information to the container status tracker, and the container status tracker makes the corresponding adjustments.

[0041] Request arrival prediction module: It obtains historical request data from the database in the cluster as input to the predictor, analyzes this historical data through a time series prediction model, and obtains the request arrival situation in the future period.

[0042] First, the predictor continuously retrieves task arrival data from the cloud database, including task type and arrival time. By processing the task time series, it predicts the arrival status of tasks within a future time slice, including the type of arriving requests and the number of requests of a certain type. The predicted data obtained by the predictor serves as the basis for the decision-makers in the scheduler to create and delete containers.

[0043] The specific steps by which the request arrival prediction module implements the request arrival prediction function are as follows:

[0044] B1. The request arrival predictor predicts all requests and their quantities that will arrive within a certain period of time based on historical request data (request arrival time, number of requests) in the database. The task arrival information table data structure is as follows:

[0045]

[0046] B2. Request the predictor to send the prediction results for each time period to the decision-maker for relevant scheduling decisions;

[0047] B3. The scheduler calculates the types and quantities of containers that need to be created and the types and quantities of containers that need to be deleted based on the task arrival information table and the container status information table.

[0048] B4. Based on the container status information table, the scheduler uses the request scheduling function to decide whether to pre-create a container on a certain worker node and to delete a container that will not be used in the next time slice on a certain worker node.

[0049] Request scheduling module: The decision-maker obtains the best worker node for processing a task based on the container status information in the tracker, and either directly assigns the task or waits in the waiting queue for a suitable worker node to appear before assigning it.

[0050] When a new request arrives, the decision maker uses container status data to poll among affinity worker nodes with available containers, non-affinity worker nodes with no available containers but sufficient computing resources to create new containers, non-affinity worker nodes with no available containers and insufficient computing resources to create new containers but which can release resources by evicting other containers, and random worker nodes to find the most suitable worker node to process the request.

[0051] The request scheduling module implements the request scheduling function through the following steps:

[0052] C1. The decision maker obtains worker nodes from the tracker containing containers that can be used to process that type of request based on the attributes (type) of the incoming request;

[0053] C2. The decision maker selects an affinity worker node from the list of worker nodes obtained from C1, assigns the task to that worker node, and then the allocator on that worker node assigns the request to the specific container.

[0054] C3. If C2 is not satisfied, try a worker node that is not compatible and whose available container serving other types of tasks will not be called in the near future, evict the container and create a new container;

[0055] C4. If C3 is not satisfied, try a worker node that is not affinity and whose available container serving other types of tasks is about to be invoked in the near future, evict the container and create a new container;

[0056] C5. If C4 is not satisfied, randomly select a worker node and create a new container;

[0057] C6. Once an available container becomes available, immediately assign the task to the appropriate worker node.

[0058] This invention comprehensively considers the container status information on all worker nodes, the future arrival status of tasks, and resource utilization efficiency. During task scheduling, it records container status changes using a container status information table stored in the master node tracker, predicts the future arrival status of tasks based on historical arrival data, selects the most suitable worker node for newly arriving tasks, pre-creates containers that will be needed in the future, and pre-deletes idle containers that will not be needed in the future, thereby alleviating the cold start problem in serverless computing and reducing the overall average task response time.

[0059] Example 2

[0060] A task scheduling method to alleviate the cold start problem in serverless computing, such as Figure 1 As shown, Figure 1 This is a schematic diagram of the task scheduling structure of the serverless computing cluster in this embodiment, including serverless computing service users, task sets, serverless computing server clusters, and a scheduler. First, the serverless computing service users submit tasks to the serverless computing platform. Then, the job scheduler of the serverless computing server cluster is responsible for allocating these tasks to corresponding jobs. Each worker node can run multiple containers for processing specific tasks. Each type of task can only be processed by one specific container, and each container processes only one corresponding task. The node selection process of the scheduler in this invention is illustrated in the following diagram. Figure 2 As shown.

[0061] Suppose that the set of worker nodes obtained by calculating the hash value of the task and the linear probing step size is W = {w1, w2, ..., w...} i ,...,w nLet W be a subset of all worker nodes in the cluster. Iterate through W and select one node w from the set. Perform the following operations: retrieve the container information for the corresponding task type on w, and check if its pausedContainers are greater than 0. If so, it means there are idle and available containers, so return w directly; otherwise, calculate the idle computing resources Q on w. free Is it greater than the computing resources Q required by the task? task If the condition is met, return w; otherwise, based on the request arrival information table, find all deletable containers {C1, C2, ..., C}. i ,...C n} Calculate whether the computational resources used by all containers in all sets are greater than Q. task If the condition is met, return w; if none of the above conditions are met, continue traversing the next worker node until the set of worker nodes is empty, and return a random worker node.

[0062] Figure 3 This is a flowchart illustrating the task scheduling implementation in this embodiment. Control is performed when a task arrives and an available container becomes available, ensuring that the task is always processed on the earliest available container. For example... Figure 3 As shown, the container allocation process is as follows:

[0063] Use when a task arrives. Figure 2 The node selection process shown is as follows: First, a suitable worker node w is selected for the task. Then, it is determined whether the worker node is an affinity node, i.e., whether it contains an available free container. If so, the task is assigned directly. If not, the following operations are performed: the task is added to the waiting queue, and a new container is created on this worker node. Subsequently, once a free available container becomes available, the scheduler checks the type of the free available container (containerType) and its corresponding worker node w. i Use `containerType` to iterate through the waiting queue. If the queue contains a task of the response type, remove the task from the waiting queue and assign it to the worker node `w`. i .

[0064] Figure 4 This is a detailed flowchart of the task scheduling method for alleviating the cold start problem of serverless computing in an embodiment of the present invention, which specifically includes the following steps:

[0065] S1. An empty container status information table is created by the tracker in the scheduler;

[0066] S2. An empty task arrival information table is created by the predictor in the scheduler;

[0067] S3. An empty task waiting queue is created by the decision-maker in the scheduler;

[0068] S4. When a new task arrives, the decision-maker in the scheduler queries the container status from the container status information table;

[0069] S5. If a worker node with an available container is found for the request, assign the request to that worker node and proceed to S10;

[0070] Step S5, which selects a worker node for a newly arriving task based on the container status information and task arrival information, includes the following steps:

[0071] S501. Calculate the hash value and linear probe step size of the task;

[0072] S502. Select one working node from all working nodes based on the value calculated in S501. If the working node is not empty, jump to S503; otherwise, jump to S507.

[0073] S503. Obtain the type information rt corresponding to the task on the node;

[0074] S504. If type rt contains a usable container, go to S508; otherwise, jump to S505.

[0075] S505. If the available resources on the node are more than the computing resources required by the task, proceed to S508; otherwise, proceed to S506.

[0076] S506. Based on the arrival information of the task, if there is a container on the node that handles a task that will not arrive in the near future, and the sum of the computing resources released by evicting the container and the idle resources can meet the computing resources required by the task, proceed to S508; otherwise, jump to S502.

[0077] S507. Randomly select a node;

[0078] S508. Return to this node, and the algorithm ends.

[0079] S6. The decision-maker adds the task to the task waiting queue;

[0080] S7. The decision-maker selects a worker node for creating a new container for the request based on the container status information table and the task arrival information table, and sends a notification to that node;

[0081] S8. The worker node creates a response container based on the notification received from the decision maker. After creation, the reporter on the worker node sends a report to the tracker in the scheduler.

[0082] S9. Once an available container becomes available during the creation process, the decision-maker immediately removes the task from the waiting queue;

[0083] S10. The decision-maker in the scheduler assigns tasks to worker nodes that have available containers;

[0084] S11. After the task is processed by the container, the result is returned to the scheduler. The tracker in the scheduler retrieves the result from two additional attributes, rt. running and rt paused Obtain the container status information on the working node and update the container status information table accordingly;

[0085] Step S11, which involves updating and maintaining the container state based on the container state change information, includes the following steps:

[0086] S1101. The tracker in the scheduler obtains the container's status information from the response of the container after it has finished processing the task in the worker node and from the scheduling decisions made beforehand.

[0087] S1102. If the container is newly created, then let rt... running +1;

[0088] S1103. If the container has finished processing the request, i.e., the container is running in the container but has not yet processed the response task, then let rt... running -1, rt paused +1;

[0089] S1104. If the idle container is reassigned to the corresponding task, then let rt running +1, rt paused -1;

[0090] S1105. If an idle container is not assigned a response task for a certain period of time, or if the task arrival information obtained by the predictor indicates that the task it is processing will not arrive in the near future, it will be deleted, and rt will be set to... rpaused -1;

[0091] S1106. Container state update complete, algorithm ends.

[0092] S12. The predictor reads the historical arrival data of the task from the cloud database, predicts the arrival information of the task in the next time slice, and updates the task arrival information table.

[0093] S13. Based on the task arrival information table, the scheduler sends eviction requests to worker nodes for containers that will not arrive within a future time period, and at the same time pre-creates containers that cannot meet the concurrent task requests.

[0094] In step S13, the container is pre-created based on the future task arrival information. The specific steps are as follows:

[0095] S1301. The tracker in the scheduler obtains the future task arrival information from the predictor, determines all task types and quantities that need to be pre-created in containers, and builds a data table to send to the decision-maker.

[0096] S1302. The decision-maker traverses the data table and selects a task that needs to pre-create a container. If the task is not empty, jump to S1303; otherwise, jump to S1306.

[0097] S1303. The decision-maker in the scheduler selects a worker node for the newly arriving task according to the process of selecting a worker node in claim 7, and sends a request to the worker node to create a container, including the container type and the required number of containers, and sends the corresponding container creation information to the tracker.

[0098] S1304. Create the maximum number of containers that can be created on this working node. If the number of containers created meets the required number of containers, go to S1302; otherwise, go to S1305.

[0099] S1305. The worker node's reporter reports the number of containers that still need to be created to the decision-maker in the scheduler. The scheduler then selects a new worker node for the task, creates the remaining required containers on the new worker node, and sends container status update information to the tracker.

[0100] S1306. Container pre-creation complete, algorithm ends.

[0101] S14. After a container is evicted, the reporter on the worker node sends a report to the tracker, and the tracker updates the container status information table accordingly based on the report.

[0102] This invention considers the lifecycle of containers and the future arrival information of tasks, and optimizes the task scheduling strategy and container creation and deletion strategy to reduce the overall response latency when the cluster processes tasks. Specifically, it includes the following: (1) Container status tracking function: First, each system-processed request carries two additional attributes rt. running and rt paused, respectively, are used to record how many containers on the working node that is processing the same type of task are processing the same type of task and how many available containers on the working node that is processing the same type of task are processing the same type of task. After the container finishes processing the request, the container status information on the working node is returned to the master node through these two attributes. The master node tracks the container status based on the returned container status information and scheduling decision; (2) Request arrival prediction function: obtain historical request data from the database in the cluster as input to the predictor, analyze these historical data through the time series prediction model to obtain the request arrival situation in the future period, including the type of request that arrives and the number of requests of a certain type that arrive. The prediction data obtained by the predictor is used as the basis for the decision-maker in the scheduler to create and delete containers; (3) Request scheduling function: for a new request, the decision-maker uses the container status data to poll and try from the affinity working nodes with available containers, the non-affinity working nodes with no available containers but with enough computing resources to create new containers, the non-affinity working nodes with no available containers and no sufficient computing resources to create new containers but can release resources by evict other containers, and random working nodes, to find the most suitable working node to process the request. Ultimately, by optimizing task scheduling and container creation and deletion strategies, the overall response latency when the cluster processes tasks is reduced. This method has broad application value and promising prospects in the field of serverless computing.

[0103] It should be noted that the above content merely illustrates the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. For those skilled in the art, various improvements and modifications can be made without departing from the principle of the present invention, and all such improvements and modifications fall within the scope of protection of the claims of the present invention.

Claims

1. A task scheduling system for alleviating the cold start problem in serverless computing, characterized in that: It includes at least a container state tracking module, a request arrival prediction module, and a request scheduling module; The container status tracking module is implemented by deploying a container status tracker in the master node of the cluster, which tracks the container status based on the container status information and scheduling decisions on the worker nodes. The request arrival prediction module: based on historical request data in the system, uses a time series prediction model to obtain the task arrival status within a future period, and controls the pre-creation or deletion of containers; the task arrival status includes at least the type of request arriving and the number of requests of a certain type arriving; The request scheduling module: based on the container status information tracked by the container status tracking module and the request arrival information predicted by the request arrival prediction module, it rationally schedules newly arriving requests and controls the creation and deletion of containers; the scheduling is carried out by polling from four modes: affinity worker nodes with available containers, non-affinity worker nodes with no available containers but sufficient computing resources to create new containers, non-affinity worker nodes with no available containers and insufficient computing resources to create new containers but which can release resources by evicting other containers, and random worker nodes, to find the most suitable worker node to schedule and control the requests; including the following steps: S501. Calculate the hash value and linear probe step size of the task; S502. Select a working node from all working nodes in a round-robin fashion based on the value calculated in step S501. If the working node is not empty, skip to step S503; otherwise, skip to step S507. S503. Obtain the container type information rt corresponding to the task on the node; S504. If type rt contains a usable container, proceed to step S508; otherwise, skip to step S505. S505. If the idle resources on the node are more than the computing resources required by the task, proceed to step S508; otherwise, proceed to step S506. S506. Based on the arrival information of the task, if there is a container on the node that handles a task that will not arrive in the near future, and the sum of the computing resources released by evicting the container and the idle resources can meet the computing resources required by the task, proceed to step S508; otherwise, proceed to step S502. S507. Randomly select a node; S508. Return to this node; the step is complete.

2. The task scheduling system to mitigate serverless computing cold start problem of claim 1, wherein: The specific steps for implementing the container state tracking function in the container state tracking module are as follows: A1. The request handled by each system carries two additional attributes rt running and rt paused ; A2. Maintain a table in the container tracker to store container status. The table includes worker node name, running container type, number of running containers of a certain type, available container types, and number of available containers of a certain type. A3. After each request is processed, it is returned to the master node. The tracker updates the container status table in step A2 using the two additional attributes in step A1, the type of the request itself, and the worker node information that processed the request. A4. When a container in a worker node is deleted, the reporter on that worker node sends the container type information to the container status tracker, and the container status tracker makes the corresponding adjustments.

3. The task scheduling system to mitigate serverless computing cold start problem of claim 1, wherein: The specific steps for implementing the request arrival prediction function in the request arrival prediction module include: B1. The request arrival predictor predicts the arrival status of all tasks that will arrive within a future period based on historical request data in the database. The historical request data includes at least the arrival time and the number of requests. The task arrival status includes at least the type of request that arrives and the number of requests of a certain type that arrive. B2. Request the predictor to send the prediction results for each time period to the decision-maker for scheduling decisions; B3. The scheduler calculates the types and quantities of containers that need to be created and the types and quantities of containers that need to be deleted based on the task arrival information table and the container status information table. B4. The scheduler controls the pre-creation or deletion of containers based on the container status information table.

4. The task scheduling system to mitigate serverless computing cold start problem of claim 1, wherein: The specific steps for implementing the request scheduling function in the request scheduling module are as follows: C1. The decision maker obtains worker nodes from the tracker, which contain containers that can be used to process the type of request, based on the attributes of the incoming request; C2. The decision-maker selects an affinity worker node from the list of worker nodes obtained in step C1, assigns the task to the worker node, and the allocator on the worker node assigns the request to the specific container. C3. If step C2 cannot be satisfied, select a non-affinity worker node whose available container serving other types of tasks will not be invoked in the near future, evict this container and create a new container; C4. If step C3 cannot be satisfied, select a worker node that is not affinity and whose available container serving other types of tasks is about to be invoked in the next period of time, evict this container and create a new container; C5. If step C4 cannot be satisfied, randomly select a worker node and create a new container; C6. Once an available container becomes available, immediately assign the task to the appropriate worker node.

5. A task scheduling method for mitigating the cold start problem in serverless computing using the system as described in claim 1, characterized in that, Includes the following steps: S1. Create an empty container state information table using the tracker in the container state tracking module; S2. Create an empty task arrival information table using the predictor in the request arrival prediction module; S3. An empty task waiting queue is created by the decision-maker in the request scheduling module; S4. When a new task arrives, the decision-maker queries the container status from the container status information table; S5. If a worker node with an available container is found for the request, assign the request to that worker node and proceed to step S10. S6. The decision-maker adds the task to the task waiting queue; S7. The decision-maker selects a worker node for creating a new container for the request based on the container status information table and the task arrival information table, and sends a notification to that node; S8. The worker node creates the corresponding container based on the notification received from the decision maker. After creation, the reporter on the worker node sends a report to the tracker in the scheduler. S9. Once an available container becomes available during the creation process, the decision-maker immediately removes the task from the waiting queue; S10. The decision-maker in the scheduler assigns tasks to worker nodes that have available containers; S11. After the task is processed by the container, the result is returned to the scheduler. The tracker in the scheduler retrieves the result from two additional attributes, rt. running and rt paused Obtain the container status information on the working node and update the container status information table accordingly; S12. The predictor reads the historical arrival data of the task from the cloud database, predicts the arrival information of the task in the next time slice, and updates the task arrival information table. S13. Based on the task arrival information table, the scheduler sends eviction requests to worker nodes for containers that will not arrive within a future time period, and at the same time pre-creates containers that cannot meet the concurrent task requests. S14. After a container is evicted, the reporter on the worker node sends a report to the tracker, and the tracker updates the container status information table accordingly based on the report.

6. The task scheduling method for alleviating the cold start problem of serverless computing as described in claim 5, characterized in that: Step S11, which involves updating and maintaining the container state based on the container state change information, includes the following steps: S1101. The tracker in the scheduler obtains the container's status information from the response of the container after it has finished processing the task in the worker node and from the scheduling decisions made beforehand. S1102. If the container is newly created then let rt running +1; S1103. If the container has finished processing the request, i.e., the container is running in the container but has not yet processed the corresponding task, then let rt... running -1, rt paused +1; S1104. If the idle container is re-assigned with the corresponding task, let rt running +1, rt paused -1; S1105. If an idle container is not assigned a response task for a certain period of time, or if the task arrival information obtained by the predictor indicates that the task it is processing will not arrive in the near future, it will be deleted, and rt will be set to... rpaused -1; S1106. Container status update complete, step ends.

7. A task scheduling method for alleviating the cold start problem in serverless computing as described in claim 5, characterized in that: In step S13, the container is pre-created based on the future task arrival information. The specific steps are as follows: S1301. The tracker in the scheduler obtains the future task arrival information from the predictor, determines all task types and quantities that need to be pre-created in containers, and builds a data table to send to the decision-maker. S1302. The decision-maker traverses the data table and selects a task that needs to pre-create a container. If the task is not empty, jump to step S1303; otherwise, jump to step S1306. S1303. The decision-maker in the scheduler selects the worker node to pre-create containers for the task and sends a request to the worker node to create containers, including the container type and the required number of containers, while sending the container creation information in response to the tracker. S1304. Create the maximum number of containers that can be created on this working node. If the number of containers created meets the required number of containers, proceed to step S1302. Otherwise, proceed to step S1305; S1305. The worker node's reporter reports the number of containers that still need to be created to the decision-maker in the scheduler. The scheduler then selects a new worker node for the task, creates the remaining required containers on the new worker node, and sends container status update information to the tracker. S1306. Container pre-creation complete. Step ends.

Images