Task processing method, device and equipment for server cluster, computer readable storage medium and computer program product

Abstract

The invention provides a task processing method, device and equipment for a server cluster, a computer program product and a computer readable storage medium. The method comprises the steps that a to-be-scheduled target calculation task is received, and the target calculation task comprises the resource demand quantity; performing resource matching on the resource demand quantity and the resource information of each server, and determining a plurality of candidate servers from the plurality of servers according to a resource matching result; determining a target server from a plurality of candidate servers according to the historical scheduling record of each candidate server; a task scheduling instruction is sent to a target server, and the task scheduling instruction indicates that the target calculation task is scheduled to the target server. By means of the method and device, efficient scheduling of server cluster tasks and reasonable resource allocation can be achieved, and the overall processing efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, and particularly relates to a task processing method and device of a server cluster, an equipment, a computer readable storage medium and a computer program product. BACKGROUND

[0002] In a cloud computing environment, a cloud server scheduling system is responsible for distributing various tasks to appropriate servers to achieve efficient use of resources and stable operation of business. As a key link of the scheduling system, the optimization of the bin packing strategy directly affects the efficiency and performance of the scheduling.

[0003] In the related art, the scheduling system often adopts a first-fit algorithm, a best-fit algorithm, a round-robin algorithm and the like on the bin packing strategy, and matches tasks to server resources through different distribution strategies to achieve a basic optimization goal. However, with the increase of the load of the cloud platform and the complexity of the tasks, how to improve the overall efficiency of the scheduling still faces challenges. SUMMARY

[0004] The embodiments of the present application provide a task processing method and device of a server cluster, an equipment, a computer readable storage medium and a computer program product, which can efficiently and accurately determine an adaptive target server for a target computing task to be scheduled from a server cluster, thereby realizing efficient scheduling and processing of the target computing task.

[0005] The technical solution of the embodiments of the present application is as follows: The embodiments of the present application provide a task processing method of a server cluster, the server cluster comprising a plurality of servers, the server cluster being provided with a cache, the cache being used to store resource information of each server and historical scheduling records of the server; the method comprising: receiving a target computing task to be scheduled, wherein the target computing task comprises a resource demand amount; performing resource matching on the resource demand amount and the resource information of each server, and determining a plurality of candidate servers from the plurality of servers according to a resource matching result; determining a target server from the plurality of candidate servers according to the historical scheduling records of each candidate server; and sending a task scheduling instruction to the target server, wherein the task scheduling instruction indicates that the target computing task is scheduled to the target server.

[0006] The embodiment of the application provides a task processing device of a server cluster, the server cluster comprises a plurality of servers, the server cluster is provided with a cache, the cache is used for storing resource information of each server and historical scheduling records of the server; the device comprises: a receiving module configured to receive a target computing task to be scheduled, wherein the target computing task comprises a resource requirement amount; a determining module configured to perform resource matching between the resource requirement amount and the resource information of each server, and determine a plurality of candidate servers from the plurality of servers according to a resource matching result; the determining module is further configured to determine a target server from the plurality of candidate servers according to the historical scheduling records of each candidate server; and an executing module configured to send a task scheduling instruction to the target server, wherein the task scheduling instruction indicates that the target computing task is scheduled to the target server.

[0007] In the above scheme, the resource information comprises available resource information of the server; the available resource information comprises available resource amounts of a plurality of resource types; the determining module is further configured to match the available resource amounts of the server with resource requirement amounts of corresponding resource types in the resource requirement amount respectively to obtain a resource matching result; and in response to the resource matching result representing that the available resource amounts of the server are all greater than or equal to the resource requirement amounts of corresponding resource types in the resource requirement amount, the server is determined as a candidate server.

[0008] In the above scheme, the available resource information of each server is stored in the cache in the form of a multi-level index, the multi-level index comprises available resource amounts of a plurality of resource types in the available resource information and a server identifier; the determining module is further configured to, for each server entry in the multi-level index, match the available resource amounts of each resource type in the server entry with resource requirement amounts of corresponding resource types in the resource requirement amount to obtain a resource matching result; and in response to the resource matching result representing that the available resource amounts of each resource type in the server entry are all greater than or equal to the resource requirement amounts of corresponding resource types in the resource requirement amount, a server corresponding to the server identifier in the server entry is determined as a candidate server.

[0009] In the above scheme, the resource information of the server includes total resource quantity of the server, the historical scheduling record of the server includes resource occupation quantity of a task group scheduled to the server, and a matching score of the task group relative to the server; the matching score is a proportion of available resource quantity of the server to the total resource quantity, and the available resource quantity is a difference between the total resource quantity and the resource occupation quantity; the determining module is further configured to update the matching score according to the resource requirement quantity to obtain a new matching score; and determine a target server from the plurality of candidate servers according to the new matching score of each candidate server.

[0010] In the above scheme, the server includes resources of a plurality of resource types; the determining module is further configured to obtain a preset weight of each resource type; for each resource type, determine a target resource occupation quantity as a sum of the resource requirement quantity of the resource type and the resource occupation quantity of the resource type; determine an available resource quantity of the resource type as a difference between total resource quantity of the resource type and the target resource occupation quantity of the resource type; determine a matching score of the resource type as a proportion of the available resource quantity of the resource type to the total resource quantity of the resource type; and determine the new matching score based on the preset weight of each resource type and the matching score of each resource type.

[0011] In the above scheme, the cache adopts a form of a graph structure; the determining module is further configured to determine a target edge corresponding to a task satisfying a resource similarity condition with the target computing task from the graph structure based on the resource requirement quantity; wherein the server is taken as a node in the graph structure, and a scheduling relationship between the task and the server is taken as an edge; the resource information and the historical scheduling record are included in the node; and a server connected by the target edge is determined as the candidate server.

[0012] In the above scheme, the number of the target computing tasks to be scheduled is a plurality; the server includes resources of a plurality of resource types; the determining module is further configured to, for each resource type, obtain a resource requirement quantity of each target computing task in the resource type; based on the resource requirement quantity and a plurality of preset resource requirement quantity intervals, divide a plurality of target computing tasks into at least one target computing task set; wherein each target computing task set corresponds to a resource requirement quantity interval; for each target computing task set, perform resource matching on the resource requirement quantity interval corresponding to the target computing task set and the resource information of each server; and determine a plurality of candidate servers matched with target computing tasks in the target computing task set from the plurality of servers according to a resource matching result.

[0013] In the above scheme, the device further comprises a data updating module configured to: in response to detecting a server resource state change event, acquire resource change information corresponding to the server resource state change event, or in response to detecting a demand change event of a target computing task scheduled to the server, acquire resource change information corresponding to the demand change event; determine a target data segment corresponding to the resource change information in the cache; and update the target data segment in the cache using the resource change information.

[0014] In the above scheme, the device further comprises a data storage module configured to: after sending a task scheduling instruction to the target server, acquire a task execution result of the target server executing the target computing task; write the task execution result as a scheduling record of the task scheduling instruction into the cache; and synchronize the scheduling record from the cache to a database; and the database is configured to store resource information of each server in the server cluster and the historical calling record.

[0015] In the above scheme, the number of the target computing tasks to be scheduled is a plurality; the determining module is further configured to acquire a task parameter of each target computing task; based on the task parameter, divide similar tasks in the plurality of target computing tasks into a same target computing task set; for each target computing task set, perform resource matching between a resource demand of a target computing task in the target computing task set and the resource information of each server, and determine a plurality of candidate servers for the target computing task set from the plurality of servers according to a resource matching result.

[0016] In the above scheme, the device further comprises an information storage module configured to: acquire a version number of resource information and a historical scheduling record of each server, and generate a verification tag for each server; the verification tag is configured to perform validity verification on the resource information and the historical scheduling record of the server when performing task scheduling; and map and store the version number, the resource information and the historical calling record of the server in the cache respectively, and map and store the verification tag, the resource information and the historical calling record of the server in the cache respectively.

[0017] Embodiments of the present application provide an electronic device, comprising: a memory configured to store computer executable instructions or computer programs; and a processor configured to execute the computer executable instructions or computer programs stored in the memory to implement the task processing method of the server cluster.

[0018] The embodiment of the present application provides a computer readable storage medium, which stores computer executable instructions or a computer program, and the computer executable instructions or the computer program are executed by a processor to implement the task processing method of the server cluster.

[0019] The embodiment of the present application provides a computer program product, which comprises computer executable instructions or a computer program, and the computer executable instructions or the computer program are executed by a processor to implement the task processing method of the server cluster.

[0020] The above scheme has the following beneficial effects: In the embodiment of the present application, the resource information and the historical scheduling record of the server are stored in the cache, so that the data used for task scheduling decision can be quickly obtained, the data access time is reduced, and the scheduling efficiency is improved; the resource requirement of the target computing task is matched with the resource information of the server, the candidate server satisfying the resource requirement is screened out, and it is ensured that the candidate server has the basic resource condition for processing the task; and then the target server is determined from the candidate server based on the historical scheduling record of the candidate server, so that the selection of the target server not only meets the resource requirement of the target computing task, but also adapts to the task characteristics of the target computing task in combination with the historical scheduling condition, thereby improving the accuracy and rationality of the task scheduling of the server cluster and optimizing the overall task processing performance. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 is an optional architecture schematic diagram of the task processing system of the server cluster provided by the embodiment of the present application; Figure 2 is a structural schematic diagram of an electronic device provided by the embodiment of the present application; Figure 3 is an optional flowchart of the task processing method of the server cluster provided by the embodiment of the present application; Figure 4 is an optional implementation flowchart for determining a plurality of candidate servers provided by the embodiment of the present application; Figure 5 is another optional implementation flowchart for determining a plurality of candidate servers provided by the embodiment of the present application; Figure 6 is still another optional implementation flowchart for determining a plurality of candidate servers provided by the embodiment of the present application; Figure 7 is yet another optional implementation flowchart for determining a plurality of candidate servers provided by the embodiment of the present application; Figure 8 is an implementation flowchart for determining a target server from a plurality of candidate servers provided by the embodiment of the present application; Figure 9is an implementation process schematic diagram provided by the embodiment of the application for obtaining a new matching score; Figure 10 is an implementation process schematic diagram provided by the embodiment of the application for updating a target data segment in a cache; Figure 11 is an architecture implementation process schematic diagram of a task processing method of a server cluster provided by the embodiment of the application; Figure 12 is a cache structure schematic diagram of a task processing method of a server cluster provided by the embodiment of the application; Figure 13 is a whole framework principle schematic diagram of a task processing method of a server cluster provided by the embodiment of the application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be described in further detail below with reference to the accompanying drawings, and the described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those skilled in the art without making creative efforts fall within the scope of protection of the present application.

