Request scheduling method and device, product, equipment and medium

Abstract

The invention discloses a request scheduling method and device, a product, equipment and a medium. The method comprises the following steps: sending a state check request to each server node in a node pool; receiving an equipment operation state returned by each server node; adjusting a scheduling weight corresponding to each server node based on the equipment running state of each server node; a target server node is determined from the node pool, and the target server node is a server node used for processing the request; and scheduling the request to each target server node according to the proportion of the scheduling weight of each target server node. Thus, the equipment running state of the server node is checked, the scheduling weight is the weight adjusted based on the equipment running state, it can be guaranteed that the request is reasonably scheduled to the target server node according to the proportion, server resources can be reasonably utilized, and the system performance is improved.

Description

Technical Field

[0001] The present application relates to the field of server technology, and in particular to a request scheduling method, device, product, equipment and medium. Background Art

[0002] In order to ensure the stable operation of the system, server checks are required. Currently, the load balancing device sends HTTP (Hypertext Transfer Protocol) requests to the real server and then waits for the server's response. If a correct response is received within the expected time, the node is considered healthy. Otherwise, the node is considered offline. If the node is healthy, it is available.

[0003] Although the existing server check scheme checks whether the node is available, it cannot provide a basis for the rational use of server resources, which affects system performance. Therefore, how to schedule requests based on the check results when checking the server, rationally use server resources, and improve system performance is a problem that needs to be solved at present. Summary of the invention

[0004] In view of this, the purpose of this application is to provide a request scheduling method, device, product, equipment and medium, which can reasonably utilize server resources and improve system performance. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a request scheduling method, comprising:

[0006] Send status check requests to each server node in the node pool;

[0007] Receiving the device operation status returned by each of the server nodes;

[0008] Adjusting the scheduling weights corresponding to the server nodes based on the device operation status of the server nodes themselves;

[0009] Determining a target server node from the node pool, wherein the target server node is a server node for processing the request;

[0010] The request is dispatched to each of the target server nodes according to the ratio of the dispatch weight of each of the target server nodes.

[0011] Optionally, after receiving the device operation status returned by each of the server nodes, the method further includes:

[0012] Comparing the device operation status of any of the server nodes with a preset threshold;

[0013] If the device operation state exceeds the preset threshold, marking the node state of any server node as a busy state;

[0014] Correspondingly, determining the target server node from the node pool includes:

[0015] When the preset busy state scheduling policy is to allow scheduling, the server nodes whose node states are busy and the normal server nodes in the node pool are determined as target server nodes, and the normal server nodes are server nodes in non-busy states and receiving the device operation status;

[0016] When the preset busy state scheduling strategy is scheduling failure, the normal server node in the node pool is determined as the target server node.

[0017] Optionally, the allowed scheduling includes forced scheduling and queuing, wherein the forced scheduling is to schedule the server node in the busy state as a normal server node, and the queuing is to place the request scheduled to the server node in the busy state into the queue corresponding to the server node in the busy state, and wait for the server node in the busy state to change to a normal server node before processing the request in the queue.

[0018] Optionally, the device operation status includes multiple pieces of status information, and the adjusting the scheduling weights corresponding to the server nodes based on the device operation status of the server nodes themselves includes:

[0019] Performing weighted calculation based on the multiple pieces of status information of each of the server nodes to obtain a weight adjustment value corresponding to each of the server nodes;

[0020] The adjusted scheduling weight is determined based on the weight adjustment value and the current scheduling weight, and the scheduling weights corresponding to each of the server nodes are obtained.

[0021] Optionally, the device operating status includes usage of one or more of a CPU, a memory, and a disk.

[0022] Optionally, sending a status check request to each server node in the node pool includes:

[0023] Encapsulate status check request based on SNMP protocol;

[0024] The status check request is sent to each server node in the node pool.

[0025] In a second aspect, the present application discloses a request scheduling device, comprising:

[0026] A request sending module is used to send status check requests to each server node in the node pool;

