CN110636388A - Service request distribution method, system, electronic equipment and storage medium - Google Patents
Service request distribution method, system, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN110636388A CN110636388A CN201910931291.9A CN201910931291A CN110636388A CN 110636388 A CN110636388 A CN 110636388A CN 201910931291 A CN201910931291 A CN 201910931291A CN 110636388 A CN110636388 A CN 110636388A
- Authority
- CN
- China
- Prior art keywords
- slave node
- performance data
- service request
- performance
- time period
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
- H04N21/6473—Monitoring network processes errors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
- H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
- H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a service request distribution method, which comprises the steps of obtaining historical performance data of all slave nodes; determining the performance change trend of each slave node according to the historical performance data, and determining the expected performance data of each slave node in a target time period according to the performance change trend; wherein the target time period is a time period after the current time; and setting the priority of each slave node according to the expected performance data, and distributing the service requests received in the target time period according to the priority. The method and the device can distribute the service request on the premise of keeping load balance, and improve cluster reliability. The application also discloses a service request distribution system, an electronic device and a storage medium, which have the beneficial effects.
Description
Technical Field
The present application relates to the field of server technologies, and in particular, to a method and a system for allocating service requests, an electronic device, and a storage medium.
Background
The load balancing means that the load is balanced and distributed to a plurality of operation units for operation. For example, data processing tasks needing to be processed within a period of time can be distributed to FTP servers, Web servers, enterprise core application servers and other main task servers, and the like, so that the work tasks are completed cooperatively.
Load balancing is one of effective means for improving system reliability, and after a certain node in a related technology cluster fails or when the load of the certain node is too high, the load balancing is triggered, and the priority of each server for receiving requests is determined according to the load state of each server, so that the load difference among different servers is reduced. However, the load balancing scheme in the related art has hysteresis and low cluster reliability.
Therefore, how to distribute service requests and improve cluster reliability on the premise of keeping load balance is a technical problem that needs to be solved by those skilled in the art at present.
Disclosure of Invention
The application aims to provide a service request distribution method, a service request distribution system, an electronic device and a storage medium, which can distribute service requests on the premise of keeping load balance and improve cluster reliability.
In order to solve the above technical problem, the present application provides a service request allocation method, where the service request allocation method includes:
acquiring historical performance data of all slave nodes;
determining the performance change trend of each slave node according to the historical performance data, and determining the expected performance data of each slave node in a target time period according to the performance change trend; wherein the target time period is a time period after the current time;
and setting the priority of each slave node according to the expected performance data, and distributing the service requests received in the target time period according to the priority.
Optionally, the setting the priority of each slave node according to the expected performance data includes:
determining an expected load of each said slave node for said target time period based on said expected performance data;
determining a priority for each of the slave nodes based on the expected load; wherein the expected load magnitude is inversely related to the priority level.
Optionally, allocating the service request received by the target time segment according to the priority includes:
updating a service request distribution probability table according to the priority corresponding to each slave node; the service request distribution probability table comprises request distribution probabilities corresponding to each slave node, and the sum of the request distribution probabilities corresponding to all the slave nodes is 1;
and distributing the service request received by the target time period to the corresponding slave node according to the distribution probability table.
Optionally, the method further includes:
when node fault information is received, setting the request distribution probability of a slave node corresponding to the node fault information to be zero, and updating the request distribution probability table.
Optionally, the historical performance data includes any one or a combination of bandwidth, IOPS, CPU utilization, and memory utilization.
Optionally, the determining the performance trend of each slave node according to the historical performance data includes:
determining a performance evaluation value of the historical performance data acquired in each period according to a weight value corresponding to each type of performance parameter in the historical performance data;
and determining the performance change trend of each slave node according to all the performance evaluation values.
Optionally, determining the performance variation trend of each slave node according to all the performance evaluation values includes:
determining the time weight of each performance evaluation value corresponding period; the earlier the cycle corresponding to the performance evaluation value is from the current moment, the smaller the time weight is;
and determining the performance change trend of each slave node according to all the performance evaluation values and the time weight.
The present application also provides a service request distribution system, which includes:
the historical data acquisition module is used for acquiring historical performance data of all slave nodes;
the expectation module is used for determining the performance change trend of each slave node according to the historical performance data and determining the expected performance data of each slave node in a target time period according to the performance change trend; wherein the target time period is a time period after the current time;
and the request distribution module is used for setting the priority of each slave node according to the expected performance data and distributing the service request received in the target time period according to the priority.
The application also provides a storage medium, on which a computer program is stored, and the computer program realizes the steps executed by the service request distribution method when executed.
The application also provides an electronic device, which comprises a memory and a processor, wherein the memory stores a computer program, and the processor realizes the steps executed by the service request allocation method when calling the computer program in the memory.
The application provides a service request distribution method, which comprises the steps of obtaining historical performance data of all slave nodes; determining the performance change trend of each slave node according to the historical performance data, and determining the expected performance data of each slave node in a target time period according to the performance change trend; wherein the target time period is a time period after the current time; and setting the priority of each slave node according to the expected performance data, and distributing the service requests received in the target time period according to the priority.
According to the method, historical performance data of each slave node is obtained, and the performance change trend of each new node is determined according to the historical performance data. The historical load conditions of the slave nodes can be known according to the historical performance data of the slave nodes, so the expected load conditions of the target time period can be determined according to the expected performance data determined by the performance change trend. The priority of each slave node is set based on the expected performance data, the service data received in the target time period is distributed according to the priority, and load balance of each slave node in the cluster is achieved. The method and the device can distribute the service request on the premise of keeping load balance, and improve cluster reliability. The application also provides a service request distribution system, a storage medium and an electronic device, which have the beneficial effects and are not described herein again.
Drawings
In order to more clearly illustrate the embodiments of the present application, the drawings needed for the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained by those skilled in the art without inventive effort.
Fig. 1 is a flowchart of a service request allocation method according to an embodiment of the present application;
fig. 2 is a flowchart of another service request allocation method provided in the embodiment of the present application;
fig. 3 is a schematic structural diagram of a service request distribution system according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Referring to fig. 1, fig. 1 is a flowchart of a service request distribution method according to an embodiment of the present application.
The specific steps may include:
s101: acquiring historical performance data of all slave nodes;
the execution main body of this embodiment may be a master node of a cluster, the cluster may include a plurality of slave nodes, and the master node allocates a service request to each slave node, so that the slave node executes a service processing operation corresponding to the service request. The preset period of obtaining the historical performance data of the master node may be preset, so that the master node obtains the key performance index of each slave node at preset time intervals to obtain the historical performance data.
The historical performance data may include any one or a combination of bandwidth, IOPS (Input/Output Operations Per Second), CPU utilization, and memory utilization. As a possible implementation, the historical performance data may also include any one or a combination of bandwidth utilization, IOPS utilization, CPU utilization, and memory utilization. The bandwidth utilization rate refers to the ratio of the used bandwidth to the maximum bandwidth, and the IOPS utilization rate refers to the ratio of the actual read-write operation times per second to the maximum read-write operation times per second.
As a possible implementation manner, the present embodiment may acquire historical performance data corresponding to a specific historical time period, and may record the generation time of the historical performance data after acquiring the historical performance data.
S102: determining the performance change trend of each slave node according to the historical performance data, and determining the expected performance data of each slave node in a target time period according to the performance change trend;
after the historical performance data is obtained, the performance change trend of each slave node can be determined according to the corresponding relation between each performance index and the generation time in the historical performance data, and the expected performance data of the slave node in the future time period can be determined according to the performance change trend.
For example, the current time is 12:00, 11:55 is the time point of last obtaining of the historical performance data, the historical performance data of the node a at 11:55 is 60% of the CPU utilization rate and 50% of the memory utilization rate, and if the performance change trend of the node a is determined to be flat according to 10:55 to 11:55, the expected performance data of 12:00-12:05 is 60% of the CPU utilization rate and 50% of the memory utilization rate; if the performance change trend of the node A is determined to be linearly increased according to the ratio of 10: 55-11: 55, the expected performance data of 12:00-12:05 can be the CPU utilization rate of 66% and the memory utilization rate of 55%; if the performance change trend of the node A is determined to be linear rising according to the ratio of 10: 55-11: 55, the expected performance data of 12:00-12:05 can be the CPU utilization rate of 66% and the memory utilization rate of 55%; if the performance change trend of the node A is determined to be linear reduction according to the ratio of 10: 55-11: 55, the expected performance data of 12:00-12:05 can be 54% of CPU utilization rate and 45% of memory utilization rate; if the performance change trend of the node A is determined to be the exponential rise according to the ratio of 10: 55-11: 55, the expected performance data of 12:00-12:05 can be the CPU utilization rate of 95% and the memory utilization rate of 90%; if the performance change trend of the node A is determined to be exponentially reduced according to the ratio of 10:55 to 11:55, the expected performance data of 12:00 to 12:05 can be 15% of the CPU utilization rate and 10% of the memory utilization rate.
As a feasible implementation manner, the time difference between the ending time of the time period corresponding to the historical performance data acquired in S101 and the current time may be within a preset range, so as to improve the accuracy of obtaining the expected performance data according to the historical performance data.
S103: and setting the priority of each slave node according to the expected performance data, and distributing the service requests received in the target time period according to the priority.
The present embodiment establishes that, on the basis of having obtained the expected performance data of the slave node in the target time period, the priority of each slave node may be set according to the level of the performance data. Specifically, the expected performance data may include a plurality of performance indexes such as a bandwidth utilization rate, an IOPS utilization rate, a CPU utilization rate, and a memory utilization rate, the expected performance score of each slave node may be obtained by combining a weight coefficient corresponding to each performance index, and the priority of each slave node is set in the order of the scores from high to low. And distributing the service request received by the cluster at the near segment according to the priority. Specifically, the expected performance data represents the used performance of each slave node in the target time period, the higher the used performance is, the lower the priority is, the higher the probability that the slave node with the higher priority receives the service request is when the service request is distributed, so that the slave nodes with the lower used performance in the target time period receive more service requests, and further, the load balance of each slave node in the cluster is realized.
As a further introduction to the above embodiment, a specific process of setting the priority of each slave node in S103 may include the steps of:
step 1: determining an expected load of each said slave node for said target time period based on said expected performance data;
step 2: determining a priority for each of the slave nodes based on the expected load;
the above manner may calculate the expected load of the slave node in the target time period according to the bandwidth utilization, the IOPS utilization, the CPU utilization, and the memory utilization in the expected performance data. The priority mentioned above is the priority of allocating the service request, and the higher the expected load, the lower the priority, and the lower the expected load, the higher the priority. That is, the priority setting manner can make the probability of receiving the service request from the node with smaller expected load higher than the probability of receiving the service request from the node with larger expected load, thereby balancing the load of the nodes in the cluster.
The embodiment first obtains the historical performance data of each slave node, and determines the performance change trend of each new node according to the historical performance data. The historical load conditions of the slave nodes can be known according to the historical performance data of the slave nodes, so the expected load conditions of the target time period can be determined according to the expected performance data determined by the performance change trend. In this embodiment, the priority of each slave node is set based on the expected performance data, and the service data received in the target time period is allocated according to the priority, so as to achieve load balancing of each slave node in the cluster. The embodiment can distribute the service request on the premise of keeping load balance, and improves the cluster reliability.
As a further addition to the corresponding embodiment of fig. 1, the performance trend of the slave node may be determined by: firstly, determining a performance evaluation value of the historical performance data acquired in each period according to a weight value corresponding to each type of performance parameter in the historical performance data; and determining the performance change trend of each slave node according to all the performance evaluation values. Specifically, the determining the performance variation trend of each slave node according to all the performance evaluation values may include the following steps:
step 1: determining the time weight of each performance evaluation value corresponding period; the earlier the cycle corresponding to the performance evaluation value is from the current moment, the smaller the time weight is;
step 2: and determining the performance change trend of each slave node according to all the performance evaluation values and the time weight.
The embodiment introduces the time weight, so that the performance evaluation value closer to the current moment has higher weight, and the accuracy of the performance change trend is improved.
Referring to fig. 2, fig. 2 is a flowchart of another service request allocation method provided in the embodiment of the present application; this embodiment is a specific description of allocating service requests according to priorities in the embodiment corresponding to fig. 1, and a more preferred implementation may be obtained by combining the embodiment and the embodiment corresponding to fig. 1, where the embodiment may include the following steps:
s201: updating a service request distribution probability table according to the priority corresponding to each slave node;
the service request distribution probability table comprises request distribution probabilities corresponding to each slave node, and the sum of the request distribution probabilities corresponding to all the slave nodes is 1;
s202: and distributing the service request received by the target time period to the corresponding slave node according to the distribution probability table.
In the above embodiment, the corresponding request distribution probability is set for the priority of each level, and the service request distribution probability table is updated according to the distribution probability corresponding to each node. After receiving the service request in the target time period, the target slave node which needs to distribute the service request can be selected according to the distribution probability table. In this embodiment, there may be an operation of randomly selecting a target slave node, and the random selection operation may be performed according to the request distribution probability recorded in the distribution probability table.
As a further supplement to the above embodiment, when the master node receives the node failure information, the request allocation probability of the slave node corresponding to the node failure information may be set to zero, and the request allocation probability table may be updated.
The flow described in the above embodiment is explained below by an embodiment in practical use.
The embodiment may be applied to a server cluster including a plurality of nodes, where a performance prediction engine may be deployed on a master node of the server cluster, and the performance prediction engine may be configured to collect and store historical performance data (such as bandwidth, IOPS, CPU utilization, memory utilization, and the like) of key performance indexes of each slave node. The prediction engine may predict performance data for a future time period at regular intervals T based on historical performance data. The service priority of the slave nodes is set according to the performance predicted by each slave node, and the lower the predicted performance, the higher the priority of the slave node. When the service request is received by the master node, the node for processing the request can be determined according to the priority level of each slave node, and the service request is forwarded.
In the process of predicting the performance of the slave nodes, the master node may collect historical performance data of each slave node according to a certain frequency, and the master node may perform performance prediction at a fixed time interval T by using the prediction to obtain expected performance data of each slave node. The master node can calculate the expected load state of each slave node according to the performance index weight and the performance data of the master node. The master node may assign a probability of the request of the slave node as a priority, and the lower the load of the slave node, the higher the service priority of the slave node, the higher the selection probability of the slave node.
When the master node receives the service request, a slave node can be randomly selected as a service node (namely a target slave node) according to the selection probability of the slave node; wherein, the probability of the slave node being selected is higher as the request distribution probability is higher. After determining the serving node, the master node forwards the service request to the selected serving node.
The embodiment evaluates the load state of each slave node in a future period of time by predicting the performance of each slave node in the cluster so as to determine the low-load node. When a new service request accesses, the node with low load has higher probability to receive the service request, and the node with high load has lower probability to receive the service request, thereby realizing load balance. The embodiment does not rely on the current system state to evaluate the load of each node, but has the prospective function of balancing the load of future requests according to the possible pressure of the future system, thereby greatly improving the reliability of the system.
Referring to fig. 3, fig. 3 is a schematic structural diagram of a service request distribution system according to an embodiment of the present application;
the system may include:
a historical data obtaining module 100, configured to obtain historical performance data of all slave nodes;
an expectation module 200, configured to determine a performance variation trend of each slave node according to the historical performance data, and determine expected performance data of each slave node in a target time period according to the performance variation trend; wherein the target time period is a time period after the current time;
a request allocating module 300, configured to set a priority of each slave node according to the expected performance data, and allocate a service request received in the target time period according to the priority.
The embodiment first obtains the historical performance data of each slave node, and determines the performance change trend of each new node according to the historical performance data. The historical load conditions of the slave nodes can be known according to the historical performance data of the slave nodes, so the expected load conditions of the target time period can be determined according to the expected performance data determined by the performance change trend. In this embodiment, the priority of each slave node is set based on the expected performance data, and the service data received in the target time period is allocated according to the priority, so as to achieve load balancing of each slave node in the cluster. The embodiment can distribute the service request on the premise of keeping load balance, and improves the cluster reliability.
Further, the request distribution module 300 includes:
an expected load determining unit, configured to determine, according to the expected performance data, an expected load of each slave node in the target time period;
the priority setting unit is used for determining the priority of each slave node according to the expected load; wherein the expected load magnitude is inversely related to the priority level.
An allocation unit, configured to allocate the service request received in the target time slot according to the priority
Further, the request distribution module 300 includes:
a node setting unit, configured to set a priority of each slave node according to the expected performance data;
the probability setting unit is used for updating a service request distribution probability table according to the priority corresponding to each slave node; the service request distribution probability table comprises request distribution probabilities corresponding to each slave node, and the sum of the request distribution probabilities corresponding to all the slave nodes is 1;
and the service request distribution unit is used for distributing the service requests received by the target time period to corresponding slave nodes according to the distribution probability table.
Further, the method also comprises the following steps:
and the probability table updating unit is used for setting the request distribution probability of the slave node corresponding to the node fault information to be zero and updating the request distribution probability table when the node fault information is received.
Further, the historical performance data includes any one or a combination of bandwidth, IOPS, CPU utilization, and memory utilization.
Further, it is contemplated that module 200 includes:
the performance evaluation value determining unit is used for determining the performance evaluation value of the historical performance data acquired in each period according to the weight value corresponding to each type of performance parameter in the historical performance data;
a trend determining unit, configured to determine a performance variation trend of each slave node according to all the performance evaluation values;
and the expected performance data determining unit is used for determining the expected performance data of each slave node in a target time period according to the performance change trend.
Further, the trend determining unit includes:
a time weight determining subunit, configured to determine a time weight of a period corresponding to each of the performance evaluation values; the earlier the cycle corresponding to the performance evaluation value is from the current moment, the smaller the time weight is;
and the performance change trend determining subunit is used for determining the performance change trend of each slave node according to all the performance evaluation values and the time weights.
Since the embodiment of the system part corresponds to the embodiment of the method part, the embodiment of the system part is described with reference to the embodiment of the method part, and is not repeated here.
The present application also provides a storage medium having a computer program stored thereon, which when executed, may implement the steps provided by the above-described embodiments. The storage medium may include: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The application further provides an electronic device, which may include a memory and a processor, where the memory stores a computer program, and the processor may implement the steps provided by the foregoing embodiments when calling the computer program in the memory. Of course, the electronic device may also include various network interfaces, power supplies, and the like.
The embodiments are described in a progressive manner in the specification, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. For the system disclosed by the embodiment, the description is relatively simple because the system corresponds to the method disclosed by the embodiment, and the relevant points can be referred to the method part for description. It should be noted that, for those skilled in the art, it is possible to make several improvements and modifications to the present application without departing from the principle of the present application, and such improvements and modifications also fall within the scope of the claims of the present application.
It is further noted that, in the present specification, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
Claims (10)
1. A service request distribution method is characterized by comprising the following steps:
acquiring historical performance data of all slave nodes;
determining the performance change trend of each slave node according to the historical performance data, and determining the expected performance data of each slave node in a target time period according to the performance change trend; wherein the target time period is a time period after the current time;
and setting the priority of each slave node according to the expected performance data, and distributing the service requests received in the target time period according to the priority.
2. The method of claim 1, wherein setting the priority of each slave node according to the expected performance data comprises:
determining an expected load of each said slave node for said target time period based on said expected performance data;
determining a priority for each of the slave nodes based on the expected load; wherein the expected load magnitude is inversely related to the priority level.
3. The method of claim 1, wherein allocating the service requests received in the target time period according to the priority comprises:
updating a service request distribution probability table according to the priority corresponding to each slave node; the service request distribution probability table comprises request distribution probabilities corresponding to each slave node, and the sum of the request distribution probabilities corresponding to all the slave nodes is 1;
and distributing the service request received by the target time period to the corresponding slave node according to the distribution probability table.
4. The service request distribution method according to claim 3, further comprising:
when node fault information is received, setting the request distribution probability of a slave node corresponding to the node fault information to be zero, and updating the request distribution probability table.
5. The service request distribution method according to claim 1, wherein the historical performance data comprises any one or a combination of any of bandwidth, IOPS, CPU utilization, and memory utilization.
6. The service request distribution method according to any of claims 1 to 5, wherein determining a performance trend of each slave node according to the historical performance data comprises:
determining a performance evaluation value of the historical performance data acquired in each period according to a weight value corresponding to each type of performance parameter in the historical performance data;
and determining the performance change trend of each slave node according to all the performance evaluation values.
7. The method according to claim 6, wherein determining the performance trend of each slave node according to all the performance evaluation values comprises:
determining the time weight of each performance evaluation value corresponding period; the earlier the cycle corresponding to the performance evaluation value is from the current moment, the smaller the time weight is;
and determining the performance change trend of each slave node according to all the performance evaluation values and the time weight.
8. A service request distribution system, comprising:
the historical data acquisition module is used for acquiring historical performance data of all slave nodes;
the expectation module is used for determining the performance change trend of each slave node according to the historical performance data and determining the expected performance data of each slave node in a target time period according to the performance change trend; wherein the target time period is a time period after the current time;
and the request distribution module is used for setting the priority of each slave node according to the expected performance data and distributing the service request received in the target time period according to the priority.
9. An electronic device, comprising a memory in which a computer program is stored and a processor which, when invoked by the computer program in the memory, carries out the steps of the service request distribution method according to any of claims 1 to 7.
10. A storage medium having stored thereon computer-executable instructions which, when loaded and executed by a processor, carry out the steps of a service request distribution method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910931291.9A CN110636388A (en) | 2019-09-29 | 2019-09-29 | Service request distribution method, system, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910931291.9A CN110636388A (en) | 2019-09-29 | 2019-09-29 | Service request distribution method, system, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110636388A true CN110636388A (en) | 2019-12-31 |
Family
ID=68973359
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910931291.9A Pending CN110636388A (en) | 2019-09-29 | 2019-09-29 | Service request distribution method, system, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110636388A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113435754A (en) * | 2021-06-30 | 2021-09-24 | 平安普惠企业管理有限公司 | Service distribution method, device, terminal equipment and medium |
| CN113553186A (en) * | 2021-07-29 | 2021-10-26 | 深信服科技股份有限公司 | Load balancing method, system, storage medium and electronic equipment |
| WO2022021858A1 (en) * | 2020-07-29 | 2022-02-03 | 苏州浪潮智能科技有限公司 | Method and system for achieving high service availability in high-load scene in distributed system |
| CN114584605A (en) * | 2022-03-21 | 2022-06-03 | 平安壹钱包电子商务有限公司 | Service distribution method, device, electronic equipment and storage medium |
| CN117217920A (en) * | 2023-11-08 | 2023-12-12 | 深圳海辰储能科技有限公司 | Energy storage transaction data processing method, device and storage medium |
| CN117237004A (en) * | 2023-11-10 | 2023-12-15 | 深圳海辰储能科技有限公司 | Energy storage device transaction processing method and device and storage medium |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101945407A (en) * | 2010-10-22 | 2011-01-12 | 东南大学 | Load balancing method for content monitoring of mobile service |
| CN102624922A (en) * | 2012-04-11 | 2012-08-01 | 武汉大学 | Method for balancing load of network GIS heterogeneous cluster server |
| CN103368864A (en) * | 2013-07-31 | 2013-10-23 | 北京华易互动科技有限公司 | Intelligent load balancing method based on c/s (Client/Server) architecture |
| US20160011617A1 (en) * | 2014-07-11 | 2016-01-14 | Microsoft Technology Licensing, Llc | Power management of server installations |
| CN107395708A (en) * | 2017-07-14 | 2017-11-24 | 郑州云海信息技术有限公司 | A kind of method and apparatus for handling download request |
| CN109918198A (en) * | 2019-02-18 | 2019-06-21 | 中国空间技术研究院 | A kind of emulation cloud platform load dispatch system and method based on user characteristics prediction |
| CN110035122A (en) * | 2019-04-04 | 2019-07-19 | 科讯嘉联信息技术有限公司 | A kind of load-balancing method based on dynamic probability model, device and system |
| CN110278102A (en) * | 2018-03-15 | 2019-09-24 | 勤智数码科技股份有限公司 | A kind of IT automation operational system and method |
-
2019
- 2019-09-29 CN CN201910931291.9A patent/CN110636388A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101945407A (en) * | 2010-10-22 | 2011-01-12 | 东南大学 | Load balancing method for content monitoring of mobile service |
| CN102624922A (en) * | 2012-04-11 | 2012-08-01 | 武汉大学 | Method for balancing load of network GIS heterogeneous cluster server |
| CN103368864A (en) * | 2013-07-31 | 2013-10-23 | 北京华易互动科技有限公司 | Intelligent load balancing method based on c/s (Client/Server) architecture |
| US20160011617A1 (en) * | 2014-07-11 | 2016-01-14 | Microsoft Technology Licensing, Llc | Power management of server installations |
| CN107395708A (en) * | 2017-07-14 | 2017-11-24 | 郑州云海信息技术有限公司 | A kind of method and apparatus for handling download request |
| CN110278102A (en) * | 2018-03-15 | 2019-09-24 | 勤智数码科技股份有限公司 | A kind of IT automation operational system and method |
| CN109918198A (en) * | 2019-02-18 | 2019-06-21 | 中国空间技术研究院 | A kind of emulation cloud platform load dispatch system and method based on user characteristics prediction |
| CN110035122A (en) * | 2019-04-04 | 2019-07-19 | 科讯嘉联信息技术有限公司 | A kind of load-balancing method based on dynamic probability model, device and system |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2022021858A1 (en) * | 2020-07-29 | 2022-02-03 | 苏州浪潮智能科技有限公司 | Method and system for achieving high service availability in high-load scene in distributed system |
| US11736562B1 (en) | 2020-07-29 | 2023-08-22 | Inspur Suzhou Intelligent Technology Co., Ltd. | Method and system for achieving high availability of service under high-load scene in distributed system |
| CN113435754A (en) * | 2021-06-30 | 2021-09-24 | 平安普惠企业管理有限公司 | Service distribution method, device, terminal equipment and medium |
| CN113553186A (en) * | 2021-07-29 | 2021-10-26 | 深信服科技股份有限公司 | Load balancing method, system, storage medium and electronic equipment |
| CN114584605A (en) * | 2022-03-21 | 2022-06-03 | 平安壹钱包电子商务有限公司 | Service distribution method, device, electronic equipment and storage medium |
| CN114584605B (en) * | 2022-03-21 | 2024-04-05 | 平安壹钱包电子商务有限公司 | Service distribution method and device, electronic equipment and storage medium |
| CN117217920A (en) * | 2023-11-08 | 2023-12-12 | 深圳海辰储能科技有限公司 | Energy storage transaction data processing method, device and storage medium |
| CN117217920B (en) * | 2023-11-08 | 2024-01-30 | 深圳海辰储能科技有限公司 | Energy storage transaction data processing method, device and storage medium |
| CN117237004A (en) * | 2023-11-10 | 2023-12-15 | 深圳海辰储能科技有限公司 | Energy storage device transaction processing method and device and storage medium |
| CN117237004B (en) * | 2023-11-10 | 2024-03-05 | 深圳海辰储能科技有限公司 | Energy storage device transaction processing method and device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110636388A (en) | Service request distribution method, system, electronic equipment and storage medium | |
| US7631034B1 (en) | Optimizing node selection when handling client requests for a distributed file system (DFS) based on a dynamically determined performance index | |
| US9405588B2 (en) | Cloud resource allocation system and method | |
| US11496413B2 (en) | Allocating cloud computing resources in a cloud computing environment based on user predictability | |
| KR101865318B1 (en) | Burst mode control | |
| CN106959894B (en) | Resource allocation method and device | |
| CN106453146B (en) | Method, system, device and readable storage medium for allocating private cloud computing resources | |
| CN106407190A (en) | Event record querying method and device | |
| CN108154298B (en) | Distribution task allocation method and device, electronic equipment and computer storage medium | |
| CN110740164B (en) | Server determination method, regulation and control method, device, equipment and storage medium | |
| CN109032800A (en) | A kind of load equilibration scheduling method, load balancer, server and system | |
| CN111737168A (en) | Cache system, cache processing method, device, equipment and medium | |
| CN112181664A (en) | Load balancing method and device, computer readable storage medium and electronic equipment | |
| CN108241535B (en) | Resource management method and device and server equipment | |
| JP7192645B2 (en) | Information processing device, distributed processing system and distributed processing program | |
| CN110096352A (en) | Process management method, device and computer readable storage medium | |
| CN116302477A (en) | Dynamic allocation method and system of performance resources and related components | |
| CN102200928A (en) | Computation resource control apparatus, computation resource control method, and non-transitory computer-readable recording medium | |
| JP2009252050A (en) | System, method and program for server load management | |
| CN111967938A (en) | Cloud resource recommendation method and device, computer equipment and readable storage medium | |
| CN108572871B (en) | Resource allocation method and device, electronic equipment and storage medium | |
| CN112910988A (en) | Resource acquisition method and resource scheduling device | |
| CN117076157B (en) | Request management method, request management device, computer readable storage medium and computer equipment | |
| CN117170881B (en) | Resource regulation method and device, storage medium and processor | |
| CN113849457B (en) | Multi-data center dynamic copy placement method based on neural network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191231 |