[0023] In the following description, "some embodiments" are related to a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0024] In the following description, the terms "first\second\third" are only to distinguish similar objects, and do not represent a specific order of the objects, and it can be understood that "first\second\third" can be interchanged with a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0025] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the functions of the module or unit.

[0026] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as those commonly understood by those skilled in the art. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0027] The relevant data collection and processing in the embodiments of the present application should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of authorization of laws and regulations and the personal information subject.

[0028] Before further detailing the embodiments of the present application, the terms and phrases involved in the embodiments of the present application are explained, and the terms and phrases involved in the embodiments of the present application are applicable to the following explanations.

[0029] 1) In response to: used to represent the conditions or states on which the operations performed depend, when the dependent conditions or states are met, one or more operations performed can be real-time or have a set delay; in the absence of special instructions, there is no restriction on the execution order of multiple operations performed.

[0030] 2) Cloud server: Cloud server is a virtual server based on cloud computing technology, providing computing, storage and network resources. Users can rent cloud servers through the Internet, without the need to purchase and manage physical hardware, to achieve flexible, efficient and secure computing resource utilization. Cloud servers support elastic scaling, dynamically adjusting resources according to demand, suitable for various application scenarios such as website hosting, data storage, application development, etc.

[0031] 3) Physical machine: Physical machine is an entity computer relative to virtual machine, providing hardware environment for virtual machine. Physical machine can support multiple operating systems through virtualization technology, and these operating systems can communicate with each other, just like multiple computers.

[0032] 4) Packing strategy: In cloud server scheduling, a series of rules and methods followed in the process of allocating tasks (which can be regarded as goods) to cloud servers (which can be regarded as boxes). The goal is to efficiently use server resources as much as possible while meeting task resource requirements, reducing server idling and overuse. For example, according to the demand of tasks for CPU, memory and other resources, multiple tasks are reasonably "packed" into one or more servers.

[0033] 5) Cache merging: Integrating and storing multiple scattered data or calculation results related to packing strategy to form a unified and efficient cache structure. Through merging, the required information can be quickly obtained from the merged cache in the subsequent scheduling process, reducing the time of repeated calculation and data lookup.

[0034] In the related art, cloud server scheduling systems generally use a cache mechanism based on resource state or historical scheduling records to improve scheduling efficiency. Even if some schemes attempt to reuse historical data, they can only achieve resource matching through static caching or independent database queries. This approach not only has high response delay, but also has limited resource utilization, making it difficult to meet the needs of real-time scheduling and resource optimization in a high-concurrency and dynamic cloud environment. Therefore, the method in the related art cannot effectively respond to instantaneous changes in server resource state, and static resource snapshots cannot reflect real-time cluster load, which can easily lead to scheduling decision errors based on outdated information. At the same time, relying solely on historical scheduling records lacks consideration of the overall resource layout of the current cluster, and the applicability of historical solutions decreases significantly when nodes are dynamically added or removed, which restricts scheduling accuracy and resource integration efficiency.

[0035] Based on the at least one problem existing in the related art, the embodiments of the present application provide an efficient, low-overhead, and highly scalable technical solution to address the problem that the cloud server scheduling system in the related art cannot balance scheduling efficiency and resource optimization in a dynamic high-concurrency environment. The task scheduling process can be based on a unified policy cache and dynamic update mechanism to achieve efficient sharing and reuse of intermediate results, improving system throughput and resource utilization. Specifically, the embodiments of the present application provide a task processing method for a server cluster, which is characterized by constructing a unified cache unit containing multiple indexes and graph structures to integrate and store intermediate calculation results of server resource information, task requirements, and packing strategies. Based on an event-driven mechanism, the cache is dynamically updated incrementally to ensure data consistency. Finally, through a multi-factor scoring model and parallel processing mechanism, the optimal server is quickly located and scheduling decisions are executed. The embodiments of the present application effectively solve the problems of calculation redundancy, high database load, and large response delay in traditional scheduling schemes, achieving coordinated optimization of task scheduling efficiency and resource utilization in a highly dynamic cloud environment, significantly reducing scheduling delay and improving overall system performance.

[0036] Here, first, an exemplary application of the task processing device of the server cluster of the embodiments of the present application is described, which is an electronic device for implementing the task processing method of the server cluster. The task processing device of the server cluster (i.e., the electronic device) provided by the embodiments of the present application can be implemented as a terminal or as a server. In one implementation, the electronic device provided by the embodiments of the present application can be implemented as any terminal with a task processing function of the server cluster, such as a notebook computer, a tablet computer, a desktop computer, a smart robot, etc.; in another implementation, the electronic device provided by the embodiments of the present application can also be implemented as a server, where the server can be a standalone physical server or a server cluster or a distributed system composed of multiple physical servers. The terminal and the server can be directly or indirectly connected through wired or wireless communication, which is not limited in the embodiments of the present application. In the following, an exemplary application when the electronic device is implemented as a server is described.

[0037] Referring to Figure 1 , Figure 1 is a schematic diagram of the architecture of the task processing system 100 of the server cluster provided by the embodiments of the present application, where the terminal (exemplarily shown as the terminal 400-1 and the terminal 400-2) is connected to the server 200 through the network 300, and the server 200 accesses data by being connected to the database 500, where the server 200 can be any server in the server cluster, and the server 200 is the server that receives the target computing task; the network 300 can be a wide area network or a local area network, or a combination of the two.

[0038] Referring to Figure 1 In the task processing of the server cluster, the terminal (the terminal 400-1 and the terminal 400-2) can receive the computing demand input by the user, generate the target computing task to be scheduled, and send the target computing task to the server 200 through the network 300; after receiving the target computing task, the server 200 matches the resource demand of the target computing task with the resource information of each server in the server cluster based on the resource information and the historical scheduling records of each server stored in the cache, filters out the candidate servers whose resources meet the demand, determines the final target server in combination with the historical scheduling records of the candidate servers, and then sends a task scheduling instruction to the target server to complete the task allocation; during this process, the server 200 can interact with the database 500 to synchronize the data such as the resource information and the historical scheduling records in the cache to the database 500 for persistent storage, or load data from the database 500 to the cache, so as to ensure the accuracy and efficient access of the data in the scheduling process, thereby enabling the target computing task submitted by the user to be quickly and reasonably allocated to the appropriate server for processing and improving the user's task processing experience.

[0039] In some embodiments, the server 200 can be a standalone physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and basic cloud computing services such as big data and artificial intelligence platforms. The terminal and the server can be connected directly or indirectly through wired or wireless communication, which is not limited in the embodiments of the present application.

[0040] Referring to Figure 2 , Figure 2 is a structural schematic diagram of an electronic device provided by an embodiment of the present application, Figure 2 The electronic device shown in the figure includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. Various components in the electronic device are coupled together through a bus system 440. It can be understood that the bus system 440 is used to realize the connection and communication between the components. In addition to the data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the purpose of clear illustration, all kinds of buses are marked as the bus system 440 in the figure. Figure 2

[0041] The processor 410 can be an integrated circuit chip with signal processing capability, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor.

[0042] The user interface 430 includes one or more output devices 431 that enable the presentation of media content. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input.

[0043] ​Memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. Memory 450 may optionally include one or more storage devices physically located remote from processor 410. Memory 450 may include volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM), and volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include memory of any suitable resource type. In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as illustrated below.

[0044] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; network communication module 452 for reaching other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.; presentation module 453 for enabling the presentation of information (e.g., user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., display screen, speaker, etc.); input processing module 454 for detecting and translating one or more user inputs or interactions from one or more input devices 432.

[0045] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A task processing device 455 for a server cluster stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a receiving module 4551, a determining module 4552, and an execution module 4552. These modules are logically linked and can therefore be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0046] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the task processing method of the server cluster provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0047] The task processing method for server clusters provided in the embodiments of this application will be described below. Figure 3 This is an optional flowchart illustrating a task processing method for a server cluster provided in an embodiment of this application. The following will be combined with... Figure 3 The steps shown are explained as follows: Figure 3 As shown, the execution subject of the task processing method of the server cluster is an electronic device as an example. The electronic device can be implemented as any server in the server cluster. Here, the server cluster includes multiple servers and is equipped with a cache. The cache is used to store the resource information of each server and the server's historical scheduling records. The method includes the following steps S101 to S104: Step S101: Receive the target computing task to be scheduled, wherein the target computing task includes resource requirements.

[0048] A target computing task is a basic unit of work in a cloud computing environment that needs to be assigned to a specific server node for execution. A target computing task represents a computing job, service request, or data processing activity submitted by a user. A target computing task can be an independent batch processing job or a service instance in a microservice architecture.

[0049] Resource requirements refer to the specifications and quantity constraints of various computing resources required for the normal execution of a target computing task, and are the core basis for task scheduling decisions. Resource requirements are quantified using a Resource Demand Vector, which includes constraint parameters in the following dimensions: computing resources (including the required number of CPU cores, whether specific instruction set extensions are required, etc.); memory resources (including memory capacity requirements, memory bandwidth baselines, etc.); storage resources (including local temporary storage space, persistent storage space, and input / output operations per second (IOPS) requirements, etc.); network resources (including network bandwidth guarantees, network latency limits, etc.); accelerator resources (including the number of Graphics Processing Units (GPUs) and their memory requirements, Field-Programmable Gate Arrays (FPGAs) or other dedicated accelerator types, etc.); and quality of service (including task priority labels, maximum execution time limits, resource isolation level requirements, etc.).

