Resource scheduling method, apparatus and device

Abstract

The application provides a resource scheduling method, device and equipment, the method comprises the following steps: obtaining a plurality of historical resource scheduling data corresponding to a plurality of users; obtaining the predicted resource demand of each user according to the historical resource scheduling data of each user, and pre-allocating buffer resources for each user according to the predicted resource demand; when receiving a service processing request of a target user, calling a target buffer resource from the buffer resource corresponding to the target user, responding to the service processing request based on the target buffer resource, and matching a service processing resource corresponding to the service processing request in a shared resource pool shared by the plurality of users; when the service processing resource is initialized, the service processing operation corresponding to the service processing request is taken over based on the service processing resource, and the target buffer resource is released. In the application, the user request response delay is reduced, the resource scheduling with high real-time performance, high flexibility and high resource utilization rate can be realized, and the applicability is high.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource scheduling method, apparatus and device. Background Technology

[0002] In cloud computing environments, dynamic resource allocation and elastic scaling are core mechanisms for addressing fluctuations in user computing power demands. Because user task loads exhibit significant temporal variations (e.g., alternating peak and trough periods), maximizing resource utilization presents a challenge: redundant resources remain idle during low loads, leading to waste, while resource provisioning delays during high loads can cause performance degradation or service interruptions. Existing technologies primarily achieve elastic scaling through dynamic scheduling algorithms, load balancing strategies, and containerized resource orchestration, while also leveraging heterogeneous resource management to improve hardware adaptability.

[0003] However, existing resource scheduling mechanisms employ a passive response mode, requiring a lengthy initialization process from resource allocation to availability. This results in prolonged response times for business requests, making it difficult to simultaneously meet the demands for low-latency response and high resource utilization. Summary of the Invention

[0004] This application provides a resource scheduling method, apparatus, and device that can provide highly flexible and real-time resource scheduling, enable immediate response to user service processing requests, reduce the latency of resource scheduling and service processing request response, improve resource utilization, and has high applicability.

[0005] In a first aspect, this application provides a resource scheduling method, which includes: acquiring multiple historical resource scheduling data corresponding to multiple users, wherein one user corresponds to one set of historical resource scheduling data; acquiring the predicted resource demand of each user based on the historical resource scheduling data corresponding to each user, and pre-allocating buffer resources for each user based on the predicted resource demand of each user, so as to obtain multiple buffer resources corresponding to the multiple users, wherein the buffer resources are available resources that have been pre-initialized and stored in a buffer resource pool and are in a state of pending allocation; when a business processing request from a target user among the multiple users is received, calling the target buffer resource from the buffer resource corresponding to the target user, responding to the business processing request based on the target buffer resource, and simultaneously matching the business processing resource corresponding to the business processing request in a shared resource pool shared by the multiple users; when the business processing resource is initialized, taking over the business processing operation corresponding to the business processing request based on the business processing resource, and releasing the target buffer resource. In this application, historical resource scheduling data from each user is collected to predict resource demand using a model. Pre-allocated initialized buffer resources are then pre-assigned to each user. Upon receiving a business processing request from a target user, the corresponding buffer resources can be immediately invoked for a rapid response. Simultaneously, the matching and initialization process of business processing resources within the shared resource pool is triggered. After the business processing resources are initialized, the business processing operation is taken over, and the buffer resources are released. Utilizing historical resource scheduling data improves the accuracy of resource demand prediction, while the pre-loading mechanism of buffer resources reduces the latency of business processing request responses. Furthermore, the dynamic matching of business processing resources and the buffer resource reclamation mechanism improve overall resource utilization while ensuring user experience, demonstrating high applicability.

[0006] In one possible implementation of the first aspect, obtaining the predicted resource demand of each user based on the historical resource scheduling data corresponding to each user includes: obtaining target historical resource scheduling data for each user within a historical target time period from the historical resource scheduling data corresponding to each user; inputting the target historical resource scheduling data for each user into a resource prediction model; and outputting the predicted resource demand of each user within a future target time period corresponding to the historical target time period through the resource prediction model; wherein the resource prediction model includes at least one of a machine learning model or a deep learning model. In this application, by obtaining the target historical resource scheduling data for each user within a historical target time period and inputting it into a resource prediction model, the predicted resource demand of each user within a future target time period corresponding to the historical target time period can be generated. The model can map historical resource usage patterns with future demand trends, improving the matching degree between the prediction results and the real scenario, increasing the accuracy of the prediction, and thus optimizing the timeliness and accuracy of buffer resource preloading and pre-allocation. Furthermore, the resource prediction model offers diverse options and high applicability.

[0007] In one possible implementation of the first aspect, the aforementioned pre-allocation of buffer resources to each user based on the predicted resource demand of each user includes: pre-allocating business processing resources to each user based on the predicted resource demand of each user, and marking the pre-allocated business processing resources to each user as dedicated business processing resources for each user; initializing the dedicated business processing resources of each user, and freezing the initialized resources into resources in a state of initialization and pending scheduling using memory snapshot technology, thereby obtaining multiple buffer resources corresponding to the multiple users. In this application, dedicated business processing resources can be pre-allocated to each user based on the predicted resource demand and initialized. Then, memory snapshot technology can be used to freeze the initialized resources into a state of pending scheduling to obtain multiple buffer resources. This ensures accurate matching between the predicted user resource demand and the pre-allocated buffer resources. By using memory snapshot freezing technology to solidify the initialization completion state, the buffer resources can be activated and called immediately, improving the flexibility of resource scheduling, avoiding the waiting delay when business processing requests trigger initialization in the traditional mode, and achieving seamless switching from the pre-allocated buffer resource state to the real-time scheduling state, thus having high applicability.

[0008] In one possible implementation of the first aspect, the aforementioned invocation of a target buffer resource from the buffer resources corresponding to the target user includes: obtaining at least one idle buffer resource from the buffer resources corresponding to the target user as the target buffer resource, and invoking the target buffer resource through an immediately available scheduling interface to respond to the service processing request through the target buffer resource; wherein, the immediately available scheduling interface includes at least one of a memory access channel or a dedicated application programming interface (API) channel, and the buffer resource includes at least one of computing resources, storage resources, or network resources. In this application, an idle resource can be selected from the target user's buffer resources as the target buffer resource, and the target buffer resource can be directly invoked through an immediately available interface to respond to the service processing request. By selecting an idle resource, resource preemption conflicts can be avoided. At the same time, using an immediately available scheduling interface can complete resource supply in real time when the service processing request is triggered, reducing the latency of resource scheduling and making it highly applicable.

[0009] In one possible implementation of the first aspect, releasing the target buffer resource includes: determining the remaining resource amount of the buffer resource corresponding to the target user; when the remaining resource amount is less than a resource capacity threshold, supplementing the target buffer resource into the buffer resource corresponding to the target user to expand the buffer resource corresponding to the target user; when the remaining resource amount is not less than the resource capacity threshold, releasing the target buffer resource to its pre-initialization state to obtain the target service processing resource corresponding to the target buffer resource, and supplementing the target service processing resource into the shared resource pool. In this application, the remaining resource amount of the buffer resource can be detected in real time, and the resource pre-allocation can be dynamically adjusted according to the comparison result with the resource capacity threshold: when the remaining resource amount is insufficient, the target buffer resource can be supplemented into the user's buffer resource to maintain the remaining resource amount of the buffer resource; when the remaining resource amount is sufficient, the target buffer resource can be released to its pre-initialization state and recycled into the shared resource pool. The elastic adjustment mechanism based on threshold determination can prioritize the reserve of buffer resources for target users when resources are insufficient, ensuring a rapid response capability to subsequent business processing requests. It can also release resources and reclaim them to the shared resource pool when resources are redundant, avoiding long-term idleness of redundant buffer resources, improving the resource utilization rate of global resources, and has high applicability.

[0010] In one possible implementation of the first aspect, after responding to the service processing request based on the target buffer resource, the method further includes: determining the amount of remaining buffer resources in the buffer resources corresponding to the target user, excluding the target buffer resource; when the amount of remaining buffer resources is less than a resource capacity threshold, obtaining idle service processing resources from the shared resource pool and completing initialization, and then supplementing the initialized service processing resources into the buffer resources corresponding to the target user. In this application, the amount of remaining buffer resources in the target user's buffer resources after excluding the already invoked target buffer resource can be detected in real time. When the remaining amount is lower than the resource capacity threshold, idle service processing resources are obtained from the shared resource pool and initialized, thereby supplementing the initialized resources into the target user's buffer resources. Through real-time detection of the remaining buffer resource amount and a threshold triggering mechanism, service processing resources in the shared resource pool can be dynamically invoked to expand the buffer resources when buffer resources are scarce, ensuring a continuous supply of buffer resources, avoiding delays in subsequent service processing request responses due to insufficient buffer resources, reducing resource waste caused by redundant pre-allocation of buffer resources, improving the resource utilization rate of global resources, and demonstrating high applicability.

[0011] In one possible implementation of the first aspect, before pre-allocating buffer resources to each user based on the predicted resource demand of each user, the method further includes: setting the resource capacity threshold based on the time period position of the historical target time period within the business processing resource pre-allocation cycle, wherein the historical target time period is a portion of the business processing resource pre-allocation cycle; or setting the resource capacity threshold based on the resource node type included in the historical resource scheduling data, wherein the resource node type is either a resource center node or a resource edge node; or setting the resource capacity threshold based on historical resource configuration information included in the historical resource scheduling data, wherein the historical resource configuration information includes at least the resource type and the business processing capacity of the resource; or setting the resource capacity threshold based on the user priority of each user, wherein the user priority is set by the service level of the business processing service subscribed by the user. In this application, resource capacity thresholds can be set through multiple dimensions such as time period position, resource node type, resource configuration information, or user priority, enriching the flexibility and selectivity of resource capacity threshold setting and dynamic resource pre-allocation strategies, enhancing the scenario adaptability of resource scheduling, and providing high applicability.