[0027] A status receiving module, used for receiving the device operation status returned by each of the server nodes;

[0028] A weight adjustment module, used for adjusting the scheduling weights corresponding to each of the server nodes based on the device operation status of each of the server nodes;

[0029] A node determination module, used to determine a target server node from the node pool, wherein the target server node is a server node used to process the request;

[0030] The request scheduling module is used to schedule the request to each of the target server nodes according to the proportion of the scheduling weight of each of the target server nodes.

[0031] In a third aspect, the present application discloses a computer program product, which implements the aforementioned request scheduling method when executed.

[0032] In a fourth aspect, the present application discloses an electronic device, including a memory and a processor, wherein:

[0033] The memory is used to store the computer program;

[0034] The processor is used to execute the computer program to implement the aforementioned request scheduling method.

[0035] In a fifth aspect, the present application discloses a computer-readable storage medium for storing a computer program, wherein the computer program implements the aforementioned request scheduling method when executed by a processor.

[0036] It can be seen from the above scheme that the present application provides a request scheduling method, including: sending a status check request to each server node in a node pool; receiving the device operation status returned by each of the server nodes; adjusting the scheduling weights corresponding to each of the server nodes based on the device operation status of each of the server nodes themselves; determining a target server node from the node pool, wherein the target server node is a server node used to process the request; and scheduling the request to each of the target server nodes according to the ratio of the scheduling weights of each of the target server nodes.

[0037] It can be seen that the beneficial effects of the present application are: when performing a server node inspection, the device operating status of the server node is checked, and the scheduling weight of the server node is adjusted based on the device operating status, so that the request is scheduled to the target server node in proportion to the scheduling weight. Since the scheduling weight is adjusted based on the device operating status, it can ensure that the request is reasonably scheduled to the target server node in proportion. In this way, server resources can be reasonably utilized and system performance can be improved.

[0038] Correspondingly, a request scheduling device, product, equipment and readable storage medium provided by the present application also have the above-mentioned technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0040] Figure 1 A flowchart of a request scheduling method provided in an embodiment of the present application;

[0041] Figure 2 A schematic diagram of a server status check provided in an embodiment of the present application;

[0042] Figure 3 A schematic diagram of the structure of a request scheduling device provided in an embodiment of the present application;

[0043] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0045] First, the professional terms involved in this application are explained:

[0046] SNMP (Simple Network Management Protocol) is a standard protocol designed specifically for managing network nodes (servers, workstations, routers, switches, and Hubs, etc.) in IP (Internet Protocol) networks. SNMP enables network administrators to manage network performance, discover and solve network problems, and plan network growth. By receiving random messages (and event reports) through SNMP, network management systems are informed of network problems.

[0047] HTTP is a simple request-response protocol that usually runs on top of TCP (Transmission Control Protocol). It specifies what messages a client may send to a server and what responses it may get. The headers of request and response messages are given in ASCII (Standard Code for Information Interchange).

[0048] LB (Load balancing) is a computer technology used to distribute load among multiple computers (computer clusters), network connections, CPUs (Central Processing Units), disk drives, or other resources to optimize resource usage, maximize throughput, minimize response time, and avoid overload. Using multiple server components with load balancing instead of a single component can improve reliability through redundancy.

[0049] Node is a real server. After receiving the client's request, LB needs to forward it to the node. The node responds according to the request.

[0050] See also Figure 1 As shown, the embodiment of the present application discloses a request scheduling method, including:

[0051] Step S11: Send a status check request to each server node in the node pool.

[0052] The status check request is a constructed request for obtaining the device operation status of the server node. In this embodiment, a status check request can be sent to each server node to obtain the device operation status of each server node. The device operation status may include one or more status information, and the status information may be understood as information reflecting the device operation status of the server node.

[0053] In an optional implementation, a status check request may be sent to each server node in the node pool at a regular interval. If the device operation status returned by any server node is not received, the node status of the server node is set to an offline state.

[0054] In an optional implementation, the status check request may be encapsulated based on the SNMP protocol; and the status check request may be sent to each server node in the node pool.