[0050] In this embodiment, the target computing task can be received in various ways. For example, it can receive externally submitted task descriptions through the Application Programming Interface (API) provided by the scheduling system; asynchronously obtain task requests from task producers through message queue middleware (such as Kafka or RabbitMQ); or automatically generate periodic computing tasks through the scheduled task module within the scheduling system. When receiving a target computing task, the scheduling system performs integrity checks, including verifying the format and validity of resource requirements, and checking task signatures or authorization credentials, to ensure that only legitimate task requests enter the scheduling process. The received target computing task can also be encapsulated into a unified internal representation and have metadata such as a receipt timestamp and task sequence number added to establish a complete context for subsequent scheduling decisions.

[0051] Step S102: Match the resource requirements with the resource information of each server, and determine multiple candidate servers from multiple servers based on the resource matching results.

[0052] Here, resource information includes the available resources of the server, which includes the available resources of multiple resource types, such as CPU, memory, storage, and other types of available resources.

[0053] In some embodiments, see Figure 4 ,Figure 4 The method involves matching resource requirements with the resource information of each server, and determining multiple candidate servers from multiple servers based on the resource matching results. This can be achieved through the following steps S201 to S202: Step S201: Match the available resources of the server with the resource requirements of the corresponding resource types in the resource requirements to obtain the resource matching results.

[0054] Here, resource requirement refers to the minimum amount of computing resources needed for the target computing task, such as the minimum number of CPU cores, memory capacity, and storage space required. Available resources, on the other hand, refer to the total amount of resources that the servers in the server cluster can currently provide for the target computing task. By comparing the available resources for each resource type with the corresponding resource requirement in the resource requirement table, it can be determined whether each server in the server cluster has the capability to meet the task.

[0055] In this embodiment, the available resource information of each server is stored in the cache through a multi-level index. Correspondingly, the multi-level index includes the available resource quantities of multiple resource types and server identifiers within the available resource information. The multi-level index categorizes server resources according to multiple dimensions (such as CPU, memory, and storage) and manages them hierarchically in a tree or graph format. Using the multi-level index, the scheduling system can quickly locate server entries under a specific resource type. Therefore, in step S201, for each server entry in the multi-level index, the available resource quantity of each resource type in the server entry is matched with the resource demand quantity of the corresponding resource type in the resource demand quantity, thereby obtaining the resource matching result.

[0056] Step S202: In response to the resource matching results indicating that the available resources of the server are all greater than or equal to the resource requirements of the corresponding resource type in the resource requirements, the server is determined as a candidate server.

[0057] Here, when resource matching results indicate that a server has sufficient available resources to support the resource requirements of the target computing task, that server is identified as a candidate server. Only when all resource types of a server meet the resource requirements is it considered a candidate server, i.e., a server that may be used to host the target computing task.

[0058] A candidate server refers to a server in a set of candidate servers that possess all the resource conditions to execute the target computing task, obtained through resource matching and screening. In this embodiment, the process of determining candidate servers can adopt a multi-stage verification mechanism: first, an initial candidate server set is established based on strict resource matching; then, a load balancing strategy is applied to exclude servers whose load rate exceeds a dynamic threshold; finally, resource fragmentation evaluation is performed, prioritizing servers with concentrated resource distribution. The candidate server set is maintained through a candidate server list, and each candidate server entry includes metadata such as server identifier, resource fit score, and real-time load metrics.

[0059] In this embodiment, the resource requirements of the target computing task are obtained, and then the resource requirements of the target computing task are compared with the available resources of the server item by item to obtain the resource matching result. Finally, candidate servers that meet the conditions are selected based on the resource matching result. The whole process ensures the accuracy of resource matching and the efficiency of scheduling decisions.

[0060] In the specific implementation process, the resource matching result refers to the result obtained by comparing the available resource quantity of each resource type in the server entry with the resource quantity required by the target computing task one by one. Only when the available resource quantity of all resource types meets the condition of being greater than or equal to the resource requirement is the server entry considered to be successfully matched with the target computing task. Therefore, the determination of candidate servers in step S202 can be achieved in the following way: in response to the resource matching result indicating that the available resource quantity of each resource type in the server entry is greater than or equal to the resource requirement of the corresponding resource type, the server corresponding to the server identifier in the server entry is determined as a candidate server.

[0061] In this embodiment, by introducing multi-level indexes, efficient organization and rapid retrieval of server resource information are achieved. Simultaneously, the accurate judgment of resource matching results improves the accuracy of server selection. By introducing multi-level indexes and combining them with accurate judgment of resource matching results, unnecessary database queries can be reduced, scheduling latency can be lowered, thereby improving overall response speed and resource utilization. This enables support for larger-scale concurrent task scheduling, enhancing the scalability and stability of the scheduling system.

[0062] In some embodiments, caching can be performed using a graph structure, see [link to documentation]. Figure 5 , Figure 5 The diagram illustrates step S102, which involves matching resource requirements with the resource information of each server and determining multiple candidate servers from among them based on the resource matching results. This can also be achieved through the following steps S301 to S302: Step S301: Based on the resource requirements, determine the target edge from the graph structure that corresponds to the task that satisfies the resource similarity condition of the target computing task.

[0063] A graph structure is a data structure used to represent the scheduling relationships between tasks and servers. In a graph structure, servers are treated as nodes, and the scheduling relationships between tasks and servers are represented as edges. Each node includes resource information and historical scheduling records. By constructing a graph structure, the resource allocation among servers and the historical scheduling paths of different tasks can be visually displayed.

[0064] Historical scheduling records refer to the tasks executed by a server over a past period and the corresponding resource allocation. By referring to the information in historical scheduling records, it is possible to identify which servers have successfully executed similar tasks and optimize the scheduling decisions for the target computation task based on this information.

[0065] A target edge is an edge in a graph structure that corresponds to a task with resource similarity to the target computing task. Resource similarity means that the resource requirements (such as CPU and memory) of the target computing task are close to the actual resource usage of existing tasks on the server. By filtering out edges corresponding to tasks with resource similarity to the target computing task, servers that might be suitable for the target computing task can be quickly located.

[0066] Step S302: The server connected to the target edge is determined as the candidate server.

[0067] By analyzing the resource requirements of the target computing task and combining this with resource information and historical scheduling records in the graph structure, target edges corresponding to tasks with similar resources to the target computing task are identified. Then, the servers associated with these target edges are further identified as candidate servers, thus providing basic data support for subsequent precise matching or load balancing operations.

[0068] In this embodiment of the application, by constructing a graph structure and using target edges to filter candidate servers, the inefficient operation of matching resources for all servers one by one can be effectively avoided, thereby significantly reducing scheduling latency and improving the overall performance and resource utilization of the cloud server scheduling system.

[0069] In some embodiments, the number of target computing tasks to be scheduled can be multiple; see [link to relevant documentation]. Figure 6 , Figure 6 The diagram illustrates that in step S102, resource matching is performed between the resource demand and the resource information of each server, and multiple candidate servers are determined from multiple servers based on the resource matching results. This can be achieved through the following steps S401 to S404: Step S401: For each resource type, obtain the resource requirements of each target computing task under the resource type.

[0070] Here, there are multiple target computing tasks to be scheduled, and the server includes resources of multiple resource types. Resource type refers to the type of hardware or software resources that the target computing task depends on during execution, such as CPU, memory, and storage space. Each resource type has different units of measurement and allocation rules; for example, CPU is measured in cores, and memory is measured in GB.

[0071] Resource requirements are the minimum resource requirements of a target computing task for a specific resource type, indicating how many resources the target computing task needs to run at least. For example, an image processing target computing task may require 4 CPU cores, 8GB of memory, and 50GB of storage space.

[0072] Step S402: Based on the resource requirements and multiple preset resource requirement ranges, divide the multiple target computing tasks into at least one target computing task set; wherein each target computing task set corresponds to a resource requirement range.

[0073] Resource demand range refers to a predefined range of resource demands used for coarse-grained task classification. A target computing task set refers to a logical grouping of multiple target computing tasks with similar resource demand characteristics. The set partitioning process can be implemented using the following multi-dimensional joint matching strategy: For each target computing task, the resource demand of each resource type is mapped to the corresponding resource demand range, generating a resource demand range vector; then, based on vector similarity calculation, target computing tasks with the same resource demand range vector are grouped into the same target computing task set for unified scheduling and management. Grouping target computing tasks according to resource demand ranges simplifies the subsequent server resource matching process and improves the efficiency of batch scheduling.

[0074] Step S403: For each set of target computing tasks, match the resource requirement range corresponding to the set of target computing tasks with the resource information of each server.

[0075] Resource information includes the quantity of various resources currently available on the server, such as the number of remaining CPU cores and the remaining random access memory capacity. Resource matching is typically performed by the scheduling system, which compares the total resources required by the target set of computing tasks with the total amount of remaining server resources.

[0076] By matching each set of target computing tasks with server resources, the rational use of server resources is ensured, while avoiding overload or resource waste on any single server.

[0077] Step S404: Based on the resource matching results, determine multiple candidate servers from multiple servers that match the target computing tasks in the target computing task set.

[0078] The candidate server selection employs a multi-stage selection mechanism. First, an initial candidate server set is determined based on set-level matching results. Then, for each server in the initial candidate set, individual task-level resource verification is performed to ensure that the server can meet the independent resource requirements of each task within the candidate server set. Next, load balancing assessment is conducted, excluding servers whose current load rate exceeds a dynamic threshold. Finally, resource fragmentation analysis is performed, prioritizing servers with concentrated resource distribution. By selecting multiple candidate servers, diverse selection criteria can be provided for subsequent scheduling algorithms, thereby further optimizing the allocation of target computing tasks.