[0012] In one possible implementation of the first aspect, the shared resource pool includes multiple service processing resources sorted according to different scheduling priorities; the acquisition of idle service processing resources from the shared resource pool and completion of initialization includes: acquiring idle resources with scheduling priorities lower than a priority threshold from the multiple service processing resources and completing initialization; wherein the scheduling priority is set by at least one priority setting rule among user priority, task priority, and resource type priority. In this application, service processing resources sorted according to scheduling priorities such as user priority, task priority, or resource type priority can be maintained in the shared resource pool, and initialization is completed by acquiring idle resources with scheduling priorities lower than a set threshold when acquiring service processing resources. By using the priority threshold filtering mechanism, low-priority idle resources with less impact on business operation can be selected for initialization, avoiding the occupation of high-priority resources and affecting the resource guarantee of critical tasks or high-priority users. This preserves the schedulability of high-priority resources to maintain the stability of core businesses and the resource supply preparation for high-priority users, while activating low-priority idle resources as service processing resources, improving the resource utilization rate of the shared resource pool, achieving a balance between efficient resource reuse and business guarantee capabilities, and has high applicability.

[0013] In one possible implementation of the first aspect, the aforementioned takeover of the business processing operation corresponding to the business processing request based on the aforementioned business processing resource includes: processing a portion of the business processing operation requested by the business processing request based on the aforementioned business processing resource, and processing all the business processing operation requested by the business processing request based on the aforementioned business processing resource after a preset transition time, thereby achieving a smooth transition of the business processing operation from the aforementioned target buffer resource to the aforementioned business processing resource. In this application, by first processing a portion of the operation in the business processing request based on the business processing resource, and then switching to processing all the operation after a preset transition time, a smooth transition from the target buffer resource to the business processing resource can be achieved. This effectively avoids interruption of business processing operations or performance fluctuations at the moment of resource switching, maintaining service continuity while reserving a smooth transition time for the complete takeover of the business processing resource. At the same time, while ensuring business continuity, it reduces the risk of processing conflicts caused by sudden release or preemption of resources, optimizes the stability of the resource switching process, and has high applicability.

[0014] In one possible implementation of the first aspect, matching the business processing resource corresponding to the business processing request from the shared resource pool shared by the multiple users includes: obtaining the identity identifier of the target user carried in the business processing request, wherein the identity identifier includes at least a user identifier and a user priority, and the user priority is set by the service level of the business processing service subscribed by the user; determining, based on the identity identifier, resources adapted to the target user and the business processing request from the shared resource pool shared by the multiple users, and initializing the resources to create the business processing resource corresponding to the business processing request. In this application, by obtaining the identity identifier of the target user carried in the business processing request, dynamically matching resources adapted to the target user and request characteristics from the shared resource pool based on the identity identifier, and completing resource initialization to create dedicated business processing resources, resource guarantees with differentiated service levels can be achieved, ensuring the compatibility between the matched resources and the target user, and improving the stability of business processing resource supply. The resource initialization and creation process combines user identification and request characteristics, enabling the generated business processing resources to have targeted processing capabilities. This reduces redundant resource consumption and shortens the delay from the initiation of a business processing request to the readiness of the resource, making it highly applicable.

[0015] Secondly, this application provides a resource scheduling apparatus, which includes a module or unit for performing the resource scheduling method provided in the first aspect or any possible implementation thereof.

[0016] For example, the resource scheduling device described above includes:

[0017] The data acquisition module is used to acquire multiple historical resource scheduling data corresponding to multiple users, wherein one of the aforementioned users corresponds to one of the aforementioned historical resource scheduling data.

[0018] The prediction allocation module is used to obtain the predicted resource demand of each user based on the historical resource scheduling data corresponding to each user, and to pre-allocate buffer resources to each user based on the predicted resource demand of each user. The buffer resources are available resources that have been pre-initialized and stored in the buffer resource pool and are in a state of waiting to be allocated.

[0019] The request and response module is used to, when receiving a business processing request from a target user among the multiple users, call the target buffer resource from the buffer resource corresponding to the target user, respond to the business processing request based on the target buffer resource, and at the same time match the business processing resource corresponding to the business processing request in the shared resource pool shared by the multiple users.

[0020] The resource switching module, when the above-mentioned business processing resources are initialized, takes over the business processing operation corresponding to the above-mentioned business processing request based on the above-mentioned business processing resources, and releases the above-mentioned target buffer resources.

[0021] Thirdly, this application provides a terminal device, which includes a processor and a memory; the processor is connected to the memory, wherein the memory is used to store program code, and the processor is used to call the program code to execute the method provided in the above embodiments.

[0022] Fourthly, this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and to execute the methods provided in the above embodiments.

[0023] Fifthly, this application provides a computer program product including computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of the method provided in the above embodiments. Attached Figure Description

[0024] Figure 1 This is a system architecture diagram of the resource scheduling method provided in the embodiments of this application;

[0025] Figure 2 This is a schematic diagram illustrating an application scenario of the resource scheduling method provided in the embodiments of this application;

[0026] Figure 3 This is a flowchart illustrating the resource scheduling method provided in an embodiment of this application;

[0027] Figure 4 This is an interactive schematic diagram of the resource scheduling method provided in an embodiment of this application;

[0028] Figure 5 This is another interactive schematic diagram of the resource scheduling method provided in the embodiments of this application;

[0029] Figure 6 This is a schematic diagram of the structure of the resource scheduling device provided in the embodiments of this application;

[0030] Figure 7 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] In cloud computing environments, dynamic resource pre-allocation and elastic scaling technologies are core mechanisms for addressing fluctuations in user computing power demand, aiming to balance the adaptability between resource supply and dynamic load. Since user task loads typically exhibit significant temporal variations—for example, traffic surges during e-commerce promotions, periodic peaks on online education platforms, and idle periods for computing clusters at night—traditional static resource allocation models face severe challenges: redundant resources remain idle for extended periods under low load, while delays in resource supply during high load can lead to service performance degradation or even outages. Existing technical solutions primarily achieve on-demand resource pre-allocation through dynamic scheduling algorithms (such as adaptive scheduling strategies based on real-time load monitoring), load balancing strategies (such as weighted round-robin and minimum connection pre-allocation), and containerized resource orchestration platforms (such as Kubernetes' elastic scaling components). Furthermore, traditional solutions often incorporate heterogeneous computing resource management technologies to improve hardware adaptability.

[0033] However, the limitations of existing technologies in practice are becoming increasingly apparent. First, the dynamic optimization capabilities of load balancing are insufficient. Most systems rely on static weights or historical averages for pre-allocation strategies, which struggle to effectively handle sudden traffic spikes or differences in the computational characteristics of heterogeneous tasks, leading to severe load imbalances among instances. For example, some nodes may be overloaded due to handling high input / output (I / O) or computationally intensive tasks, while other nodes suffer from low resource utilization due to unreasonable task pre-allocation. Second, the real-time performance of resource scheduling is a bottleneck. The data collection cycle and decision-making delays make it difficult for the system to respond promptly to instantaneous load fluctuations, potentially causing service degradation, especially under second-level traffic surges. Furthermore, existing mechanisms have weak adaptability. Elastic strategy parameters (such as scaling steps and cooldown periods) typically rely on manual presets, making dynamic adjustment based on business characteristics difficult. The tendency for local optimization in distributed architectures further weakens the ability to coordinate global resources. For example, when scheduling across availability zones, algorithms lacking topology awareness may add extra latency due to frequent instance migrations across network partitions. These problems collectively lead to a decline in overall system performance, an increase in reliability risks, and a waste of resources, highlighting the deep-seated deficiencies of existing technologies in terms of dynamism, real-time performance, and global collaboration.

[0034] The resource scheduling method provided in this application predicts resource demand by collecting historical resource scheduling data from each user and pre-allocating initialized buffer resources to each user. Upon receiving a business processing request from a target user, the method immediately invokes the corresponding buffer resources for a rapid response. Simultaneously, it triggers the matching and initialization process of business processing resources within the shared resource pool. After the business processing resources are initialized, the method takes over the business processing operation and releases the buffer resources. Utilizing historical resource scheduling data improves the accuracy of resource demand prediction, while the pre-loading mechanism of buffer resources reduces the latency of business processing request responses. Furthermore, the dynamic matching of business processing resources and the buffer resource reclamation mechanism improve overall resource utilization while ensuring user experience, demonstrating high applicability.

[0035] Please see Figure 1 , Figure 1 This is a system architecture diagram of the resource scheduling method provided in the embodiments of this application. For example... Figure 1 As shown, Figure 1 As shown, the system architecture may include a business server 100 and a terminal cluster. The terminal cluster may include terminal devices 200a, 200b, 200c, ..., 200n, etc. The business server 100 may be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It may also be a cloud server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms. The terminal devices (including terminal devices 200a, 200b, 200c, ..., 200n) may be PDAs, smartphones, laptops, desktop computers, tablets, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, etc.), smart computers, and other smart terminals, but are not limited to these.

[0036] The service server 100 can establish communication connections with each terminal device in the terminal cluster, and the terminal devices in the terminal cluster can also establish communication connections with each other. In other words, the service server 100 can establish communication connections with each terminal device among terminal devices 200a, 200b, 200c, ..., 200n. For example, terminal device 200a can establish a communication connection with the service server 100. Terminal devices 200a and 200b can establish a communication connection, and terminal devices 200a and 200c can also establish a communication connection. The communication connection method is not limited; it can be established directly or indirectly through wired communication or wireless communication, etc., depending on the actual application scenario, and is not restricted here.

[0037] It should be understood that, such as Figure 1 Each terminal device in the terminal cluster shown can have an application client installed. When the application client runs on each terminal device, it can interact with the aforementioned... Figure 1 The business servers 100 shown interact with each other, enabling each business server 100 to receive business data from each terminal device. This business data can be application data generated during user interaction with the application client, and this application data can be shared with the business server 100. The application client can be an application program, a webpage, or a website, depending on the specific application scenario, and is not limited here. The application client can be a standalone client or an embedded sub-client integrated into another client (e.g., an instant messaging client, a social networking client, etc.), depending on the specific application scenario, and is not limited here. Users can send business data to the business server 100 through the application client. This business data can be used to request the business server 100 to start relevant business processes and return relevant process data to the application client. The business server 100, as the server for the application client, can be a collection of multiple servers, including the backend server corresponding to the application client, a data processing server, etc. The method provided in this embodiment can be provided by, for example... Figure 1 The business server 100 shown can execute the service, but it can also be executed by a terminal device (such as...). Figure 1 The terminal device 200a, terminal device 200b, ..., terminal device 200n shown can be used to execute the application. Alternatively, the terminal device and the business server can be used together to execute the application. The specific execution method can be determined based on the actual application scenario and is not limited here.