[0055] Step S12: receiving the device operation status returned by each of the server nodes.

[0056] The device operation status includes, but is not limited to, the usage of one or more of the CPU, memory, and disk. For example, the device operation status includes the usage of the CPU, memory, and disk, which are three pieces of status information. The usage can be understood as information that characterizes resource utilization, such as utilization rate, remaining capacity, etc.

[0057] In an optional implementation, after receiving the device operation status returned by each of the server nodes, the method further includes: comparing the device operation status of any of the server nodes with a preset threshold; if the device operation status exceeds the preset threshold, marking the node status of any of the server nodes as a busy state. If the device operation status does not exceed the preset threshold, marking the node status of any of the server nodes as an online state.

[0058] Wherein, when the device operation status of the server node includes multiple status information, and any status information exceeds the preset threshold corresponding to the status information, the node status of the server node is marked as busy. If the multiple status information does not exceed the preset threshold corresponding to each, the node status of the server node is marked as online. Different status information items may correspond to different preset thresholds.

[0059] For example, if one of the CPU, memory, and disk usage exceeds the corresponding preset threshold, the node status of the server node is marked as busy. If the CPU, memory, and disk usage do not exceed the corresponding preset thresholds, the node status of the server node is marked as online.

[0060] Step S13: adjusting the scheduling weights corresponding to the server nodes based on the device operation status of the server nodes themselves.

[0061] In an optional implementation, a weighted calculation can be performed based on the multiple pieces of status information of each of the server nodes to obtain a weight adjustment value corresponding to each of the server nodes; based on the weight adjustment value and the current scheduling weight, an adjusted scheduling weight is determined to obtain a scheduling weight corresponding to each of the server nodes.

[0062] The embodiment of the present application can perform weighted calculation based on the multiple pieces of status information of each server node and the weights corresponding to the multiple pieces of status information to obtain the weight adjustment value corresponding to each server node.

[0063] For example, the multiple pieces of status information are the usage of CPU, memory and disk. The first formula can be used to perform weighted calculation based on the multiple pieces of status information of each server node and the weights corresponding to the multiple pieces of status information to obtain the weight adjustment value corresponding to each server node. The first formula is:

[0064] ;

[0065] Among them, Rc, Rm, and Rd are the pre-configured weights corresponding to the CPU, memory, and disk, respectively. LOAD is the weight adjustment value. CPU, MEMORY, and DISK represent the usage of the CPU, memory, and disk, respectively, or the normalized values ​​of the usage of the CPU, memory, and disk.

[0066] Furthermore, the second formula can be used to determine the adjusted scheduling weight based on the weight adjustment value and the current scheduling weight to obtain the scheduling weights corresponding to each of the server nodes. The second formula is:

[0067] ;

[0068] Among them, Wd is the original weight of the node, that is, the current scheduling weight, and W is the adjusted scheduling weight.

[0069] Step S14: determining a target server node from the node pool, wherein the target server node is a server node for processing the request.

[0070] In an optional embodiment, when the preset busy state scheduling policy is to allow scheduling, the server nodes in the node pool whose node status is busy and the normal server nodes are determined as target server nodes, and the normal server nodes are server nodes in non-busy status and have received the device operation status; when the preset busy state scheduling policy is scheduling failure, the normal server nodes in the node pool are determined as target server nodes.

[0071] Wherein, the allowed scheduling includes forced scheduling and queuing, wherein the forced scheduling is to schedule the server node in the busy state as a normal server node, and the queuing is to place the request scheduled to the server node in the busy state into the queue corresponding to the server node in the busy state, and wait for the server node in the busy state to change to a normal server node to process the request in the queue. It can be understood that although the strategy is to schedule the request to the server node in the busy state when queuing, it is first placed in the queue corresponding to the server node, and wait for the server node in the busy state to change to a normal server node to process the request in the queue. That is, in the subsequent inspection process, when it changes to the online state, the request in the queue is processed. In the embodiment of the present application, regardless of whether the node state is the node online, the node offline or the node busy, the load balancing device will send a status check request to the server node in the node pool again after a period of time.