[0079] In this embodiment, the resource requirements of the target computing tasks are extracted for each resource type, and then the target computing tasks are classified based on the range of resource requirements, ultimately matching suitable candidate servers. Multiple feasible scheduling schemes can be provided. This mechanism enhances flexibility and fault tolerance, thereby improving the overall reliability and stability of the scheduling.

[0080] In some embodiments, the number of target computing tasks to be scheduled can be multiple; see [link to relevant documentation]. Figure 7 , Figure 7 The diagram illustrates step S102, which involves matching resource requirements with the resource information of each server and determining multiple candidate servers from among them based on the resource matching results. This can also be achieved through steps S501 to S503: Step S501: Obtain the task parameters for each target computation task.

[0081] The task parameters of a target computing task refer to the specific values ​​and attributes that describe the resources and constraints required by the target computing task, including but not limited to the user who issued the task, the task type, the task's execution objective, storage space, runtime, and priority level. The task parameters of a target computing task are used to measure the degree of computing resource demand of the target computing task and serve as the basis for subsequent resource matching.

[0082] Step S502: Based on the task parameters, similar tasks among multiple target computing tasks are grouped into the same target computing task set.

[0083] Similar tasks refer to target computing tasks that have the same or similar resource requirements. For example, target computing tasks can be grouped into the same task set based on a preset quantization threshold. By grouping similar target computing tasks into the same set, the scheduling system can batch process these target computing tasks during subsequent resource matching, reducing redundant computation and decision-making overhead.

[0084] Step S503: For each set of target computing tasks, the resource requirements of the target computing tasks in the set of target computing tasks are matched with the resource information of each server, and multiple candidate servers for the set of target computing tasks are determined from multiple servers based on the resource matching results.

[0085] By matching resources to sets of target computation tasks one by one, suitable server resources can be found more accurately, rather than simply matching based on individual target computation tasks, thus avoiding resource fragmentation. This approach optimizes overall resource utilization, reduces server idle time, and consequently improves the stability and responsiveness of the scheduling system.

[0086] Step S103: Determine the target server from multiple candidate servers based on the historical scheduling records of each candidate server.

[0087] In some embodiments, the server's resource information includes the server's total resources, and the server's historical scheduling records include the resource usage of task groups scheduled to the server, and the matching score of the task groups relative to the server; the matching score is the proportion of the server's available resources to the total resources, and the available resources are the difference between the total resources and the resource usage. See also Figure 8 , Figure 8 The step S103, which determines the target server from multiple candidate servers based on the historical scheduling records of each candidate server, can be achieved through the following steps S601 to S602: Step S601: Update the matching score according to the resource demand to obtain a new matching score.

[0088] Matching score refers to the proportion of available server resources to total resources. By incorporating the resource requirements of the target computing task, the server's matching score can be dynamically adjusted, thereby making the matching score more closely reflect the actual resource allocation needs of the target computing task.

[0089] In some embodiments, the server may include resources of multiple resource types; see [link to documentation]. Figure 9 , Figure 9 Step S601 can be achieved through the following steps S6011 to S6015: Step S6011: Obtain the preset weight for each resource type.

[0090] Preset weights refer to the importance coefficients set for different resource types (such as CPU, memory, and storage) during the scheduling process. Preset weights reflect the degree of influence of different resource types on the overall matching effect; for example, CPU-intensive tasks may be assigned a higher CPU weight, while memory-sensitive tasks may be assigned a higher memory weight. By setting reasonable preset weights, the priority and actual impact of resource allocation can be more accurately reflected, thereby improving the rationality and efficiency of scheduling decisions.

[0091] Step S6012: For each resource type, the sum of the resource demand and the resource usage of that resource type is determined as the target resource usage.

[0092] The target resource utilization is the sum of the resource demand and resource utilization for a given resource type. It represents the total amount of currently used resources and the amount of resources to be requested for that resource type. It is used to assess whether the resources corresponding to a given resource type can meet the demands of a new task. For example, if a server is currently using 70% of its CPU resources, and a new task requests an additional 10% of CPU, then the sum of the resource demand and resource utilization for that resource type will be 80%. By calculating the sum of the resource demand and resource utilization for each resource type, it can be determined whether there are sufficient remaining resources to support the execution of the newly requested task.

[0093] Step S6013: The difference between the total resource quantity of the resource type and the target resource occupancy of the resource type is determined as the available resource quantity of the resource type.

[0094] Available resources, or the difference between the total resources of a resource type and its target resource usage, are calculated by subtracting the sum of the resource demand and resource usage of the resource type from the total resources of that resource type. This difference represents the server's remaining capacity for the resource type and serves as a key indicator of whether a resource type is schedulable. For example, if a server has 64GB of total memory and the sum of the resource demand and resource usage of a resource type is 56GB, the difference between the total resources of the resource type and the sum of the resource demand and resource usage is 8GB.

[0095] Step S6014: The proportion of available resources of the resource type to the total resources of the resource type is determined as the matching score of the resource type.

[0096] Resource type matching score, which is the ratio of available resources of a resource type to its total resources, is a quantitative indicator calculated based on the ratio of the difference between the total resources of a resource type and its target resource usage to the total resources of that resource type. It measures the degree of fit between the current resource status and the target computing task requirements. A higher ratio of available resources to total resources indicates more abundant resources and a better match; conversely, a lower ratio indicates a poorer match. By introducing the ratio of available resources to total resources, quantitative comparisons can be made among multiple candidate servers, thereby enabling more accurate scheduling decisions.

[0097] Step S6015: Determine a new matching score based on the preset weight of each resource type and the matching score of each resource type.

[0098] Based on the preset weights and matching scores for each resource type, the determined new matching score is a comprehensive score calculated by combining the preset weights of each resource type with the proportion of available resources of that resource type to the total resources of that resource type, through a weighted summation. The new matching score reflects the ability of the entire server or cluster represented by the new matching score to support a specific task under the current load. For example, in a scenario where the preset weight for CPU resources is 0.4, and the proportion of available CPU resources to the total resources of that resource type is 0.8; the preset weight for memory resources is 0.3, and the proportion of available memory resources to the total resources of that resource type is 0.7; and the preset weight for storage resources is 0.3, and the proportion of available storage resources to the total resources of that resource type is 0.9; then, based on the preset weights and matching scores of each resource type, the calculated new matching score is 0.4 × 0.8 + 0.3 × 0.7 + 0.3 × 0.9 = 0.8. Using this method, servers can be evaluated across multiple dimensions, and the most suitable resource allocation scheme can ultimately be selected.

[0099] In this embodiment, a weighted calculation is performed by obtaining the preset weights of each resource type and combining them with the sum of the resource demand and resource usage of each resource type, the difference between the total resource quantity and the target resource usage of each resource type, and the proportion of the available resource quantity of each resource type to its total resource quantity. Based on the preset weights and matching scores of each resource type, a new matching score is generated. This process, by integrating multiple factors, more comprehensively reflects the actual availability of server resources, improves resource utilization, further reduces redundant calculations and database access operations, and significantly enhances the response speed and overall performance of the scheduling system.

[0100] Step S602: Determine the target server from multiple candidate servers based on the new matching score of each candidate server.

[0101] The new matching score is the result of adjusting the original matching score based on the resource requirements of the target computing task. By comparing the new matching scores of each candidate server, the server most suitable for the target computing task can be selected as the target server. For example, for a target computing task that requires high CPU resources, the server with the highest new matching score will be selected. That is, the server with the highest new matching score will meet the resource requirements while still having a large amount of spare resources to ensure the stability of the target computing task.

[0102] In actual deployment, the scheduler in the electronic device sorts candidate servers based on the new matching score and prioritizes the server with the highest score for task allocation. This process by the scheduler improves task scheduling efficiency and effectively prevents overload on certain servers caused by frequently receiving resource-intensive tasks.

[0103] Step S104: Send a task scheduling instruction to the target server, wherein the task scheduling instruction indicates that the target computing task is scheduled to the target server.

[0104] Once the target server is identified, a task scheduling instruction is generated and sent to the target server via a communication protocol (such as REST API, gRPC, etc.). Upon receiving the task scheduling instruction, the target server starts a task instance according to the specified resource configuration, such as creating a new container, allocating a virtual machine instance, or starting a batch job. The task scheduling instruction can also include additional information such as the priority, timeout settings, and dependencies of the target computing task, allowing the target server to execute the target computing task more precisely.

[0105] In practical implementation, the method of sending task scheduling instructions can be optimized according to actual needs, such as using asynchronous message queues or streaming transmission. The scheduler in the electronic device adopts these methods to cope with the scheduling pressure in high-concurrency scenarios. To ensure the consistency and reliability of scheduling, the scheduler in the electronic device can update cached data after task scheduling is completed and synchronize the scheduling results back to the database. The scheduler in the electronic device forms a closed-loop feedback mechanism through these operations.

[0106] The server cluster task processing method provided in this application effectively solves the problems of redundant calculations, frequent database queries, and low scheduling efficiency in the prior art by setting up a cache in the server cluster to store the resource information and historical scheduling records of each server, and performing resource matching and scheduling decisions based on the cached data. Specifically, it integrates multi-source data through cache merging technology to reduce the frequency of database access; reduces computational overhead through an intermediate result reuse mechanism; and optimizes the speed and accuracy of scheduling decisions through multi-level indexes and graph structures. In summary, the server cluster task processing method provided in this application significantly improves scheduling performance, increases resource utilization, and enhances the stability and scalability of the scheduling system.

[0107] In some embodiments, in response to detecting a server resource state change event, resource change information corresponding to the server resource state change event may be obtained, or in response to detecting a demand change event of a target computing task scheduled to the server may be obtained, resource change information corresponding to the demand change event may be obtained; then, the target data segment corresponding to the resource change information in the cache may be determined; then, the target data segment in the cache may be updated using the resource change information.