[0038] The resource scheduling method provided in this application (which may be simply referred to as the resource scheduling method or method for ease of description) is applicable to terminal devices including, but not limited to, smartphones, computers, tablets, personal digital assistants (PDAs), mobile internet devices (MIDs), and wearable devices. Optionally, the terminal device may also be a server corresponding to the aforementioned smartphones, computers, tablets, PDAs, MIDs, and wearable devices, etc., which can be determined according to the actual application scenario and is not limited here. For ease of description, the execution subject of the resource scheduling method provided in this application will be described using terminal devices. Correspondingly, the resource scheduling device (or simply resource scheduling device) provided in this application includes, but is not limited to, smartphones, computers, tablets, PDAs, MIDs, and wearable devices. For ease of description, the resource scheduling device and / or terminal provided in this application will be described using a computer as an example.

[0039] It is understood that the resource scheduling method provided in the embodiments of this application can be derived from, for example, the following methods. Figure 1 The business server 100 shown can execute the service, but it can also be executed by a terminal device (such as...). Figure 1 The execution can be performed by any one of the terminal devices 200a, 200b, ..., 200n shown, or it can be executed interactively by the terminal device and the business server. The specific execution method can be determined according to the actual application scenario, and no restrictions are imposed here. For ease of subsequent understanding and explanation, the embodiments of this application can... Figure 1 Select one terminal device from the terminal device cluster shown as the target terminal device, for example, select terminal device 200c as the target terminal device.

[0040] The resource scheduling method provided in this application is applicable to the scheduling of various types of resources, including but not limited to: computing resources, storage resources, and network resources. The specific type can be determined according to the actual application scenario and is not limited here. The computing resources may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), neural network processing units (NPUs), tensor processing units (TPUs), virtualization instances, dedicated accelerators, processes / threads, etc. The storage resources may include, but are not limited to, object storage, block storage, file storage, cache storage, archive storage, etc. The network resources may include, but are not limited to, bandwidth, load balancers, IP addresses, content delivery networks, software-defined networks, etc. Different types of resources are applicable to scenarios including, but not limited to, running business services, user data backup, and cross-data center data transmission, and are not limited here.

[0041] Optionally, the various types of resources in the examples above can exist independently or in combination, without restriction. "Independent existence" can be understood as a resource providing a specific function on its own; for example, a GPU bare-metal server can independently provide GPU computing power, allowing users to directly operate the hardware. "Combined existence" can be understood as one type of resource being combined with another type of resource to form a complete service. For example, using a combination of cloud servers and cloud disks, virtual machines can mount block storage to run databases, achieving a combination of computational processing and data persistence.

[0042] For ease of description, we will take the application client (or simply client) installed on the aforementioned terminal device 200c as an example, combined with... Figure 2 The application scenarios of the resource scheduling method provided in the embodiments of this application are described.

[0043] See Figure 2 , Figure 2This is a schematic diagram illustrating an application scenario of the resource scheduling method provided in this application. Assume that a target user (referred to as "user" for convenience) has a need to frequently upload large amounts of data to cloud storage using a terminal device 200c (referred to as "terminal device") during working hours (e.g., 9:00-18:00), and there are peak upload concurrency periods (e.g., 17:00-18:00). In this case, the input / output (I / O) throughput and response speed of the storage service directly affect work efficiency. The terminal device can detect the user's operation status on its user interface (e.g., user interface 1), such as... Figure 2 As shown, when a user clicks the "Register" control icon on user interface 1, a user interface (e.g., user interface 2) displaying information about storage reservations can be triggered. Figure 2 As shown, the user interface for storage reservation can include selectable controls such as "Basic Individual," "Small and Medium Teams," and "Enterprise Customization." When the user's mouse cursor moves to the corresponding display text, a pop-up window (not shown in the figure) can be displayed to show the corresponding storage amount. It can be understood that different storage amounts correspond to different quantities or qualities of storage resources. Assuming the target user selects "Small and Medium Teams," meaning the target user has reserved the storage resources corresponding to "Small and Medium Teams," the terminal device can pre-allocate the corresponding buffer resource amount for the target user. Here, the buffer resource is an available resource that has been pre-initialized and stored in the buffer resource pool, in a pending allocation state. When the target user sends a storage request, for example, when the target user drags the file they wish to store into the indicated area in user interface 3 and clicks the "Upload" control, the terminal device immediately calls upon the aforementioned buffer resource to respond to the target user's storage request. For example, it expands a new user interface or pop-up window (not shown in the figure) for the user to select the storage file type, quality, etc., and creates a dedicated business processing resource corresponding to the storage request in the background, reducing the target user's waiting time. Optionally, the user can also change the reserved resource amount, such as... Figure 2As shown, assuming a user clicks the "Modify Reserved Storage" button in user interface 3, they can be redirected to user interface 2 to modify the reserved resource storage. The specific amount can be determined based on the actual application scenario and is not limited here. After the target user registers, their usage patterns and usage behavior can be continuously collected. For example, for a week, patterns such as a large number of logins starting around 8:50 AM, a sharp increase in upload requests after 9:00 AM, and a peak in resource usage between 5:00 PM and 6:00 PM can be collected. Based on this historical resource usage data, the peak time range for the next day can be predicted, and it can be further refined to the expected resource demand at different time points (e.g., an increase of 50% in reserved upload bandwidth before 5:00 PM). Without the user's awareness, the terminal device can complete buffer resource preheating and expansion before the predicted peak period arrives to reduce user request response latency. In the specific implementation, how the terminal device uses historical resource scheduling data to predict resource demand and schedule resources can be found in the implementation methods described in the following embodiments, which will not be elaborated here.

[0044] In some feasible implementations, when a terminal device fails to access buffer resources in the aforementioned buffer resource pool, it can trigger emergency resource allocation, dynamically allocating emergency resources from the shared resource pool and prioritizing these emergency resources to the highest level (e.g., through real-time scheduling flags, core binding, or resource preemption strategies) to ensure their availability. Here, the shared resource pool maintains a large number of business processing resources sorted by scheduling priorities such as user priority, task priority, or resource type priority. These resources are uninitialized and need to be initialized based on the business request and initialization priority. It is understood that the terminal device can scan the shared resource pool using distributed resource probes, dynamically selecting suitable, idle business processing resources based on the resource requirements declared in the business request (e.g., the aforementioned storage request) (such as minimum available space requirements, random read / write performance limits, etc.) as emergency resources, and prioritizing their initialization to the highest level for rapid initialization and response to business requests. The specific details can be determined based on the actual application scenario and are not limited here. In this embodiment, by triggering an emergency resource allocation mechanism when a buffer resource call fails, resources are dynamically allocated from the shared resource pool to ensure zero-latency recovery of critical services, thereby improving the system's fault tolerance, resource allocation efficiency, and resource utilization, and achieving a balance between rapid fault recovery and efficient resource utilization.

[0045] It is understood that in the specific implementation of this application, data related to object information is involved. When the embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0046] The following will combine Figures 3 to 7 The resource scheduling method and apparatus provided in the embodiments of this application will be described in detail.

[0047] See Figure 3 , Figure 3 This is a flowchart illustrating the resource scheduling method provided in the embodiments of this application. For ease of understanding, the embodiments of this application use a terminal device as an example for explanation, i.e.,... Figure 1 Taking the terminal device 200c as an example, the service server can be the one described above. Figure 1 The corresponding embodiment refers to the business server 100. This application's embodiments can be applied to various scenarios, including but not limited to cloud technology and artificial intelligence. Figure 3 In the resource scheduling method shown, each step of resource scheduling can be derived from the above. Figure 1 The terminal device 200c in the middle is used to execute, such as Figure 3 As shown, the resource scheduling method may include at least the following steps S301-S304:

[0048] S301, obtain multiple historical resource scheduling data corresponding to multiple users, wherein one of the above-mentioned users corresponds to one of the above-mentioned historical resource scheduling data.

[0049] In some feasible implementations, the terminal device can acquire historical resource scheduling data corresponding to multiple users. Here, resources may include, but are not limited to, computing resources, storage resources, and network resources, which can be determined according to the actual application scenario and are not limited here. Optionally, the terminal device can collect process-level resource consumption in real time through the application programming interface (API) exposed by the operating system kernel layer, or parse system logs through an agent program to obtain time-series scheduling records, thereby realizing the collection of historical resource scheduling data. This can be determined according to the actual application scenario and is not limited here. Here, historical resource scheduling data may include, but is not limited to, resource types (such as the number of CPU cores, memory pages, IOPS, network bandwidth), pre-allocation strategies, actual usage (such as CPU utilization percentage, resident memory size), user information (such as user tags, user levels), dynamic usage frequency (requests per second), load characteristics (bursting / stable), and time-series patterns (daily / weekly peak and trough granularity), which can be determined according to the actual application scenario and are not limited here.

[0050] Optionally, in some feasible implementations, after obtaining multiple historical resource scheduling data corresponding to the aforementioned multiple users, the terminal device can store the aforementioned historical resource scheduling data in storage spaces including but not limited to local time-series databases, memory buffers, or storage clusters for quick retrieval or analysis during subsequent prediction. The specific details can be determined according to the actual application scenario and are not limited here.

[0051] S302, based on the historical resource scheduling data corresponding to each of the above-mentioned users, obtain the predicted resource demand of each of the above-mentioned users, and pre-allocate buffer resources for each of the above-mentioned users based on the predicted resource demand of each of the above-mentioned users, so as to obtain multiple buffer resources corresponding to the above-mentioned multiple users. The buffer resources are available resources that have been pre-initialized and stored in the buffer resource pool and are in a state of waiting to be allocated.