[0072] That is, the embodiment of the present application can determine the target server node of the request to be processed based on the node status. The server node in the online state is a normal server node and can be determined as the target server node. The server node in the busy state can be determined as the target server node based on the policy judgment. The busy state scheduling policy configured by the user can be obtained to obtain the preset busy state scheduling policy. That is, the user can set the node scheduling policy of the busy state according to the needs.

[0073] Step S15: Scheduling the request to each of the target server nodes according to the proportion of the scheduling weight of each of the target server nodes.

[0074] That is, the requests are dispatched to the target server nodes in turn according to the proportion of the scheduling weights, so that the proportion of the number of requests processed by each target server node is the proportion of the scheduling weights.

[0075] For example, if there are three target server nodes, the scheduling weights are 1, 2, and 3 respectively, and the client sends a total of 60 requests, then the number of requests allocated to the three nodes is 10, 20, and 30.

[0076] It can be seen that when the embodiment of the present application performs a server node check, it checks the device operating status of the server node and adjusts the scheduling weight of the server node based on the device operating status, so that the request is scheduled to the target server node in proportion to the scheduling weight. Since the scheduling weight is adjusted based on the device operating status, it can ensure that the request is reasonably scheduled to the target server node in proportion. In this way, server resources can be reasonably utilized and system performance can be improved.

[0077] The request scheduling method provided in the embodiment of the present application can be applied to a load balancing device, see Figure 2As shown, the embodiment of the present application discloses a schematic diagram of server status check, and based on the status check result, request scheduling can be implemented. Specifically, the following steps may be included:

[0078] Create SNMP-based health checks: Set CPU, memory, and disk thresholds and query the CPU, memory, and disk consumption of nodes in real time. SNMP-based health checks are functional components running on load balancing devices.

[0079] Create a node pool: A node pool is a collection of nodes. Each node in the node pool is a real server. The load balancing device will schedule traffic based on the node scheduling algorithm and the scheduling weight of each node. The node pool references SNMP health check. The load balancing device will check the device operation status of each node in the node pool.

[0080] The load balancing device sends an SNMP request: The load balancing device constructs an SNMP request, which includes the usage of the system CPU, memory, and disk, and sends the request to each node in the node pool.

[0081] The load balancing device receives SNMP responses: When the load balancing device receives an SNMP response within the timeout period, it determines whether the CPU, memory, and disk running in real time on the device exceed the threshold of the SNMP health check. If any of these exceeds the threshold, the node will be set to busy. When the node is busy, three busy strategies can be configured: forced scheduling, queuing, and scheduling failure. Among them, scheduling failure: requests sent by the client will no longer be scheduled to the busy node. This option is the default value. Queuing: Client requests will still be scheduled to the node, but will not be processed immediately, but will enter a queue. When the node returns to normal from busy, the requests queued in the queue will be reprocessed. Forced scheduling: busy is treated as online processing, and client requests are normally scheduled to busy nodes. At the same time, the load balancing will adjust the weight of each node according to the following two formulas.

[0082] ;

[0083] ;

[0084] Among them, Rc, Rm, and Rd are the CPU weight, memory weight, and disk weight configured in the SNMP node monitor, respectively. Wd is the original weight of the node, and W is the adjusted weight. The SNMP node monitor is the aforementioned SNMP-based health check. When the node is online, the load balancing device will distribute the requests sent by the client according to the proportion of the node weight. For example, there are three nodes in the node pool, and the weights are 1, 2, and 3 respectively. The client sent a total of 60 requests. Then the number of requests allocated to the three nodes is 10, 20, and 30.

[0085] When the load balancing device does not receive a response from a node within the timeout period, it indicates that the node has failed and the node status is set to offline. New requests from the client will no longer be dispatched to the offline node. The load balancing device resends SNMP requests: Regardless of whether the node status is online, offline, or busy, the load balancing device will resend SNMP requests to the node after a period of time to continuously update the node's device operation status.