[0108] Server resource status change events refer to events in which the available resources of a server (such as CPU, memory, and storage) change, such as server expansion, fault recovery, and load changes. Target computing task requirement change events refer to events in which the resource requirements of a task already deployed on the server change due to business needs or user operations, such as task priority increases or increased resource requests.

[0109] Resource change information is a detailed description of an event, including metadata such as resource status before and after the change, task parameters, and timestamps. By capturing and parsing resource change information, the scheduling system can quickly identify which servers or tasks have changed, thereby determining whether to update the relevant data in the cache and ensuring that scheduling decisions are based on the latest resource status.

[0110] To identify target data segments, the system searches based on key fields in the resource change information (such as server ID, task ID, and resource type) to determine which target data segments need to be updated or replaced. Then, it writes the resource status or task requirements to the corresponding location in the cache to ensure that subsequent scheduling operations can make decisions based on the latest data.

[0111] In this embodiment, by updating the target data segment in the cache with resource change information, it can be ensured that the scheduling system always uses the latest and most accurate data for resource allocation decisions. This operation of updating the target data segment in the cache with resource change information can significantly reduce redundant calculations and invalid queries, thereby improving scheduling efficiency and resource utilization, and ultimately optimizing the performance of the entire cloud server scheduling system.

[0112] In some embodiments, the resource information and version number of the historical scheduling record of each server can be obtained, and a verification tag can be generated for each server. Then, the version number is mapped to the resource information and historical call record of the server and stored in the cache, and the verification tag is mapped to the resource information and historical call record of the server and stored in the cache.

[0113] A version number is a number or string used to identify the status of data updates, typically to ensure data consistency. When server resource information and historical scheduling records change, the version number is updated to quickly identify whether the data is valid during subsequent scheduling processes.

[0114] Verification tags are a set of verification data generated based on the server's resource information and historical scheduling records. They are used to verify whether the resource information and historical scheduling records used during the scheduling process are still accurate. To achieve this function, verification tags can be generated using hash values, signatures, or other encryption methods to ensure that even if the resource information and historical scheduling records have not been tampered with, incorrect usage due to version inconsistencies can still be detected.

[0115] Mapping and storing version numbers with resource information and historical scheduling records in the cache helps to quickly locate and verify the server's status during task scheduling. Similarly, mapping and storing verification tags with resource information and historical scheduling records enables quick determination of data validity during scheduling, avoiding the use of outdated or incorrect information.

[0116] In this embodiment, by introducing version numbers and verification tags, and mapping and caching version numbers and verification tags with server resource information and historical scheduling records, the server status can be efficiently verified during task scheduling, avoiding the use of invalid or outdated data, thereby improving scheduling efficiency and accuracy, and thus optimizing the overall resource utilization and stability of the cloud server.

[0117] In some embodiments, after sending a task scheduling instruction to the target server, the task execution result of the target server executing the target computing task can also be obtained; then, the task execution result is written into the cache as a scheduling record of the task scheduling instruction, and the scheduling record is synchronized from the cache to the database; here, the database is used to store the resource information of each server in the server cluster and the historical call records.

[0118] The task execution result refers to the output or status information generated by the target server during task execution after receiving the task scheduling instruction and actually running the target computation task according to the instruction. For example, during task execution, there may be states such as task success, failure, partial completion, and timeout, as well as specific execution logs, return values, and performance metrics (such as CPU utilization and memory usage). The task execution result of the target server can serve as an important basis for evaluating the rationality of task scheduling and is also key input data for subsequent optimization of scheduling strategies.

[0119] The database serves as persistent storage, used to permanently store resource information from the server cluster (such as the CPU, memory, storage capacity, and current load of each server) and historical call records (i.e., records of all past task scheduling). This resource information and historical call records are crucial for subsequent resource allocation, fault recovery, performance analysis, and cost accounting. Simultaneously, a data flow exists between the cache and the database. The cache acts as the scheduling system's short-term memory, responsible for quickly responding to scheduling requests; while the database acts as long-term memory, responsible for data persistence and global consistency management. The cache and database work together to improve the scheduling system's response speed and ensure data reliability and integrity.

[0120] In this embodiment, by obtaining the task execution result after the task scheduling instruction is issued, writing the scheduling record to the cache, and then synchronizing it to the database, a closed-loop feedback of the scheduling process is achieved. This operation of obtaining the task execution result after the task scheduling instruction is issued, writing the scheduling record to the cache, and then synchronizing it to the database effectively reduces redundant queries and calculations, thereby accelerating the scheduling response speed and improving the efficiency and stability of the entire cloud server scheduling system.

[0121] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0122] The server cluster task processing method provided in this application is widely used in cloud computing scenarios with high requirements for resource scheduling efficiency and cluster utilization. Such environments typically need to handle a variety of mixed workloads, including online business services, large-scale data processing, and high-performance computing. These workloads share the core characteristics of high task arrival time, heterogeneous resource demand patterns, and sensitivity to scheduling latency.

[0123] From a system performance perspective, the server cluster task processing method provided in this application significantly optimizes the resource scheduling process by constructing an intelligent caching and decision-making system. When dealing with sudden surges in tasks, the average latency from submission to successful scheduling of the target computing task can be controlled at an extremely low level, ensuring the responsiveness of core business services and preventing resource supply delays from becoming a system bottleneck. The server cluster task processing method provided in this application is dynamically adaptable, effectively addressing complex scenarios such as elastic scaling of the server cluster, fluctuations in individual node resources, and mixed deployment of tasks with different priorities and resource characteristics. This allows for improved overall cluster resource utilization density and throughput while ensuring service level agreements are maintained.

[0124] Through intelligent cache merging and dynamic update mechanisms, the server cluster task processing method provided in this application embodiment achieves refined scheduling decisions. It can automatically identify high-value, reusable intermediate computation results and provide near real-time matching for routine tasks, while concentrating complex computing resources on processing unconventional or high-value scheduling decision points. The server cluster task processing method provided in this application embodiment supports private cloud, public cloud, and hybrid cloud deployment modes, meeting the needs of enterprises at different stages of development for infrastructure flexibility, cost, and control. Furthermore, the server cluster task processing method provided in this application embodiment provides a flexible policy configuration interface, allowing administrators to adjust binning strategies and caching behaviors according to business objectives (such as optimal energy efficiency, minimal resource fragmentation, or fastest deployment speed), achieving customized optimization of the scheduling system.

[0125] Next, the implementation details of the server cluster task processing method provided in the embodiments of this application will be described.

[0126] The technical architecture of the server cluster task processing method provided in this application embodiment is based on a deeply optimized cache management system. Combined with a resource status event-driven dynamic update mechanism, it constructs an efficient, low-latency scheduling process. The server cluster task processing method provided in this application embodiment consists of core steps such as data acquisition and integration, unified policy cache construction, dynamic cache update, intelligent matching, and decision feedback. Through collaborative operation, it achieves an intelligent scheduling strategy of "data preprocessing - intermediate result reuse - on-demand precise update".

[0127] See Figure 11 , Figure 11 This is a schematic diagram of the architecture implementation flow of the server cluster task processing method provided in the embodiments of this application. The following refers to... Figure 11 The steps shown in the diagram are explained.

[0128] Step S801, data acquisition.

[0129] In some embodiments, data acquisition is achieved through the following methods: First, server resources (i.e., the resource information of the aforementioned servers), task requirements (i.e., the resource requirements of the aforementioned target computing task), and historical scheduling records are obtained in real time through a scheduling system. For example, dynamic resource metrics of each server are obtained in real time through a scheduling system (such as Kubernetes), including but not limited to CPU core utilization, memory usage and total capacity, GPU utilization, disk input / output (I / O) throughput, and network bandwidth. Simultaneously, the resource request specifications of newly arriving tasks are detected in real time through the task queue, such as the required number of CPU cores, memory size, number of GPUs, storage space, task priority, and maximum allowed execution time. Furthermore, historical scheduling records are obtained in batches through the scheduling system's database or log interface, such as successful task-server matching mappings over a certain period, actual utilization data after resource allocation, and scheduling failure cases and attribution information. This historical data can be synchronized using a scheduled task (such as every morning) to build a data foundation for analysis and optimization.

[0130] Next, the acquired raw data is organized and normalized to form a structured data stream. For example, server resources (CPU, memory, storage, etc.) and task requirements (such as application type and required resources) are abstracted into a standardized data structure. The format of the server resource structure is as follows:

[0131] Reference format for task requirement structure:

[0132] Step S802, cache construction.

[0133] In some embodiments, cache construction is implemented as follows: First, server resources, task requirements, and historical scheduling records obtained during the data acquisition phase are merged into a unified cache unit (as shown in the diagram). The goal of this phase is to merge multi-source data for binning strategies and reduce redundant calculations. For example, the unified cache integrates server resource information, task resource requirements, and historical scheduling records, and is organized and managed using a graph structure. In the graph structure, servers are used as nodes, and the binning relationships between tasks and servers are used as edges, enabling explicit expression of task allocation relationships and reuse of binning calculation results.

[0134] The data stored in a node (i.e., a server node) includes: 1) Basic attributes: Server ID (unique identifier). 2) Resource configuration: CPU, memory, and total storage. 3) Running status: Current CPU / memory utilization and load index. 4) Scheduling records: List of assigned task IDs and last update time.

[0135] The data stored in the edge (task-server binning relationship) includes: 1) Task identification information: Task ID, belonging task group ID. 2) Task resource requirements: Required CPU, memory, storage, and priority. 3) Binning calculation results: Total resource usage, matching score, and task allocation status. 4) Execution record: Execution status and timestamp.

[0136] This graph-structured cache supports node-edge-based association retrieval, enabling rapid location of candidate server nodes and reuse of existing matching results. Furthermore, the graph-structured cache explicitly expresses the topological relationship between resources and demands, allowing for rapid traversal and evaluation of the suitability of different servers for specific tasks, providing a direct data foundation for subsequent intelligent matching.