[0052] In some feasible implementations, the terminal device can obtain the predicted resource demand of each user based on the historical resource scheduling data corresponding to each user. Here, the terminal device can directly call the historical resource scheduling data collected in real time, or it can read the historical resource scheduling data from storage space (such as database, memory buffer, or storage cluster). The specific method can be determined according to the actual application scenario and is not limited here. Here, the historical resource scheduling data may include, but is not limited to, the type of resources requested by the user (such as the number of CPU cores, GPU memory, storage capacity, etc.), the actual allocated resource specifications, resource usage duration, resource utilization curve (such as CPU / GPU load fluctuation curve), task execution status (such as success / failure and error codes), scheduling latency (such as the time from request to allocation), priority change records, and the number of emergency resource calls, etc. The specific method can be determined according to the actual application scenario and is not limited here. The terminal device can use methods including but not limited to model prediction, periodic rule mining, event correlation analysis, sliding window statistics, similarity matching strategy, etc. to predict resource demand. It can use one of the above methods for prediction, or it can form a hybrid decision system to improve robustness. The specific method can be determined according to the actual application scenario and is not limited here. In other words, predicting resource demand involves analyzing historical resource scheduling data of users and systems (such as scheduling records for CPU, memory, storage, and network), business load characteristics (such as task type, concurrency, and time-series patterns), and environmental variables (such as business growth trends and periodic traffic fluctuations). Using statistical models or machine learning algorithms (such as time series analysis and neural networks), the result is a quantitative estimate of the scale of computing, storage, and network resources required for a specific future time period. This estimate can be output in the form of specific data (such as the required number of CPU cores or memory capacity) or probability ranges (such as the confidence range for bandwidth requirements). For example, predicted resource demand may include, but is not limited to: peak computing power (such as the number of CPU cores or GPUs) during the user's future task cycle, estimated memory usage, storage space growth trends, network bandwidth fluctuation range, and accelerator resource requirements (such as TPU usage). It is understood that the aforementioned predicted resource demand can be at different time granularities, such as predicted resource demand within 15 minutes, predicted resource demand within 1 hour, etc. The time granularity can be set by the user, or determined based on the time granularity corresponding to the most accurate predicted resource demand in history. The specific determination can be made according to the actual application scenario and is not limited here. Furthermore, the terminal device can pre-allocate buffer resources to each user based on the predicted resource demand. Here, the pre-allocation process can be dynamically adapted by combining the accuracy of demand prediction, business scenario characteristics, and real-time system status. For example, for users with obvious periodic characteristics, the standard deviation of historical fluctuations can be added to the predicted value as redundancy. The specific determination can be made according to the actual application scenario and is not limited here.

[0053] In some feasible implementations, the terminal device can obtain the target historical resource scheduling data for each user within a historical target time period from the historical resource scheduling data corresponding to each user. This target historical resource scheduling data is then input into a resource prediction model, which outputs the predicted resource demand for each user within a future target time period corresponding to the historical target time period. Here, the resource prediction model can be at least one of a machine learning model or a deep learning model. For example, the resource prediction model can be a logistic regression model, a linear regression model, an artificial neural network model, a convolutional neural network model, a long short-term memory (LSTM) model, etc., which can be determined according to the actual application scenario and is not limited here. It can be understood that the terminal device can obtain the target historical resource scheduling data for each user within a historical target time period from the historical resource scheduling data corresponding to each user, and preprocess it. This preprocessing can involve data cleaning (handling missing and outliers), feature engineering (extracting sliding window statistics and periodic features), and normalization steps before inputting it into a trained resource prediction model. Correspondingly, the resource prediction model can output the predicted resource demand within the future target time period. For example, resource usage records of target users during peak evening business hours on the same workday over the past four weeks can be selected as target historical resource scheduling data for the target user. After data preprocessing, this target historical resource scheduling data is input into a trained resource prediction model (such as an LSTM model) to output the predicted resource demand during peak evening business hours on the same workday in the future. The specific data processing flow and model selection can be determined according to the actual application scenario and are not limited here. In the embodiments of this application, target historical resource scheduling data for each user within a historical target time period can be obtained and input into the resource prediction model to generate the predicted resource demand for each user in the future target time period corresponding to the historical target time period. The model can map historical resource usage patterns with future demand trends, improving the matching degree between prediction results and real scenarios, increasing prediction accuracy, and thus optimizing the timeliness and accuracy of buffer resource preloading and pre-allocation. At the same time, the resource prediction model selection is diverse and highly applicable.

[0054] In some feasible implementations, the terminal device can pre-allocate service processing resources to each user based on the predicted resource demand of each user, and mark the pre-allocated service processing resources as dedicated service processing resources for each user. The dedicated service processing resources for each user can be initialized, and memory snapshot technology can be used to freeze the initialized resources into resources in a buffer resource pool that are in a pending scheduling state, thus obtaining multiple buffer resources corresponding to multiple users. Optionally, after pre-allocating service processing resources to each user based on the predicted resource demand, the terminal device can mark the pre-allocated service processing resources as dedicated service processing resources for each user using methods including but not limited to tagged resource binding, policy-driven binding, and lease mechanism binding. It is understood that the terminal device can use dynamic semantic tags for logical identification, combined with hardware-level programmable tags (such as data processing unit firmware burning and memory coloring technology) to ensure physical layer ownership, and can also drive conditional binding through a policy engine, integrating elastic quality of service (QoS) tags and self-healing failover tags, etc. The specific implementation can be determined according to the actual application scenario and is not limited here. For ease of understanding, the following explanation uses tagged resource binding as an example. Terminal devices can reserve a specified number of CPU cores or GPU computing units on physical nodes based on each user's predicted resource needs, using a scheduler or similar mechanism. A user-specific tag is then attached to this resource block to ensure resource isolation and traceability. This user-specific tag can include, but is not limited to, multi-factor composite tags, dynamic policy hash tags, time window segmentation tags, encrypted identity token tags, resource topology-aware tags, hierarchical priority tags, and semantic version tags. The specific tag can be determined based on the actual application scenario and is not limited here. Furthermore, the terminal device can start a pre-loading engine to pre-fetch the container images (such as TensorFlow inference images and PyTorch images), dependent libraries (such as CUDA dynamic link libraries and MySQL databases), and configuration files required by the business, and load them into memory to maintain a minimal runtime environment (e.g., keeping the process suspended but not pre-allocating computing tasks). This reduces the resource initialization time from seconds to milliseconds when resources are subsequently called. Furthermore, terminal devices can freeze initialized dedicated business processing resources (such as freezing memory pages, register states, and I / O device contexts as persistent images) through memory snapshot freezing technology, and maintain the frozen resource instances using a copy-on-write mechanism. When a user's business processing request is received, the device can directly restore the complete runtime state based on the snapshot, skipping the initialization process such as operating system startup and dependency library loading, and can achieve millisecond-level resource readiness.Optionally, to ensure the effectiveness of buffer resources, the terminal device can periodically (e.g., every 5 minutes) verify the compatibility of the pre-loaded resource content with the latest business requirements (e.g., check model version consistency). If a deviation exists, a rolling update can be triggered to ensure that the buffer pool is always synchronized with the real scenario. The specific method can be determined according to the actual application scenario and is not limited here. In this embodiment, dedicated business processing resources can be pre-allocated to each user based on the predicted resource demand and the dedicated business processing resources can be initialized. Then, memory snapshot technology can be used to freeze the initialized resources into a pending scheduling state to obtain multiple buffer resources. This can ensure an accurate match between the predicted user resource demand and the pre-allocated buffer resources. By using memory snapshot freezing technology to solidify the initialization completion state, the buffer resources can be activated and called immediately, improving the flexibility of resource scheduling and avoiding the waiting delay when business processing requests trigger initialization in the traditional mode. It can achieve seamless switching from the pre-allocated state of buffer resources to the real-time scheduling state, and has high applicability.

[0055] S303, when a business processing request from a target user among the multiple users is received, the target buffer resource is called from the buffer resource corresponding to the target user, and the business processing request is responded to based on the target buffer resource. At the same time, the business processing resource corresponding to the business processing request is matched in the shared resource pool shared by the multiple users.

[0056] In some feasible implementations, when a target user's business processing request is sent to the terminal device via an API gateway or message middleware, the terminal device can obtain the user's identity identifier (such as an encryption token or user ID) carried in the business processing request through a request parsing engine, and can accurately locate the user's exclusive frozen target buffer resource from multiple buffer resources corresponding to the target user based on a tag matching engine. Furthermore, the terminal device can send an activation command to the target buffer resource through a resource scheduler, low-latency channels, etc., and use hot-loading technology (such as CRIU real-time recovery or QEMU snapshot unfreezing) to wake up the target buffer resource within milliseconds. The specific implementation can be determined according to the actual application scenario and is not limited here. It can be understood that the above wake-up process skips the operating system startup and dependency initialization stages, and can directly enter the ready state. Meanwhile, terminal devices can scan the shared resource pool through distributed resource probes and dynamically filter available resources based on the resource requirements declared in the business processing request (such as GPU memory size and floating-point computing power threshold). Matching strategies, including but not limited to static matching and dynamic optimization, can be used to match the business processing resources corresponding to the business processing request from the shared resource pool. The specific method can be determined according to the actual application scenario and is not limited here.

[0057] Optionally, in some feasible implementations, if no business processing resource corresponding to the business processing request can be matched from the aforementioned shared resource pool, such as no idle business processing resource or a faulty business processing resource, the terminal device can initiate a resource reclamation mechanism. This mechanism can scan the usage status of all allocated business processing resources and reclaim them based on reclamation rules. Here, the terminal device can collect resource metrics (such as CPU / memory usage) in real time using distributed probes, poll the orchestration status of the control plane, and detect abnormal behavior through event-driven methods. Combined with a tagged time-series database recording resource activity, it can scan the usage status of business processing resources. Furthermore, it can reclaim business processing resources that have been idle for more than a first duration threshold (such as 30 minutes) based on reclamation rules. It can also reclaim resources whose priority (such as user priority, task priority, or resource type priority) is lower than the current request's pending release, and it can reclaim abnormal resources (such as resources occupied by zombie processes that have timed out or are unresponsive). The specific method can be determined according to the actual application scenario and is not limited here. Here, when reclaiming service processing resources, the terminal device can persist the current processing state of the resources to distributed storage (such as snapshots or logs) using checkpoint technology, then send an interrupt signal and wait for the existing service connection to be interrupted. If necessary, the breakpoint location can be recorded. Furthermore, after resetting the resources (such as clearing resource caches or releasing memory locks), the reset resources can be added back to the shared resource pool for reallocation. In this embodiment, idle or low-priority service processing resources can be dynamically reclaimed through a reclamation strategy, improving resource utilization while ensuring the processing of high-priority tasks.