[0086] In this embodiment, the load balancing device obtains the device operation status of the node through the SNMP protocol, and dynamically adjusts the scheduling weight and status of the node according to the device operation status. The device operation status of the node sensed through SNMP includes CPU, memory and disk, and the node scheduling weight and status are adjusted according to the node CPU, memory and disk usage obtained by SNMP. In this way, based on the SNMP protocol, the device operation status of the node is checked in real time. The load balancing device will dynamically adjust the scheduling weight of the node according to the resource consumption of the node, so that the client's request is scheduled to the node with less resource consumption. When the resource consumption of the node exceeds the set threshold, the load balancing device will set the node to a busy state. Then schedule the client request according to the node status. It can perceive the resource consumption of the node device, such as the CPU, memory, disk and other resource consumption of the node, so as to select a better strategy to schedule the client request.

[0087] See also Figure 3 As shown, the embodiment of the present application discloses a request scheduling device, including:

[0088] A request sending module 11 is used to send a status check request to each server node in the node pool;

[0089] A status receiving module 12 is used to receive the device operation status returned by each of the server nodes;

[0090] A weight adjustment module 13, configured to adjust the scheduling weights corresponding to the server nodes based on the device operation status of the server nodes themselves;

[0091] A node determination module 14, configured to determine a target server node from the node pool, wherein the target server node is a server node for processing a request;

[0092] The request scheduling module 15 is used to schedule the request to each of the target server nodes according to the proportion of the scheduling weight of each of the target server nodes.

[0093] The device further comprises a status checking module, which is used to compare the device operation status of any of the server nodes with a preset threshold value; if the device operation status exceeds the preset threshold value, the node status of any of the server nodes is marked as a busy state;

[0094] Accordingly, the node determination module 14 is specifically used for:

[0095] When the preset busy state scheduling policy is to allow scheduling, the server nodes whose node states are busy and the normal server nodes in the node pool are determined as target server nodes, and the normal server nodes are server nodes in non-busy states and receiving the device operation status;

[0096] When the preset busy state scheduling strategy is scheduling failure, the normal server node in the node pool is determined as the target server node.

[0097] Among them, the allowed scheduling includes forced scheduling and queuing, wherein the forced scheduling is to schedule the server node in the busy state as a normal server node, and the queuing is to place the request scheduled to the server node in the busy state into the queue corresponding to the server node in the busy state, and wait for the server node in the busy state to change to a normal server node to process the request in the queue.

[0098] The weight adjustment module 13 is specifically used for: the device operation status includes multiple status information, and weighted calculation is performed based on the multiple status information of each server node itself to obtain the weight adjustment value corresponding to each server node itself; based on the weight adjustment value and the current scheduling weight, the adjusted scheduling weight is determined to obtain the scheduling weight corresponding to each server node.

[0099] The device operation status includes one or more usage of the CPU, memory, and disk.

[0100] In an optional implementation, the request sending module 11 is specifically used to: encapsulate a status check request based on the SNMP protocol; and send the status check request to each server node in the node pool.

[0101] It can be seen that when the embodiment of the present application performs a server node check, it checks the device operating status of the server node and adjusts the scheduling weight of the server node based on the device operating status, so that the request is scheduled to the target server node in proportion to the scheduling weight. Since the scheduling weight is adjusted based on the device operating status, it can ensure that the request is reasonably scheduled to the target server node in proportion. In this way, server resources can be reasonably utilized and system performance can be improved.

[0102] An embodiment of the present application discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the request scheduling method disclosed in the aforementioned embodiment.

[0103] For the specific process of the above-mentioned request scheduling method, reference may be made to the corresponding contents disclosed in the above-mentioned embodiments, which will not be repeated here.

[0104] See also Figure 4 As shown, the embodiment of the present application discloses an electronic device 20, including a processor 21 and a memory 22; wherein the memory 22 is used to store a computer program; and the processor 21 is used to execute the computer program to implement the following steps:

[0105] Send a status check request to each server node in the node pool; receive the device operation status returned by each of the server nodes; adjust the scheduling weights corresponding to each of the server nodes based on the device operation status of each of the server nodes; determine the target server node from the node pool, wherein the target server node is a server node for processing the request; and schedule the request to each of the target server nodes in proportion to the scheduling weights of the target server nodes.

[0106] It can be seen that when the embodiment of the present application performs a server node check, it checks the device operating status of the server node and adjusts the scheduling weight of the server node based on the device operating status, so that the request is scheduled to the target server node in proportion to the scheduling weight. Since the scheduling weight is adjusted based on the device operating status, it can ensure that the request is reasonably scheduled to the target server node in proportion. In this way, server resources can be reasonably utilized and system performance can be improved.

[0107] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, the following steps can be specifically implemented: after receiving the device operation status returned by each of the server nodes, the device operation status of any of the server nodes is compared with a preset threshold; if the device operation status exceeds the preset threshold, the node status of any of the server nodes is marked as a busy state; accordingly, when the preset busy state scheduling strategy is to allow scheduling, the server nodes with busy state and normal server nodes in the node pool are determined as target server nodes, and the normal server nodes are server nodes in non-busy state and have received the device operation status; when the preset busy state scheduling strategy is scheduling failure, the normal server nodes in the node pool are determined as target server nodes. The allowed scheduling includes forced scheduling and queuing, wherein the forced scheduling is to schedule the server nodes in the busy state as normal server nodes, and the queuing is to place the requests scheduled to the server nodes in the busy state into the queue corresponding to the server nodes in the busy state, and wait for the server nodes in the busy state to change to normal server nodes to process the requests in the queue.

[0108] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, the following steps can be specifically implemented: the device operation state includes multiple state information, and weighted calculation is performed based on the multiple state information of each server node itself to obtain the weight adjustment value corresponding to each server node itself; based on the weight adjustment value and the current scheduling weight, the adjusted scheduling weight is determined to obtain the scheduling weight corresponding to each server node. The device operation state includes the usage of one or more of the CPU, memory, and disk.

[0109] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, the following steps may be specifically implemented: encapsulating a status check request based on the SNMP protocol; and sending the status check request to each server node in the node pool.

[0110] Furthermore, the memory 22 as a carrier for storing resources may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the storage method may be temporary storage or permanent storage.

[0111] In addition, the electronic device 20 also includes a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26; wherein the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and an external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input / output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0112] Furthermore, the embodiment of the present application also discloses a computer-readable storage medium for storing a computer program, wherein when the computer program is executed by a processor, the following steps are implemented:

[0113] Send a status check request to each server node in the node pool; receive the device operation status returned by each of the server nodes; adjust the scheduling weights corresponding to each of the server nodes based on the device operation status of each of the server nodes; determine the target server node from the node pool, wherein the target server node is a server node for processing the request; and schedule the request to each of the target server nodes in proportion to the scheduling weights of the target server nodes.

[0114] It can be seen that when the embodiment of the present application performs a server node check, it checks the device operating status of the server node and adjusts the scheduling weight of the server node based on the device operating status, so that the request is scheduled to the target server node in proportion to the scheduling weight. Since the scheduling weight is adjusted based on the device operating status, it can ensure that the request is reasonably scheduled to the target server node in proportion. In this way, server resources can be reasonably utilized and system performance can be improved.

[0115] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: after receiving the device operation status returned by each of the server nodes, the device operation status of any of the server nodes is compared with the preset threshold value; if the device operation status exceeds the preset threshold value, the node status of any of the server nodes is marked as busy; accordingly, when the preset busy state scheduling strategy is to allow scheduling, the server nodes with busy state and normal server nodes in the node pool are determined as target server nodes, and the normal server nodes are server nodes in non-busy state and have received the device operation status; when the preset busy state scheduling strategy is scheduling failure, the normal server nodes in the node pool are determined as target server nodes. The allowed scheduling includes forced scheduling and queuing, wherein the forced scheduling is to schedule the server nodes in the busy state as normal server nodes, and the queuing is to place the requests scheduled to the server nodes in the busy state into the queue corresponding to the server nodes in the busy state, and wait for the server nodes in the busy state to change to normal server nodes to process the requests in the queue.