[0137] Next, we will explain the key calculation results in the cache boxing strategy.

[0138] For example, see Figure 12 , Figure 12 This is a schematic diagram of the cache structure of the server cluster task processing method provided in the embodiments of this application. Figure 12The example demonstrates the matching relationship between task groups and servers, including key information such as task group ID, server ID, total CPU usage, total memory usage, and matching score. To avoid redundant calculations for similar task and server combinations during scheduling, key intermediate results from the binning strategy execution process are pre-calculated and stored, such as the total resource usage of task combinations and matching scores. For common task combinations or resource demand patterns, the theoretical total resource usage and remaining resource distribution of each task combination or resource demand pattern on each server are pre-calculated. Then, based on a multi-factor scoring model (considering resource suitability, load balancing, energy efficiency, etc.), the matching score between tasks and servers is pre-calculated or cached. These intermediate results are cached on a server group basis, forming a complete dataset that can be directly used for scheduling decisions. Finally, an index is created for the intermediate cached calculation results. For example, a multi-level index structure is designed on top of the cache to support rapid location of task characteristics to server nodes. The index is constructed based on server attributes (CPU, memory, storage, etc.) and task resource demand characteristics. First, a first-level index is created based on CPU ranges, and then filtering is performed level by level along the memory and storage dimensions to quickly select a set of candidate servers that meet the criteria.

[0139] Step S803, scheduling decision.

[0140] In some embodiments, scheduling decisions are implemented as follows: First, the optimal server is quickly located based on cached data. For example, a multi-factor scoring model can be used to comprehensively score candidate servers, ensuring the selection of the optimal server resources, and the results of the multi-factor scoring model are cached under the corresponding index. The multi-factor scoring model comprehensively considers the following key factors: 1) Resource matching evaluation (weight 40%): CPU resource matching (calculated based on the matching degree between the available CPU of the server and the task requirements); memory resource matching (evaluating the adaptability of memory resources); special resource matching (special evaluation for special resources such as GPU and storage); 2) Load balancing considerations (weight 30%): Current CPU load rate (prioritizing servers with loads below a preset load threshold); memory usage pressure (avoiding servers with excessively high memory usage); I / O load status (comprehensively considering disk and network I / O pressure); 3) Business strategy factors (weight 30%): Priority matching (high-priority tasks are preferentially allocated to high-performance servers); affinity rules (considering the affinity and anti-affinity requirements between tasks); cost optimization (prioritizing lower-cost resources while meeting performance requirements).

[0141] The scoring process fully utilizes pre-calculated results in the cache, avoiding the performance overhead of real-time computation. The scheduling system maintains a cache of scoring results, allowing historical scores to be reused directly for similar task patterns, further improving decision-making efficiency.

[0142] Next, for large-scale task scheduling scenarios, a sharded parallel processing architecture is adopted. For example, task sharding strategies include: sharding by resource characteristics (e.g., classifying tasks into CPU-intensive, memory-intensive, I / O-intensive categories); sharding by priority (e.g., assigning tasks of different priorities to independent scheduling channels); and sharding by resource requirement (e.g., tiered processing based on task resource requirements). Code format reference:

[0143] For example, a multi-level parallel scheduling system is established based on sharding. Each scheduler instance is responsible for a task group of a specific shard, and decision-making efficiency is improved through specialized scheduling algorithms. When a scheduler instance completes its task group ahead of schedule, it can automatically obtain tasks to be processed from other busy instances, eliminating resource idleness. During scheduling, the throughput and latency of each scheduling channel are monitored in real time, and resource allocation is dynamically adjusted to ensure optimal overall performance. When a scheduling channel fails, tasks are automatically rerouted to healthy channels; under high load, degradation strategies are automatically activated to ensure the scheduling needs of core business operations.

[0144] Finally, the scheduling results are written to the cache and synchronized to the database, forming a closed loop. For example, after a scheduling decision is made, a complete closed-loop processing flow is established: First, the scheduling results are written to the cache system to ensure timely responses to subsequent queries. Simultaneously, the results are asynchronously synchronized to the persistent database to ensure reliable data storage. The synchronization process employs transactional guarantees to ensure eventual consistency between the cache and the database. Next, actual operational data after scheduling execution is collected, including changes in resource utilization, task execution performance indicators, and statistics on the accuracy of scheduling decisions. This feedback data is used to optimize subsequent scheduling decisions, forming a virtuous cycle of continuous improvement. Next, the weight parameters of the multi-factor scoring model are dynamically adjusted based on the feedback data, enabling the scheduling strategy to adapt to changes in business needs. Finally, a comprehensive processing system is established to monitor various key indicators of scheduling decisions. When a decline in scheduling quality or an abnormal pattern is detected, an automatic warning is issued, and corresponding optimization processes are triggered.

[0145] Step S804, dynamic update.

[0146] In some embodiments, the goal of dynamic updates is to establish an efficient cache synchronization mechanism to ensure that cached data can be updated promptly and accurately when the resource status in the cloud environment changes, while guaranteeing data consistency and reliability. First, cache update logic is triggered by detecting resource status change events. For example, agents deployed on each node of the cluster continuously detect resource status change events, such as server crashes, server scaling, task completion, and task priority adjustments. When a resource status change event is detected, the event producer publishes the event to the message bus, and the cache update service, acting as a consumer, receives these events. For instance, when server S-001 crashes, all tasks in the cache that depend on S-001 are recalculated.

[0147] After triggering the cache update logic, only the affected data segments are updated. For example, upon receiving a resource state change event, an impact scope analysis is first performed to accurately identify the cached data segments that need to be updated. The update process uses an incremental approach, processing only the affected data entries (i.e., the target data segments mentioned above) to avoid the performance overhead of a full rebuild. For instance, when task T-001 migrates from S-001 to S-002, only the cache records for T-001 are updated, rather than a full rebuild. Code format reference:

[0148] Finally, version numbers are added to the cached data. For example, to ensure consistency of cached data in a distributed environment, a multi-version concurrency control mechanism is introduced. The version management strategy is as follows: each cached entry is accompanied by a version number in the format "major version.minor version", for example, v1.0, v1.1. Update operations must be based on the latest version. When version conflicts occur, a first-commit-first strategy is adopted, such as committer priority, timestamp-based latest version priority, or weighted decision based on business priority. The specific strategy can be configured according to the business scenario. For example, for cached data related to scheduling decisions, a first-commit-first strategy is usually adopted to ensure system throughput; for resource status data, a timestamp-first strategy may be used to ensure data timeliness. For example, during the scheduling decision process, the scheduling system performs version verification at key nodes. Before the scheduler makes a decision using cached data, it verifies whether the version number of the data used is consistent with the latest version. If a version inconsistency is found, it means the data has expired, triggering a rollback or retry mechanism.

[0149] When a rollback is triggered, a rollback mechanism can be used. This mechanism includes the following steps: first, suspend the current scheduling process based on expired data; then, obtain the latest version of cached data; and finally, re-execute the scheduling decision based on the new data. For scheduling decisions already made based on expired data, the scheduling system will record rollback logs to ensure the atomicity of resource allocation.

[0150] The retry mechanism employs an exponential backoff strategy. Upon detecting a version conflict, the scheduling system will retry the operation after a random delay to avoid a new round of conflicts caused by multiple nodes retrying simultaneously. There is an upper limit to the number of retries. If the operation still fails after reaching the maximum number of retries, an upgrade process will be implemented, which may involve manual intervention or switching to a downgraded solution.

[0151] Through the above complete scheduling decision-making mechanism, a closed-loop management system is achieved, from intelligent matching and parallel processing to continuous optimization, ensuring that efficient resource scheduling capabilities are maintained in a complex and ever-changing cloud environment.

[0152] See Figure 13 , Figure 13 This is a schematic diagram of the overall framework of the server cluster task processing method provided in the embodiments of this application. The following refers to... Figure 13 The steps shown in the diagram are explained.

[0153] In step S901, the task is submitted.

[0154] In some embodiments, users submit tasks (i.e., the target computing tasks mentioned above) through the scheduling system interface. The task description includes complete resource requirements, including but not limited to the required number of CPU cores, memory capacity, storage space, network bandwidth, and possible accelerator resource requirements. The task also carries business-level attributes such as priority identifiers and execution time constraints. After receiving the task, the scheduling system performs preliminary syntax verification and specification parsing, converting the task into an internally unified task description to prepare for subsequent scheduling decision-making processes.

[0155] In step S902, it is determined whether the cache has been hit.

[0156] In some embodiments, servers that meet certain criteria (such as nodes with low load and high resource matching) are preferentially retrieved from the cache. Cache hit determination employs a hierarchical retrieval strategy, sequentially performing precise matching through a multi-level index structure and a graph-structured cache. First, a hierarchical retrieval is performed based on a pre-built multi-level index structure, which uses a three-tiered design from coarse to fine, rapidly narrowing down the candidate server pool through progressive filtering. Level 1 (CPU Layer): A segmented index is created based on the range of available CPU cores on the server, for example, divided into segments such as 0-7 cores, 8-15 cores, 16-31 cores, and 32 cores and above. This layer primarily excludes server nodes with insufficient computing power. Level 2 (Memory Layer): Within the server set filtered by the CPU layer, a secondary index partition is created based on available memory capacity. This layer is responsible for excluding servers with insufficient memory resources. Level 3 (Storage Layer): Based on the filtering of the first two layers, a final filter is performed based on storage space availability, excluding servers whose storage resources do not meet the requirements.