[0058] In some feasible implementations, the terminal device can obtain at least one idle buffer resource from the buffer resources corresponding to the target user as the target buffer resource, and can invoke the target buffer resource through an immediately available scheduling interface to respond to the service processing request. It is understood that the terminal device can identify the buffer resource status to select at least one idle buffer resource as the target buffer resource. Here, the specific amount of buffer resource selected is determined based on the actual service processing request task volume, etc., and is not limited here. The terminal device can invoke the target buffer resource through an immediately available scheduling interface. Here, the immediately available scheduling interface may include, but is not limited to, memory access channels or dedicated API channels, etc., which can be determined according to the actual application scenario and is not limited here. It is understood that the aforementioned buffer resources may include, but are not limited to, at least one of computing resources, storage resources, or network resources, which will not be elaborated here. The various types of buffer resources mentioned above can exist individually or in combination, and are not limited here. The aforementioned "existence alone" can be understood as a buffer resource providing a specific function independently. For example, a GPU bare metal server can independently provide GPU computing power for users to directly operate the hardware. The aforementioned "existence in combination" can be understood as one type of buffer resource being combined with another type to form a complete service. For example, using a combination of cloud servers and cloud disks, virtual machines can mount block storage to run databases, achieving a combination of computational processing and data persistence. The specific combination can be determined according to the actual application scenario and is not limited here. In this embodiment, idle resources can be selected from the target user's buffer resources as target buffer resources, and the target buffer resource can be directly invoked through an instantly available interface to respond to business processing requests. Selecting idle resources avoids resource preemption conflicts. Simultaneously, using an instantly available scheduling interface allows for real-time resource provisioning triggered by business processing requests, reducing resource scheduling latency and demonstrating high applicability.

[0059] In some feasible implementations, after responding to the service processing request based on the target buffer resources, the terminal device can determine the remaining buffer resources (excluding the target buffer resources) in the buffer resources corresponding to the target user through real-time detection or periodic scanning. It is understood that the terminal device can determine the amount of idle resources in the buffer resources corresponding to the target user as the remaining buffer resources. For example, the terminal device can use a resource detection agent to track the resource consumption status of the corresponding buffer resources in real time and dynamically calculate the remaining buffer resources. Here, the remaining buffer resources may include, but are not limited to, the percentage of available GPU memory, the number of idle CPU cores, etc., which can be determined according to the actual application scenario and the actual resource type, and are not limited here. When the remaining buffer resources are less than the resource capacity threshold, the terminal device can obtain idle service processing resources from the shared resource pool and complete initialization, and then supplement the initialized service processing resources into the buffer resources corresponding to the target user. Here, the resource capacity threshold can be considered as the lowest value of the buffer resource set or buffer resource pool. It can be determined by the user based on multi-dimensional resource usage data in historical resource scheduling data, or it can be set by historical resource capacity thresholds, which can be determined according to the actual application scenario, and are not limited here. Optionally, the resource capacity threshold can be the number of resources or the resource percentage, etc., which can be determined according to the actual application scenario and is not limited here. In this embodiment, the remaining buffer resources in the target user's buffer resources after deducting the target buffer resources that have been called can be detected in real time. When the remaining amount is lower than the resource capacity threshold, idle business processing resources are obtained from the shared resource pool and initialized. Then, the initialized resources can be added to the target user's buffer resources. Through the real-time detection of the remaining buffer resources and the threshold triggering mechanism, business processing resources in the shared resource pool can be dynamically called to expand the buffer resources when the buffer resources are scarce, so as to ensure the continuous supply of buffer resources, avoid the delay in response to subsequent business processing requests due to insufficient buffer resources, reduce the resource waste caused by the pre-allocation of redundant buffer resources, improve the resource utilization rate of global resources, and have high applicability.

[0060] Optionally, in some feasible implementations, the terminal device can determine the idle duration of idle resources in the buffer resources corresponding to the aforementioned target object through real-time detection or periodic scanning. Here, the terminal device can utilize an idle duration threshold determination mechanism (such as statistical analysis based on time windows or machine learning prediction models) to dynamically identify inefficiently occupied idle resources in the buffer resources. The aforementioned idle duration threshold can be specifically determined according to the actual application scenario and is not limited here. It can be understood that for idle resources exceeding the aforementioned idle duration threshold, the terminal device can downgrade buffer resources that may be reused in the short term to low priority (such as adjusting CPU frequency, memory compression, or storage hot and cold tiering) to extend their retention period in the pool; long-term idle resources can be released to their pre-initialization state and returned to the shared resource pool for other services to allocate on demand. The specific details can be determined according to the actual application scenario and are not limited here. In the embodiments of this application, through real-time detection of resource idle duration and a threshold triggering mechanism, buffer resources that have been idle for a long time can be released back to the shared resource pool, improving resource turnover efficiency, reducing buffer resource operation losses, and improving overall resource utilization.

[0061] In some feasible implementations, before pre-allocating buffer resources to each user based on their predicted resource demands, the terminal device can set the resource capacity threshold according to the historical target time period within the pre-allocation period of the service processing resources, where the historical target time period is a portion of the service processing resource pre-allocation period. It is understood that before pre-allocating buffer resources based on predicted demand, the terminal device can set a dynamic resource capacity threshold based on the temporal characteristics of the historical target time period within the overall resource pre-allocation period. For example, terminal devices can analyze the load patterns in the pre-allocation cycle of business processing resources (such as the daily cycle under 24-hour system or the weekly cycle under 7-day system), and set resource capacity thresholds based on the position of historical target time periods (such as the morning peak period from 9:00 to 11:00 on weekdays) in the pre-allocation cycle of business processing resources: based on the daily cycle pattern under 24-hour system, that is, based on the day and night pattern, a higher resource capacity threshold can be set for the peak stage of the cycle (such as daytime working hours) to ensure sufficient resource supply; while for the trough stage of the cycle (such as nighttime rest time), since the business volume usually shows a decreasing trend, the threshold can be dynamically lowered by combining the recent decline slope calculated by the sliding window. The specific determination can be made according to the actual application scenario, and there are no restrictions here. Furthermore, the terminal device can establish a time-period correlation matrix. When a strong correlation is detected between the current time period and the preceding time period (such as the immediately preceding time period), for example, when the correlation coefficient between the current time period and the preceding time period is large, statistical methods, including but not limited to Bayesian methods, can be used to incorporate the actual usage of the preceding time period with specific weights into the current threshold calculation, thereby achieving adaptive adjustment of the threshold setting. The specific method can be determined according to the actual application scenario and is not limited here. In the embodiments of this application, by adopting a resource capacity threshold strategy based on periodic positions, both the risk of resource overload can be prevented, and resource waste caused by static thresholds can be avoided, making it highly applicable.

[0062] Optionally, in some feasible implementations, the terminal device can also set the resource capacity threshold based on the resource node types included in the historical resource scheduling data, wherein the resource node type is either a resource center node or a resource edge node. It is understood that when setting the resource capacity threshold, the terminal device can differentiate the resource capacity threshold design based on the spatial dimension characteristics of the resource node type (center node or edge node). Here, edge nodes can focus on low-latency, region-sensitive tasks (such as real-time video analysis and industrial IoT data processing), with resources primarily based on CPUs and configured with a small number of lightweight GPUs, and the resource capacity threshold can be set according to localized business characteristics (such as reserving memory bandwidth at 1.2 times the historical maximum number of connected devices). Center nodes can be used to carry high-computing-intensive tasks (such as artificial intelligence model training and scientific computing), with resources primarily based on GPU / NPU clusters and supplemented by CPUs, and the resource capacity threshold can be dynamically adjusted based on the global task queue depth (such as automatically expanding the TPU resource pool when the queued tasks exceed the threshold). Terminal devices can optimize resource migration based on resource capacity threshold settings. For example, when an edge node detects a sudden surge in requests (such as a spike in real-time analysis demand), the terminal device can immediately retrieve an initialized GPU instance from the central node and load a localized algorithm model to shorten the data transmission path. Conversely, when batch tasks on the central node require distributed acceleration (such as parallel computing), idle field-programmable gate array (FPGA) resources on the edge nodes can be dynamically integrated into a resource pool formed by the central nodes. The specific integration can be determined according to the actual application scenario and is not limited here. In this embodiment, setting resource capacity thresholds based on resource node type enables pre-allocation of resources in a spatial dimension. This can improve resource utilization through "edge-center" resource complementarity. Furthermore, it can adapt to different resource distributions according to different business scenarios, improving the flexibility and generalization of resource scheduling, thus offering high applicability.

[0063] Optionally, in some feasible implementations, the terminal device can also set the aforementioned resource capacity threshold based on the historical resource configuration information included in the historical resource scheduling data. The historical resource configuration information includes at least the resource type and the resource's processing capacity. It is understood that when setting the resource capacity threshold, the terminal device can obtain the resource type (e.g., CPU, GPU, NPU) and the resource's processing capacity (e.g., floating-point computing power, memory bandwidth, instruction set compatibility) carried in the historical resource configuration information, and set the resource capacity threshold through the type dimension to dynamically adjust the buffer ratio of heterogeneous resources. For example, for parallel computing scenarios that frequently occur in historical data (e.g., video rendering tasks), if the historical peak utilization rate of GPU resources is consistently higher than 75%, the proportion of GPU buffer resources in the total amount of buffer resources of each type is increased according to the task demand weight, and the redundancy reservation of low-load CPUs is reduced. Conversely, in logic-intensive tasks (e.g., high-frequency trading systems), if the historical call rate of the NPU is extremely low (e.g., below a certain set threshold), its buffer ratio is compressed, releasing resources to enhance the proportion of CPU buffer resources. In this embodiment, setting a resource buffer threshold based on the resource type dimension to adjust the heterogeneous resource buffer ratio can align the resource business processing capacity with the task characteristics of the business processing request, reduce cross-type resource contention, and adapt to diverse business needs, thereby enhancing the resource's scenario generalization ability and heterogeneous collaboration efficiency, and making it highly applicable.