[0116] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: the device operation status includes multiple state information, and weighted calculation is performed based on the multiple state information of each server node itself to obtain the weight adjustment value corresponding to each server node itself; based on the weight adjustment value and the current scheduling weight, the adjusted scheduling weight is determined to obtain the scheduling weight corresponding to each server node. The device operation status includes the usage of one or more of the CPU, memory, and disk.

[0117] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: encapsulating a status check request based on the SNMP protocol; and sending the status check request to each server node in the node pool.

[0118] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0119] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0120] The above is a detailed introduction to a request scheduling method, device, product, equipment and medium provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A request scheduling method, characterized in that: include: Send status check requests to each server node in the node pool; Receiving the device operation status returned by each of the server nodes; Adjusting the scheduling weights corresponding to the server nodes based on the device operation status of the server nodes themselves; Determining a target server node from the node pool, wherein the target server node is a server node for processing the request; The request is dispatched to each of the target server nodes according to the ratio of the dispatch weight of each of the target server nodes.

2. The request scheduling method according to claim 1, characterized in that: After receiving the device operation status returned by each of the server nodes, the method further includes: Comparing the device operation status of any of the server nodes with a preset threshold; If the device operation state exceeds the preset threshold, marking the node state of any server node as a busy state; Correspondingly, determining the target server node from the node pool includes: When the preset busy state scheduling policy is to allow scheduling, the server nodes whose node states are busy and the normal server nodes in the node pool are determined as target server nodes, and the normal server nodes are server nodes in non-busy states and receiving the device operation status; When the preset busy state scheduling strategy is scheduling failure, the normal server node in the node pool is determined as the target server node.

3. The request scheduling method according to claim 2, characterized in that: The allowed scheduling includes forced scheduling and queuing, wherein the forced scheduling is to schedule the server node in the busy state as a normal server node, and the queuing is to place the request scheduled to the server node in the busy state into the queue corresponding to the server node in the busy state, and wait for the server node in the busy state to change to a normal server node to process the request in the queue.

4. The request scheduling method according to claim 1, characterized in that: The device operation status includes multiple pieces of status information, and the adjusting the scheduling weights corresponding to the server nodes based on the device operation status of the server nodes themselves includes: Performing weighted calculation based on the multiple pieces of status information of each of the server nodes to obtain a weight adjustment value corresponding to each of the server nodes; The adjusted scheduling weight is determined based on the weight adjustment value and the current scheduling weight, and the scheduling weights corresponding to each of the server nodes are obtained.

5. The request scheduling method according to claim 1, characterized in that: The device operation status includes the usage of one or more of the CPU, memory, and disk.

6. The request scheduling method according to any one of claims 1 to 5, characterized in that: The sending of a status check request to each server node in the node pool includes: Encapsulate status check request based on SNMP protocol; The status check request is sent to each server node in the node pool.

7. A request scheduling device, characterized in that: include: A request sending module is used to send status check requests to each server node in the node pool; A status receiving module, used for receiving the device operation status returned by each of the server nodes; A weight adjustment module, used for adjusting the scheduling weights corresponding to each of the server nodes based on the device operation status of each of the server nodes; A node determination module, used to determine a target server node from the node pool, wherein the target server node is a server node used to process the request; The request scheduling module is used to schedule the request to each of the target server nodes according to the proportion of the scheduling weight of each of the target server nodes.

8. A computer program product, characterized in that The method comprises a computer program / instruction, which, when executed by a processor, implements the request scheduling method as claimed in any one of claims 1 to 6.

9. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store the computer program; The processor is used to execute the computer program to implement the request scheduling method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the request scheduling method according to any one of claims 1 to 6 is implemented.

Images