[0157] During the retrieval process, task resource requirements are used as query conditions, and hierarchical filtering is performed sequentially according to the field order of "CPU → Memory → Storage". Each level returns a set of server nodes that meet the current resource conditions, and the intersection of the results from each level is finally output as the candidate server set. For example, there are three servers in the current cache: S1: available CPU=12, memory=20GB, storage=300GB; S2: available CPU=6, memory=40GB, storage=500GB; S3: available CPU=18, memory=10GB, storage=200GB. When a task with resource requirements of 8 or more CPU cores, 16 or more GB of memory, and 100 or more GB of storage is received, the following hierarchical filtering is performed: 1) CPU layer filtering: S2 (6 cores) is excluded, and S1 (12 cores) and S3 (18 cores) are retained; 2) Memory layer filtering: S3 (10 GB) is excluded from {S1, S3}, and S1 (20 GB) is retained; 3) Storage layer filtering: S1 (300 GB) meets the conditions, and the final candidate set is {S1}.

[0158] Next, after obtaining the candidate server set, deep matching verification is performed in the graph structure cache. In the graph structure, servers exist as nodes, and the scheduling relationship between tasks and servers is stored as edges. Each edge contains metadata such as resource usage details, matching score, and execution label. The matching verification process includes: traversing all associated edges of the candidate server nodes to obtain the feature data of historical scheduled tasks; then, calculating the feature similarity between the current task and historical tasks in terms of resource requirements, priority, and execution constraints; then, using Euclidean distance or cosine similarity algorithms for quantitative evaluation; when the multi-level index retrieval returns a non-empty candidate set, the graph structure matching similarity reaches the threshold requirement, and the cached data version is consistent with the current cluster state, it is determined that the cache has hit. If the cache has hit, proceed to step S903 to perform merging and binning and reuse intermediate results.

[0159] In some embodiments, the process of reusing intermediate results is as follows: For each candidate task group, key information (server ID, current resource usage baseline, historical matching score, etc.) of the candidate task group is directly obtained from the cache. The resource requirements of the current task are then superimposed with these intermediate results to form a merged binning scheme. For example, G-001 originally used 8 CPU cores, and with the current task requiring 2 cores, a total of 10 cores are used; G-001 originally used 16GB of memory, and with the current task requiring 4GB, a total of 20GB is used. Subsequently, a new matching score is calculated through a multi-factor scoring model, comprehensively considering optimization objectives such as resource utilization, load balancing, and energy efficiency ratio, and finally, the optimal server is selected based on the updated score.

[0160] If the cache misses, proceed to step S904 to perform non-merge binning and cache the data.

[0161] In some embodiments, if the cache is not hit, a full database query will be triggered to obtain the latest cluster resource status. This status will then be processed sequentially through a scheduling filter for resource compliance checks, a sorter for server priority ranking, and finally, the optimal server will be selected based on multi-dimensional evaluation criteria. Simultaneously, the scheduling system will update the cache system with the intermediate computation results and final decision scheme generated during this scheduling process, enriching the cached content for reuse in subsequent tasks.

[0162] Step S905, dynamic decision-making.

[0163] In some embodiments, dynamic decision-making is based on a multi-factor scoring model, comprehensively considering factors such as task priority, real-time server load status, historical scheduling scores, resource matching degree, and energy efficiency indicators. This multi-factor scoring model employs a weighted scoring mechanism, accurately calculating the fit score between each candidate server and the task to be scheduled through weight allocation. Simultaneously, to improve the efficiency of large-scale task scheduling, an intelligent task grouping strategy is adopted, classifying tasks with similar resource requirements or the same priority into the same task group; a parallel processing framework is used to batch-allocate similar tasks to the optimal server cluster. This batch processing mode not only significantly reduces redundant computation overhead but also optimizes overall performance by improving resource locality. Furthermore, a dynamic weight adjustment mechanism is established to automatically optimize the weight allocation of each factor in the multi-factor scoring model based on real-time detection data, ensuring that the scheduling strategy always maintains the best match with current business needs.

[0164] Step S906: Submit the result and update the cache.

[0165] The scheduling results are written to the database and synchronized to the cache, while relevant intermediate results are updated (such as adjusting server resource usage status).

[0166] In some embodiments, a two-phase commit protocol can be used to ensure the reliable persistence of scheduling results. First, the scheduling decision result is atomically written to the core database, completing transactional storage. Then, the updated data is distributed to the caching system through an asynchronous synchronization mechanism, ensuring eventual consistency between the cache and the main database. During the cache update process, relevant intermediate results are synchronously updated, including adjusting server resource usage, updating task group resource aggregation data, and revising matching score records.

[0167] In some embodiments, a complete closed-loop learning mechanism is constructed to provide feedback on the actual execution effect data of scheduling decisions, including key indicators such as task execution time, changes in resource utilization, and performance achievement rate. This feedback data is used to optimize the parameter configuration of the multi-factor scoring model and guide the adjustment of caching strategies. By detecting core indicators such as cache hit rate, scheduling accuracy, and resource utilization, a self-learning capability for continuous optimization is established.

[0168] The task processing method for server clusters provided in this application has the following beneficial effects: The task processing method for server clusters provided in this application achieves efficient sharing and reuse of intermediate scheduling results by constructing a unified cache structure and dynamic update mechanism, resulting in significant technical effects and application value in many aspects. (1) Significant improvement in scheduling performance: By establishing a multi-level index structure and graph structure cache, the scheduling time is significantly reduced to 10ms~50ms, achieving an 80%~95% improvement in scheduling speed. In the traditional scheme, each scheduling task needs to query the database in real time and recalculate the bin packing strategy. The single scheduling time is usually in the range of 100ms~1000ms, and it is significantly extended with the increase of task complexity and database load. At the same time, the local caching mechanism effectively reduces more than 90% of database query requests, greatly reduces the database access pressure, avoids the query backlog and performance bottleneck problems caused by high frequency database access in the traditional scheme, and improves the overall throughput. (2) Comprehensive optimization of resource utilization: By caching historical scheduling records and intermediate calculation results, the optimal allocation scheme can be intelligently reused, effectively reducing resource fragmentation and improving the average utilization of core resources such as CPU, memory, and storage. Traditional schemes lack effective caching and intermediate result reuse mechanisms, requiring repeated calculation of resource matching schemes for similar tasks, resulting in fragmented resource allocation and unbalanced server load. Task combination and resource demand superposition realize the intensive use of server resources; continuous optimization of the multi-factor scoring model ensures the best match between resource allocation and task demand. (3) Comprehensive enhancement of system stability: Through the organic combination of local caching and parallel processing technology, stable scheduling performance can be maintained even in high-concurrency scenarios, significantly reducing the task failure rate. In particular, the event-driven dynamic update mechanism can perceive resource status changes in real time, ensuring strict synchronization between cached data and actual resource status, effectively avoiding scheduling decision errors caused by data inconsistency. In addition, the introduction of version control and rollback mechanisms further enhances fault tolerance and data consistency assurance.

[0169] It is understood that in the embodiments of this application, if data related to user information or enterprise information is involved, when the embodiments of this application are applied to specific products or technologies, it is necessary to obtain user permission or consent, or to obfuscate this information in order to eliminate the correspondence between this information and the user; and the collection and processing of related data should strictly comply with the requirements of relevant laws and regulations when applied in practice, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0170] The following description continues to illustrate the exemplary structure of the server cluster task processing device 455 provided in the embodiments of this application as a software module. In some embodiments, such asFigure 2 As shown, the software modules in the server cluster task processing device 455 stored in the memory 450 may include: a receiving module 4551, configured to receive a target computing task to be scheduled, wherein the target computing task includes resource requirements; a determining module 4552, configured to perform resource matching between the resource requirements and the resource information of each server, and determine multiple candidate servers from the multiple servers based on the resource matching results; the determining module 4552 is further configured to: determine a target server from the multiple candidate servers based on the historical scheduling records of each candidate server; and an execution module 4553, configured to send a task scheduling instruction to the target server, wherein the task scheduling instruction instructs the target computing task to be scheduled to the target server.

[0171] In some embodiments, the resource information includes the available resource information of the server; the available resource information includes the available resource quantity of multiple resource types; the determining module 4552 is further configured to: match the available resource quantity of the server with the resource demand quantity of the corresponding resource type in the resource demand quantity to obtain a resource matching result; in response to the resource matching result indicating that the available resource quantity of the server is greater than or equal to the resource demand quantity of the corresponding resource type in the resource demand quantity, determine the server as a candidate server.

[0172] In some embodiments, the available resource information of each server is stored in the cache in the form of a multi-level index, the multi-level index including the available resource quantity of multiple resource types in the available resource information and the server identifier; the determining module 4552 is further configured to: for each server entry in the multi-level index, match the available resource quantity of each resource type in the server entry with the resource demand quantity of the corresponding resource type in the resource demand quantity to obtain a resource matching result; in response to the resource matching result indicating that the available resource quantity of each resource type in the server entry is greater than or equal to the resource demand quantity of the corresponding resource type in the resource demand quantity, determine the server corresponding to the server identifier in the server entry as a candidate server.

[0173] In some embodiments, the server's resource information includes the server's total resources, and the server's historical scheduling records include the resource usage of task groups scheduled to the server, and the matching score of the task groups relative to the server; the matching score is the proportion of the server's available resources to the total resources, and the available resources are the difference between the total resources and the resource usage; the determining module 4552 is further configured to: update the matching score according to the resource demand to obtain a new matching score; and determine a target server from the plurality of candidate servers according to the new matching score of each candidate server.

[0174] In some embodiments, the server includes resources of multiple resource types; the determining module 4552 is further configured to: obtain a preset weight for each resource type; for each resource type, determine the sum of the resource demand and the resource usage of the resource type as the target resource usage; determine the difference between the total resource amount of the resource type and the target resource usage of the resource type as the available resource amount of the resource type; determine the ratio of the available resource amount of the resource type to the total resource amount of the resource type as the matching score of the resource type; and determine the new matching score based on the preset weight and the matching score of each resource type.

[0175] In some embodiments, the cache takes the form of a graph structure; the determining module 4552 is further configured to: determine, based on the resource demand, a target edge corresponding to a task that satisfies the resource similarity condition of the target computing task from the graph structure; wherein, in the graph structure, the server is used as a node, and the scheduling relationship between the task and the server is used as an edge; the node includes the resource information and the historical scheduling record; and the server connected to the target edge is determined as the candidate server.