[0064] Optionally, in some feasible implementations, the terminal device can also set the resource capacity threshold according to the user priority of each of the aforementioned users, wherein the user priority is set by the service level of the business processing service subscribed by the user. It can be understood that when setting the resource capacity threshold, the terminal device can implement tiered management of user business needs based on the service-level agreement (SLA). For example, for high-level users (such as VIPs), their resource capacity threshold is set at 120% of the historical average threshold, and exclusive resource locks (such as GPU memory reservation) can be set to ensure that high-priority tasks have priority in resource contention; while lower-level users have lower resource capacity thresholds. Here, through the differentiated design of the thresholds, the buffer resources of high-priority users can be replenished more promptly. The terminal device can also implement priority scheduling of buffer resources through dynamic weighted queues. For example, when a high-SLA task is detected, the resource quota of low-priority tasks is automatically compressed proportionally, and resource re-allocation can be triggered, with the released resources being preferentially injected into the high-priority queue. In this embodiment, resource capacity thresholds can be set by user priority, which enriches the flexibility and selectivity of resource capacity threshold setting strategies and dynamic pre-allocation strategies, enhances the scenario adaptability of resource scheduling, and has high applicability.

[0065] In some feasible implementations, the terminal device can dynamically adjust the aforementioned resource capacity threshold based on the actual usage of buffer resources. Here, the actual usage of buffer resources can be the historical utilization rate of the buffer resources. The terminal device can continuously monitor the historical utilization rate of each user's buffer resources (e.g., sliding window statistics or time-series predictive analysis) and introduce a dynamic resource capacity threshold adjustment mechanism to dynamically adjust the aforementioned resource capacity threshold. For example, when a user's resource utilization rate exceeds the first threshold (e.g., 80%) for N consecutive periods, its capacity threshold can be automatically increased (e.g., by increasing the quota by 20%) to avoid frequent resource contention; when it is below the second threshold (e.g., 30%) for M consecutive periods, the threshold can be gradually decreased (e.g., by reducing it by 10% each time) to gradually reclaim redundant resources. N and M can be set according to business requirements (e.g., N=3, M=5) and support dynamic calibration during runtime. In this embodiment, the introduction of a dynamic resource capacity threshold adjustment mechanism can dynamically adjust the quota based on the actual load, making resource allocation more accurate and improving resource utilization and system performance.

[0066] In some feasible implementations, the shared resource pool may include multiple service processing resources sorted according to different scheduling priorities. The terminal device can obtain idle resources with scheduling priorities lower than a priority threshold from these multiple service processing resources, complete initialization, and then supplement the initialized service processing resources into the buffer resources corresponding to the target user. Here, the scheduling priority can be set by at least one priority setting rule, including but not limited to user priority, task priority, and resource type priority. It can be understood that under the priority scheduling framework of the shared resource pool, the terminal device can dynamically filter service processing resources and supplement buffer resources through a multi-dimensional rule fusion engine. For example, the terminal device can generate a priority score for each business processing resource in the pool based on preset priority setting rules, such as user service level, task criticality weight, and resource computing power requirements. When it is detected that the buffer resources of the target user need to be expanded (that is, when the remaining buffer resources are less than the resource capacity threshold), the business processing resources in the shared resource pool can be sorted according to the priority score, and then the business processing resources with low priority scores (i.e., low priority) in the shared resource pool can be obtained. After performing resource initialization operations, including but not limited to setting resource status and configuring environment variables, the obtained business processing resources are added to the buffer resources. The specific details can be determined according to the actual application scenario and are not limited here. In this embodiment, business processing resources sorted according to scheduling priorities such as user priority, task priority, or resource type priority can be maintained in the shared resource pool, and initialization is completed by obtaining idle resources with scheduling priorities lower than the set threshold when obtaining business processing resources. By utilizing a priority threshold filtering mechanism, low-priority idle resources with minimal impact on business operations can be selected for initialization. This avoids high-priority resources being occupied, which could affect the resource guarantee for critical tasks or high-priority users. It preserves the schedulability of high-priority resources to maintain the stability of core businesses and the resource supply preparation for high-priority users, while also activating low-priority idle resources as business processing resources. This improves the resource utilization rate of the shared resource pool, achieving a balance between efficient resource reuse and business guarantee capabilities, and has high applicability.

[0067] In some feasible implementations, the terminal device can obtain the identity identifier of the target user carried in the aforementioned service processing request. This identity identifier can at least include a user identifier and a user priority. The user priority is set by the service level of the service processing service subscribed by the user. Based on this identity identifier, the terminal device can determine resources suitable for the target user and the service processing request from a shared resource pool shared by multiple users, and initialize these resources to create the service processing resources corresponding to the service processing request. It is understood that the terminal device can obtain the target user's identity identifier carried in the service processing request through a request parsing engine, etc. This identity identifier can at least include a user identifier (such as a user account or password) and a user priority. The terminal device can verify the user's permission scope based on the obtained user identifier, such as whether they are qualified to call a certain resource, and then pre-allocate matching resources to the user based on their priority. For example, the user priority can be abstracted into physical resource specifications, matching accelerated resource nodes to higher-level users. Optionally, the terminal device can also combine the real-time characteristics of the request to select the optimal resource node from the shared resource pool that satisfies both the identity constraint and the current load. Here, real-time characteristics may include, but are not limited to, the number of concurrent tasks and peak computing power demand carried in the request, which can be determined according to the actual application scenario and are not limited here. In this embodiment, by obtaining the identity identifier of the target user carried in the business processing request, resources that are compatible with the target user and request characteristics can be dynamically matched from the shared resource pool based on the identity identifier, and resource initialization can be completed to create dedicated business processing resources. This can achieve resource protection with differentiated service levels, ensure the compatibility between the matched resources and the target user, and improve the stability of business processing resource supply. The resource initialization and creation process combines user identifier and request characteristics, so that the generated business processing resources can have targeted processing capabilities. While reducing redundant resource occupation, it shortens the delay from the initiation of the business processing request to the readiness of the resources, and has high applicability.

[0068] S304, when the above-mentioned business processing resources are initialized, the business processing operation corresponding to the above-mentioned business processing request is taken over based on the above-mentioned business processing resources, and the above-mentioned target buffer resources are released.

[0069] In some feasible implementations, when the aforementioned service processing resources are initialized, the terminal device can utilize these initialized resources to take over the service processing operations corresponding to the service processing request and release the target buffer resources that previously executed the service processing operations. It is understood that the switch between service processing resources and target buffer resources can be direct or involve a smooth switching process; the specific choice depends on the actual application scenario and is not limited here. For ease of understanding, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is an interactive schematic diagram of the resource scheduling method provided in an embodiment of this application. For example... Figure 4 As shown, a target user can pre-allocate a portion of dedicated buffer resources to the terminal device before sending a service request (e.g., pre-allocating synchronously during target user registration; or pre-allocating by selecting a user level or priority during target user registration). Upon receiving a service processing request from a target user, the terminal device can call the target buffer resource from the corresponding buffer resource to quickly respond to the target user's service processing request, avoiding the long wait for resource initialization. Simultaneously, the terminal device can match the service processing resource corresponding to the service processing request from the shared resource pool, initialize the service processing resource, and then provide the service processing resource to the user after initialization to take over the service processing operation corresponding to the aforementioned service processing request, and release the target buffer resource (not shown in the figure).

[0070] In some feasible implementations, the terminal device can process a portion of the business processing operations requested by the aforementioned business processing request based on the business processing resources, and then process all the business processing operations requested by the aforementioned business processing request based on the aforementioned business processing resources after a preset transition time, thereby achieving a smooth transition of the business processing operations from the aforementioned target buffer resource to the aforementioned business processing resource. Here, the preset transition time can be set by the user or calculated from historical smooth switching times, and can be determined according to the actual application scenario, without limitation here. It can be understood that when the terminal device receives a business processing request sent by the user, it can immediately call the aforementioned target buffer resource to respond, and at the same time match and initialize the business processing resource in the shared resource pool. Then, after the business processing resource initialization is completed, a portion of the business processing operations are processed based on the business processing resource. Within the preset transition time window (e.g., 0-500 milliseconds), the aforementioned target buffer resource continues to process core business processing operations, while the business processing resource executes non-critical sub-tasks in parallel and warms up the business context (e.g., loading user data cache). After the transition period ends, the terminal device can verify the integrity of the business processing resource status (such as data synchronization offset detection). If the verification passes, all business processing operations can be completely handed over to the business processing resource, and the target buffer resource is released. If an abnormal status is detected (such as data inconsistency), it can automatically roll back to the target buffer resource to continue service, and can also trigger alarm mechanisms, etc. The specifics can be determined according to the actual application scenario and are not limited here. It can be understood that this smooth resource switching process can achieve a zero-jitter resource migration experience without the user's awareness. In the embodiments of this application, by processing part of the operations in the business processing request based on the business processing resource first, and then switching to processing all operations after a preset transition period, a smooth transition from the target buffer resource to the business processing resource can be achieved. This effectively avoids interruption of business processing operations or performance fluctuations at the moment of resource switching, maintains service continuity, and reserves a smooth transition time for the complete takeover of the business processing resource. At the same time, while ensuring business continuity, it reduces the risk of processing conflicts caused by sudden release or preemption of resources, optimizes the stability of the resource switching process, and has high applicability.

[0071] In some feasible implementations, the terminal device can determine the remaining amount of buffer resources corresponding to the target user through real-time detection or periodic scanning. When the remaining amount of resources is less than the resource capacity threshold, the target buffer resources can be added to the buffer resources corresponding to the target user to expand the buffer resources corresponding to the target user. When the remaining amount of resources is not less than the resource capacity threshold, the target buffer resources can be released to the state before initialization to obtain the target service processing resources corresponding to the target buffer resources, and the target service processing resources can be added to the shared resource pool. Here, the resource capacity threshold can be regarded as the lowest bit of the buffer resource set or buffer resource pool. It can be determined by the user based on the multi-dimensional resource usage in historical resource scheduling data, or it can be set by historical resource capacity thresholds. The specific determination can be made according to the actual application scenario, and there is no limitation here. Optionally, the resource capacity threshold can be the number of resources or the resource ratio, etc. The specific determination can be made according to the actual application scenario, and there is no limitation here. The setting of the resource capacity threshold can be referred to the foregoing embodiments, and will not be repeated here. It is understandable that when the remaining resource amount is less than the resource capacity threshold, for example, when the current buffer resources are insufficient (e.g., below 30% of the capacity threshold), and regular replenishment (i.e., obtaining low-priority resources from the shared resource pool) cannot replenish them in time, resulting in a low buffer resource level, or when there is a sudden high-priority request (e.g., a VIP user suddenly submitting a large-scale task), or when some buffer resources fail, the target buffer resources can be added to the buffer resources corresponding to the target user. Here, the target buffer resources that can be added to the corresponding buffer resources can be resources that are still available after being released by the user (e.g., virtual machine instances without data corruption or contamination), and can be directly reset (e.g., clearing the task process) and then directly added to the corresponding buffer resources. For easier understanding, please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is another interactive schematic diagram of the resource scheduling method provided in the embodiments of this application. For example... Figure 5As shown, upon receiving a service processing request from a target user (not shown in the figure), the request can be responded to using the target buffer resource in the buffer resource corresponding to the target user. Simultaneously, the service processing resource corresponding to the request is matched and initialized in the shared resource pool. After initialization, the service processing resource takes over the service processing operation and releases the target buffer resource. Here, it is assumed that the remaining resources are sufficient, meaning the remaining resources of the buffer resource corresponding to the target user are not less than the resource capacity threshold. The target buffer resource can then be released to its pre-initialization state to replenish the shared resource pool. In this embodiment, the remaining resource quantity of the buffer resource can be detected in real time, and the resource pre-allocation can be dynamically adjusted based on its comparison with the resource capacity threshold: when the remaining resources are insufficient, the target buffer resource can be added to the user's buffer resource to maintain the remaining resource quantity; when the remaining resources are sufficient, the target buffer resource can be released to its pre-initialization state and recycled back to the shared resource pool. The elastic adjustment mechanism based on threshold determination can prioritize the reserve of buffer resources for target users when resources are insufficient, ensuring a rapid response capability to subsequent business processing requests. It can also release resources and reclaim them to the shared resource pool when resources are redundant, avoiding long-term idleness of redundant buffer resources, improving the resource utilization rate of global resources, and has high applicability.

[0072] Furthermore, in some feasible implementations, the terminal device can also incorporate a feedback-based elastic scaling mechanism. If it detects that the actual resource utilization rate of high-priority users is consistently significantly lower than the predicted resource demand, the terminal device can gradually release redundant resources to the shared resource pool, avoiding long-term idleness. This maximizes overall resource utilization efficiency while ensuring the stability of core services. Please see also... Figure 5 ,like Figure 5 As shown, assuming that the actual resources of the target user are much smaller than the predicted resource demand, the buffer resources corresponding to the target user can release a small amount of redundant resources to the shared resource pool in order to maximize the global resource utilization efficiency.

[0073] In summary, the resource scheduling method provided in this application predicts resource demand by collecting historical resource scheduling data from each user, pre-allocates initialized buffer resources to each user, and then immediately invokes the corresponding buffer resources to achieve a rapid response when a business processing request is received from a target user. Simultaneously, it triggers the matching and initialization process of business processing resources within the shared resource pool. After the business processing resources are initialized, the business processing operation is taken over and the buffer resources are released. Utilizing historical resource scheduling data improves the accuracy of resource demand prediction, while the pre-loading mechanism of buffer resources reduces the latency of business processing request responses. Furthermore, the dynamic matching of business processing resources and the buffer resource reclamation mechanism improve overall resource utilization while ensuring user experience, demonstrating high applicability. Therefore, the resource scheduling method provided in this application can improve user experience and enhance product market competitiveness, providing various enterprises with a resource scheduling solution that is highly real-time, flexible, and has high resource utilization.

[0074] Based on the description of the resource scheduling method above, embodiments of this application also disclose a resource scheduling apparatus. This resource scheduling apparatus can be applied to... Figures 1 to 5 In the resource scheduling method of the illustrated embodiment, the resource scheduling device is used to execute the steps in the resource scheduling method, that is, the resource scheduling device can be the one described above. Figures 3 to 5 The execution entity in the resource scheduling method shown in the embodiment. See also Figure 6 , Figure 6 This is a schematic diagram of the resource scheduling device provided in an embodiment of this application. Figure 6 As shown in this embodiment, the resource scheduling device 60 can operate the following modules:

[0075] The data acquisition module 610 is used to acquire multiple historical resource scheduling data corresponding to multiple users, wherein one of the aforementioned users corresponds to one of the aforementioned historical resource scheduling data.

[0076] The prediction allocation module 620 is used to obtain the predicted resource demand of each user based on the historical resource scheduling data corresponding to each user, and to pre-allocate buffer resources to each user based on the predicted resource demand of each user. The buffer resources are available resources that have been pre-initialized and stored in the buffer resource pool and are in a state of waiting to be allocated.

[0077] The request response module 630 is used to, when receiving a business processing request from a target user among the multiple users, call the target buffer resource from the buffer resource corresponding to the target user, respond to the business processing request based on the target buffer resource, and at the same time match the business processing resource corresponding to the business processing request in the shared resource pool shared by the multiple users.

[0078] The resource switching module 640, when the initialization of the above-mentioned business processing resources is completed, takes over the business processing operation corresponding to the above-mentioned business processing request based on the above-mentioned business processing resources, and releases the above-mentioned target buffer resources.

[0079] In some feasible implementations, the prediction allocation module 620 described above is used for:

[0080] Obtain the target historical resource scheduling data for each user within the historical target time period from the historical resource scheduling data for each user, input the target historical resource scheduling data for each user into the resource prediction model, and output the predicted resource demand for each user within the future target time period corresponding to the historical target time period through the resource prediction model.

[0081] The aforementioned resource prediction model includes at least one of a machine learning model or a deep learning model.

[0082] In some feasible implementations, the prediction allocation module 620 described above is used for:

[0083] Based on the predicted resource requirements of each user, pre-allocate business processing resources to each user and mark the pre-allocated business processing resources as dedicated business processing resources for each user.

[0084] The dedicated business processing resources of each of the aforementioned users are initialized, and the resources after initialization are frozen into resources that have been initialized and are in a state of waiting to be scheduled through memory snapshot technology, so as to obtain multiple buffer resources corresponding to the aforementioned multiple users.

[0085] In some feasible implementations, the request-response module 630 described above is used for:

[0086] Obtain at least one free buffer resource from the buffer resources corresponding to the target user as the target buffer resource, and call the target buffer resource through the readily available scheduling interface to respond to the business processing request through the target buffer resource.

[0087] The aforementioned readily available scheduling interface includes at least one of a memory access channel or a dedicated application programming interface (API) channel, and the aforementioned buffer resources include at least one of computing resources, storage resources, or network resources.

[0088] In some feasible implementations, the resource switching module 640 described above is used for:

[0089] Determine the remaining amount of buffer resources corresponding to the aforementioned target users;

[0090] When the remaining resource amount is less than the resource capacity threshold, the target buffer resource is added to the buffer resource corresponding to the target user to expand the buffer resource corresponding to the target user.

[0091] When the remaining resource amount is not less than the resource capacity threshold, the target buffer resource is released to the state before initialization to obtain the target business processing resource corresponding to the target buffer resource, and the target business processing resource is added to the shared resource pool.

[0092] In some feasible implementations, the request-response module 630 is further configured to:

[0093] Determine the amount of remaining buffer resources in the buffer resources corresponding to the target users, excluding the target buffer resources;

[0094] When the remaining buffer resources are less than the resource capacity threshold, idle business processing resources are obtained from the shared resource pool and initialized. The initialized business processing resources are then added to the buffer resources corresponding to the target user.

[0095] In some feasible implementations, the prediction allocation module 620 described above is further used for:

[0096] The resource capacity threshold is set based on the historical target time period within the pre-allocation cycle of business processing resources, wherein the historical target time period is a portion of the pre-allocation cycle of business processing resources; or...

[0097] The resource capacity threshold is set based on the resource node types included in the historical resource scheduling data, wherein the resource node type is either a resource center node or a resource edge node; or,

[0098] The resource capacity threshold is set based on the historical resource configuration information included in the aforementioned historical resource scheduling data, wherein the aforementioned historical resource configuration information includes at least the resource type and the resource's business processing capacity; or,

[0099] The resource capacity threshold is set according to the user priority of each of the aforementioned users, wherein the user priority is set by the service level of the business processing service subscribed by the aforementioned users.

[0100] In some feasible implementations, the shared resource pool includes multiple service processing resources sorted according to different scheduling priorities; the request response module 630 is used for:

[0101] Obtain idle resources with scheduling priorities lower than the priority threshold from the above multiple business processing resources, and complete the initialization;

[0102] The scheduling priority mentioned above is set by at least one of the following priority setting rules: user priority, task priority, and resource type priority.

[0103] In some feasible implementations, the resource switching module 640 described above is used for:

[0104] Based on the aforementioned business processing resources, a portion of the business processing operations requested by the aforementioned business processing request are processed, and after a preset transition time, all the business processing operations requested by the aforementioned business processing request are processed based on the aforementioned business processing resources, so as to achieve a smooth transition of the aforementioned business processing operations from the aforementioned target buffer resources to the aforementioned business processing resources.

[0105] In some feasible implementations, the request-response module 630 described above is used for:

[0106] Obtain the identity identifier of the target user carried in the above-mentioned business processing request. The identity identifier includes at least a user identifier and a user priority, wherein the user priority is set by the service level of the business processing service subscribed by the user.

[0107] Based on the aforementioned identity identifier, resources suitable for the aforementioned target user and the aforementioned business processing request are determined from the shared resource pool shared by the aforementioned multiple users, and the aforementioned resources are initialized to create the business processing resource corresponding to the aforementioned business processing request.

[0108] In the embodiments of this application, the modules in the device shown in the figures above can be individually or entirely combined into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effect of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In other feasible implementations of this application, the device may also include other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules, without limitation.