[0176] In some embodiments, the number of target computing tasks to be scheduled is multiple; the server includes resources of multiple resource types; the determining module 4552 is further configured to: for each resource type, obtain the resource requirement of each target computing task under the resource type; based on the resource requirement and multiple preset resource requirement intervals, divide the multiple target computing tasks into at least one target computing task set; wherein, each target computing task set corresponds to a resource requirement interval; for each target computing task set, perform resource matching between the resource requirement interval corresponding to the target computing task set and the resource information of each server; and determine multiple candidate servers from the multiple servers that match the target computing tasks in the target computing task set according to the resource matching results.

[0177] In some embodiments, the apparatus further includes: a data update module, configured to, in response to detecting a server resource status change event, obtain resource change information corresponding to the server resource status change event, or, in response to detecting a demand change event of a target computing task scheduled to the server, obtain resource change information corresponding to the demand change event; determine a target data segment in the cache corresponding to the resource change information; and update the target data segment in the cache using the resource change information.

[0178] In some embodiments, the apparatus further includes: a data storage module, configured to, after sending a task scheduling instruction to the target server, obtain the task execution result of the target server executing the target computing task; write the task execution result as a scheduling record of the task scheduling instruction into the cache; and synchronize the scheduling record from the cache to a database; the database is configured to store resource information of each server in the server cluster and the historical call records.

[0179] In some embodiments, the number of target computing tasks to be scheduled is multiple; the determining module 4552 is further configured to: obtain task parameters for each target computing task; based on the task parameters, divide similar tasks among the multiple target computing tasks into the same target computing task set; the determining module 4552 is further configured to: for each target computing task set, perform resource matching between the resource requirements of the target computing tasks in the target computing task set and the resource information of each server, and determine multiple candidate servers for the target computing task set from the multiple servers according to the resource matching results.

[0180] In some embodiments, the apparatus further includes: an information storage module, configured to acquire resource information and version number of historical scheduling records for each server, and generate a verification tag for each server; the verification tag is used to verify the validity of the resource information and historical scheduling records of the server during task scheduling; the processing module is further configured to: map the version number to the resource information and historical call records of the server respectively and store them in the cache, and map the verification tag to the resource information and historical call records of the server respectively and store them in the cache.

[0181] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment described above, and has similar beneficial effects as the method embodiment; therefore, it will not be repeated. For technical details not disclosed in this apparatus embodiment, please refer to the description of the method embodiment of this application for understanding.

[0182] This application provides an electronic device, including: a memory for storing computer-executable instructions or computer programs; and a processor for executing the computer-executable instructions or computer programs stored in the memory to implement the above-described method.

[0183] This application provides a computer program product, which includes computer-executable instructions or a computer program stored in a computer-readable storage medium; wherein, when the processor of an electronic device reads the computer-executable instructions or the computer program from the computer-readable storage medium and executes the computer-executable instructions or the computer program, the above-described method is implemented.

[0184] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will perform the aforementioned method, for example, as... Figure 3 The method shown.

[0185] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0186] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0187] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0188] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0189] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A task processing method for a server cluster, characterized in that, The server cluster includes multiple servers, and the server cluster is equipped with a cache for storing resource information of each server and historical scheduling records of the servers; the method includes: Receive a target computing task to be scheduled, wherein the target computing task includes resource requirements; The resource demand is matched with the resource information of each server, and multiple candidate servers are determined from the multiple servers based on the resource matching results. The target server is determined from the plurality of candidate servers based on the historical scheduling records of each candidate server. Send a task scheduling instruction to the target server, wherein the task scheduling instruction instructs the target computing task to be scheduled to the target server.

2. The method according to claim 1, characterized in that, The resource information includes the available resource information of the server; the available resource information includes the available resource quantity of multiple resource types; The step of matching the resource demand with the resource information of each server, and determining multiple candidate servers from the multiple servers based on the resource matching results, includes: The available resources of the server are matched with the resource requirements of the corresponding resource types in the resource requirements to obtain resource matching results; In response to the resource matching results indicating that the available resource quantity of the server is greater than or equal to the resource requirement of the corresponding resource type in the resource requirement, the server is determined as a candidate server.

3. The method according to claim 2, characterized in that, The available resource information of each server is stored in the cache in the form of a multi-level index, and the multi-level index includes the available resource quantity of multiple resource types and the server identifier in the available resource information; The step of matching the available resources of the server with the resource requirements of the corresponding resource types in the resource requirements to obtain resource matching results includes: For each server entry in the multi-level index, the available resource quantity of each resource type in the server entry is matched with the resource demand quantity of the corresponding resource type in the resource demand quantity to obtain a resource matching result; The step of determining a server as a candidate server in response to the resource matching results indicating that the available resource quantity of the server is greater than or equal to the resource requirement of the corresponding resource type in the resource requirement includes: In response to the resource matching result indicating that the available resource quantity for each resource type in the server entry is greater than or equal to the resource demand quantity for the corresponding resource type, the server corresponding to the server identifier in the server entry is identified as a candidate server.

4. The method according to claim 1, characterized in that, The server's resource information includes the server's total resources, and the server's historical scheduling records include the resource usage of task groups scheduled to the server, as well as the matching score of the task groups relative to the server. The matching score is the ratio of the available resources of the server to the total resources, and the available resources are the difference between the total resources and the resource usage. The step of determining the target server from the plurality of candidate servers based on the historical scheduling records of each candidate server includes: The matching score is updated based on the resource demand to obtain a new matching score; The target server is determined from the plurality of candidate servers based on the new matching score of each candidate server.

5. The method according to claim 4, characterized in that, The server includes resources of multiple resource types; updating the matching score according to the resource demand to obtain a new matching score includes: Obtain the preset weight for each resource type; For each resource type, the sum of the resource demand and the resource usage of that resource type is determined as the target resource usage; the difference between the total resource quantity of that resource type and the target resource usage is determined as the available resource quantity of that resource type; and the ratio of the available resource quantity of that resource type to the total resource quantity of that resource type is determined as the matching score of that resource type. The new matching score is determined based on the preset weight of each resource type and the matching score of each resource type.

6. The method according to claim 1, characterized in that, The cache is in the form of a graph structure; The step of matching the resource demand with the resource information of each server, and determining multiple candidate servers from the multiple servers based on the resource matching results, includes: Based on the resource requirements, target edges corresponding to tasks that satisfy resource similarity conditions with the target computing task are determined from the graph structure; wherein, the server is used as a node in the graph structure, and the scheduling relationship between the task and the server is used as an edge; the node includes the resource information and the historical scheduling record; The server connected to the target edge is identified as the candidate server.

7. The method according to claim 1, characterized in that, The number of target computing tasks to be scheduled is multiple; the server includes resources of multiple resource types; The step of matching the resource demand with the resource information of each server, and determining multiple candidate servers from the multiple servers based on the resource matching results, includes: For each resource type, obtain the resource requirements of each target computing task under that resource type; Based on the resource requirements and multiple preset resource requirement ranges, multiple target computing tasks are divided into at least one target computing task set; wherein, each target computing task set corresponds to a resource requirement range. For each set of target computing tasks, the resource requirement range corresponding to the set of target computing tasks is matched with the resource information of each server. Based on the resource matching results, multiple candidate servers that match the target computing tasks in the target computing task set are determined from the multiple servers.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: In response to detecting a server resource status change event, obtain resource change information corresponding to the server resource status change event; or, in response to detecting a demand change event of a target computing task scheduled to the server, obtain resource change information corresponding to the demand change event. Determine the target data segment in the cache corresponding to the resource change information; The target data fragment in the cache is updated using the resource change information.

9. The method according to any one of claims 1 to 7, characterized in that, After sending the task scheduling instruction to the target server, the method further includes: Obtain the task execution result of the target server executing the target computing task; The task execution result is written as a scheduling record of the task scheduling instruction into the cache, and, The scheduling records are synchronized from the cache to the database; the database is used to store resource information of each server in the server cluster and the historical call records.

10. The method according to any one of claims 1 to 7, characterized in that, The number of target computing tasks to be scheduled is multiple; the process of matching the resource requirements with the resource information of each server, and determining multiple candidate servers from the multiple servers based on the resource matching results, includes: Obtain the task parameters for each target computation task; Based on the task parameters, similar tasks among multiple target computing tasks are grouped into the same target computing task set; For each set of target computing tasks, the resource requirements of the target computing tasks in the set are matched with the resource information of each server, and multiple candidate servers for the set of target computing tasks are determined from the multiple servers based on the resource matching results.

11. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Obtain the resource information and version number of the historical scheduling record for each server, and generate a verification tag for each server; the verification tag is used to verify the validity of the resource information and historical scheduling record of the server when scheduling tasks. The version number is mapped to the server's resource information and historical call records respectively and stored in the cache, and the verification tag is mapped to the server's resource information and historical call records respectively and stored in the cache.

12. A task processing device for a server cluster, characterized in that, The server cluster includes multiple servers, and the server cluster is equipped with a cache for storing resource information of each server and historical scheduling records of the servers; the device includes: A receiving module is used to receive a target computing task to be scheduled, wherein the target computing task includes resource requirements; The determination module is used to match the resource demand with the resource information of each server, and determine multiple candidate servers from the multiple servers based on the resource matching results; The determining module is further configured to determine a target server from the plurality of candidate servers based on the historical scheduling records of each candidate server; An execution module is used to send a task scheduling instruction to the target server, wherein the task scheduling instruction indicates that the target computing task is scheduled to the target server.

13. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the task processing method of the server cluster according to any one of claims 1 to 11.

14. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the task processing method of the server cluster according to any one of claims 1 to 11 is implemented.

15. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the task processing method of the server cluster according to any one of claims 1 to 11 is implemented.

Images