[0109] In some feasible implementations, the above Figures 3 to 5 The implementation methods provided for each step in the resource scheduling method shown can be derived from... Figure 6 The various modules of the illustrated device are executed. For example, the above... Figure 3 In the resource scheduling method shown, step S301 can be performed by... Figure 6 The data acquisition module 610 in the device shown executes the steps, and step S302 can be performed by the data acquisition module 610 in the device shown. Figure 6The prediction allocation module 620 in the device shown executes the steps, and step S303 can be performed by the following components: Figure 6 The request-response module 630 in the device shown executes the steps, and step S304 can be performed by the following methods respectively: Figure 6 The resource switching module 640 in the illustrated device is executed. The implementation method of this module can be found in the implementation methods provided in the various steps of the above embodiments, and will not be repeated here.

[0110] In summary, the resource scheduling device provided in this application embodiment comprises at least a data acquisition module, a prediction and allocation module, a request and response module, and a resource switching module. It can acquire historical resource scheduling data from each user to predict resource demand using a model, pre-allocate initialized buffer resources to each user, and then immediately invoke the corresponding buffer resources to achieve a rapid response when a business processing request is received from a target user. Simultaneously, it triggers the matching and initialization process of business processing resources within the shared resource pool. After the business processing resources are initialized, it takes over the business processing operation and releases the buffer resources. Utilizing historical resource scheduling data improves the accuracy of resource demand prediction, while the pre-loading mechanism of buffer resources reduces the latency of business processing request responses. Furthermore, the dynamic matching of business processing resources and the buffer resource reclamation mechanism can improve overall resource utilization while ensuring user experience, demonstrating high applicability. Therefore, the resource scheduling method provided in this application embodiment can improve user experience and enhance product market competitiveness, providing various enterprises with a resource scheduling solution that is highly real-time, flexible, and has high resource utilization.

[0111] See Figure 7 , Figure 7 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. For example... Figure 7 As shown, the terminal device 1000 can be the above-mentioned Figures 1-5The terminal device in the corresponding embodiment. The terminal device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the terminal device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 7 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0112] The network interface 1004 in the terminal device 1000 can also be connected to the aforementioned Figure 1 The terminal device 200c in the corresponding embodiment connects to the network, and the optional user interface 1003 may further include a display screen and a keyboard. Figure 7 In the terminal device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to implement the aforementioned... Figure 3 Resource scheduling method in the corresponding embodiment.

[0113] It should be understood that the terminal device 1000 described in the embodiments of this application can execute the foregoing text. Figures 3 to 5 The description of resource scheduling in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0114] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which are implemented when executed by a processor. Figures 3 to 5 The resource scheduling methods provided in each step are detailed above. Figures 3 to 5 The implementation methods provided for each step will not be elaborated here.

[0115] The aforementioned computer-readable storage medium can be the resource scheduling device provided in any of the foregoing embodiments or the internal storage unit of the aforementioned computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium may include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0116] The term "comprising," and any variations thereof, in the specification, claims, and drawings of this application are intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to such processes, methods, apparatus, products, or devices.

[0117] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0118] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0119] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A resource scheduling method, characterized in that, The method comprises: obtaining a plurality of historical resource scheduling data corresponding to a plurality of users, wherein one user corresponds to one historical resource scheduling data; obtaining a predicted resource demand of each user according to the historical resource scheduling data corresponding to each user, and pre-allocating buffer resources to each user according to the predicted resource demand of each user, wherein the buffer resources are available resources that are pre-initialized and stored in a buffer resource pool and are in a state of waiting for allocation; when a service processing request of a target user in the plurality of users is received, calling a target buffer resource from the buffer resource corresponding to the target user, responding to the service processing request based on the target buffer resource, and matching a service processing resource corresponding to the service processing request in a shared resource pool shared by the plurality of users; when the service processing resource is initialized, taking over the service processing operation corresponding to the service processing request based on the service processing resource, and releasing the target buffer resource.

2. The method of claim 1, wherein, The method further comprises: obtaining target historical resource scheduling data corresponding to each user in a historical target period from the historical resource scheduling data corresponding to each user, inputting the target historical resource scheduling data corresponding to each user into a resource prediction model, and outputting a predicted resource demand of each user in a future target period corresponding to the historical target period through the resource prediction model; wherein the resource prediction model comprises at least one of a machine learning model or a deep learning model.

3. The method of claim 2, wherein, The method further comprises: pre-allocating a service processing resource to each user according to the predicted resource demand of each user, and marking the service processing resource pre-allocated to each user as an exclusive service processing resource of each user; initializing the exclusive service processing resource of each user, and freezing the initialized resource into a resource that is initialized and in a state of waiting for scheduling through a memory snapshot technology, to obtain a plurality of buffer resources corresponding to the plurality of users.

4. The method of claim 3, wherein, The method further comprises: obtaining at least one idle buffer resource as a target buffer resource from the buffer resource corresponding to the target user, and calling the target buffer resource through an instant available scheduling interface to respond to the service processing request through the target buffer resource; wherein the instant available scheduling interface comprises at least one of a memory access channel or a dedicated application programming interface channel, and the buffer resource comprises at least one of a computing resource, a storage resource, or a network resource.

5. The method of claim 4, wherein, The method further comprises: determining a remaining resource amount of the buffer resource corresponding to the target user; when the remaining resource amount is less than the resource capacity threshold, supplementing the target buffer resource into the buffer resource corresponding to the target user to expand the buffer resource corresponding to the target user, wherein the target buffer resource supplemented into the buffer resource corresponding to the target user is a resource in an available state after being released by a user; when the remaining resource amount is not less than the resource capacity threshold, releasing the target buffer resource to a state before initialization to obtain a target service processing resource corresponding to the target buffer resource, and supplementing the target service processing resource into the shared resource pool.

6. The method of claim 4, wherein, After the method of responding to the service processing request based on the target buffer resource, the method further comprises: determining a remaining buffer resource amount in the buffer resource corresponding to the target user except for the target buffer resource; when the remaining buffer resource amount is less than the resource capacity threshold, obtaining an idle service processing resource from the shared resource pool and completing initialization, and supplementing the service processing resource after initialization into the buffer resource corresponding to the target user.

7. The method according to claim 5 or 6, characterized in that, Before the method of pre-allocating buffer resources for each user according to the predicted resource demand amount of each user, the method further comprises: setting the resource capacity threshold according to a time period position of a historical target time period in a service processing resource pre-allocation period, wherein the historical target time period is a time length in the service processing resource pre-allocation period; or setting the resource capacity threshold according to a resource node type included in the historical resource scheduling data, wherein the resource node type is one of a resource center node or a resource edge node; or setting the resource capacity threshold according to historical resource configuration information included in the historical resource scheduling data, wherein the historical resource configuration information at least includes a resource type and a service processing capability of a resource; or setting the resource capacity threshold according to a user priority of each user, wherein the user priority is set by a service level of a service processing service subscribed by the user.

8. The method of claim 6, wherein, The shared resource pool includes multiple service processing resources sorted according to different scheduling priorities; the method of obtaining an idle service processing resource from the shared resource pool and completing initialization comprises: obtaining an idle resource with a scheduling priority lower than a priority threshold from the multiple service processing resources and completing initialization; wherein the scheduling priority is set by at least one of a user priority, a task priority, and a resource type priority.

9. The method according to any one of claims 1 to 6, characterized in that, The method of taking over the service processing operation corresponding to the service processing request based on the service processing resource comprises: processing part of the service processing operation requested by the service processing request based on the service processing resource, and processing all of the service processing operation requested by the service processing request based on the service processing resource after a preset transition time, to realize smooth transition of the service processing operation from the target buffer resource to the service processing resource.

10. The method according to any one of claims 1 to 6, characterized in that, The method of matching the service processing resource corresponding to the service processing request in the shared resource pool shared by the multiple users comprises: obtaining an identity of the target user carried in the service processing request, the identity comprising at least a user identifier and a user priority, wherein the user priority is set by a service level of a service processing service subscribed by the user; determining a resource suitable for the target user and the service processing request from a shared resource pool shared by the plurality of users based on the identity, and initializing the resource to create a service processing resource corresponding to the service processing request.

11. A resource scheduling apparatus, characterized by comprising: comprise: a data acquisition module configured to acquire a plurality of historical resource scheduling data corresponding to a plurality of users, wherein one user corresponds to one historical resource scheduling data; a prediction allocation module configured to acquire a predicted resource demand of each user according to the historical resource scheduling data corresponding to each user, and pre-allocate buffer resources to each user according to the predicted resource demand of each user, wherein the buffer resources are available resources pre-initialized and stored in a buffer resource pool in a to-be-allocated state; a request response module configured to, when receiving a service processing request of a target user in the plurality of users, invoke a target buffer resource from the buffer resources corresponding to the target user, respond to the service processing request based on the target buffer resource, and match a service processing resource corresponding to the service processing request in a shared resource pool shared by the plurality of users; a resource switching module configured to, when the service processing resource is initialized, take over a service processing operation corresponding to the service processing request based on the service processing resource, and release the target buffer resource.

12. The apparatus of claim 11, wherein, The prediction allocation module is configured to: acquire target historical resource scheduling data corresponding to each user in a historical target period from the historical resource scheduling data corresponding to each user, and input the target historical resource scheduling data corresponding to each user into a resource prediction model to output a predicted resource demand of each user in a future target period corresponding to the historical target period through the resource prediction model; wherein the resource prediction model comprises at least one of a machine learning model or a deep learning model.

13. The apparatus of claim 12, wherein, The prediction allocation module is configured to: pre-allocate a service processing resource to each user according to the predicted resource demand of each user, and mark the service processing resource pre-allocated to each user as an exclusive service processing resource of each user; initialize the exclusive service processing resource of each user, and freeze the initialized resource into a resource initialized and in a to-be-scheduled state through a memory snapshot technology to obtain a plurality of buffer resources corresponding to the plurality of users.

14. The apparatus of claim 13, wherein, The request response module is configured to: acquire at least one idle buffer resource as a target buffer resource from the buffer resources corresponding to the target user, and invoke the target buffer resource through an instant available scheduling interface to respond to the service processing request through the target buffer resource; The instant-available scheduling interface includes at least one of a memory access channel or a dedicated application programming interface (API) channel, and the buffer resource includes at least one of a computing resource, a storage resource, or a network resource.

15. A terminal device, comprising: The terminal device includes a processor and a memory; The processor is connected with the memory, where the memory is configured to store program code, and the processor is configured to invoke the program code to perform the method in any one of claims 1 to 10.

Images