CN117271126A

CN117271126A - Task request distribution method and device and electronic equipment

Info

Publication number: CN117271126A
Application number: CN202311237214.6A
Authority: CN
Inventors: 梁梓锋
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2023-09-22
Filing date: 2023-09-22
Publication date: 2023-12-22

Abstract

The embodiment of the application provides a task request distribution method, a task request distribution device and electronic equipment, wherein the method comprises the following steps: acquiring a plurality of pieces of load information corresponding to each server in the task processing cluster at intervals of a preset time period, and determining the current load capacity of each server according to the plurality of pieces of load information; determining the processing capacity value of each server according to the multiple performance index data; selecting a reference server at intervals of a preset time period, and estimating the load increment of the reference server according to the current load capacity and the current connection number of the reference server; each time a server receives or processes a task request, updating the current load according to the processing capacity value of the reference server, the processing capacity value of the server and the load increment of the reference server which is obtained recently; and if the task request is received within the current preset time period, distributing the task request to the target server according to the current load quantity. The embodiment of the application can realize load balancing and improve the processing efficiency of the task request.

Description

Task request distribution method and device and electronic equipment

Technical Field

The present invention relates to the field of load balancing technologies, and in particular, to a task request allocation method and apparatus, and an electronic device.

Background

At present, the task request is distributed and scheduled through a load balancing scheduling module in the prior art, and the task request is distributed to a certain node or server for processing according to a load balancing rule.

However, the existing load balancing scheduling module obtains the load condition of the server at one time, and then distributes task requests uniformly according to the obtained load condition of the server at the next time; however, after the system operates for a period of time, the load balancing scheduling module does not interact with the server any more, so that a certain deviation is generated between the actual load condition of the server and the load condition of the server based on which the task request is distributed, further the task request is distributed unreasonably, and finally the problem of unbalanced load is caused.

Disclosure of Invention

The embodiment of the application provides a task request distribution method, a task request distribution device and electronic equipment, so that load balancing can be realized at least to a certain extent, and the task request processing efficiency is improved.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned in part by the practice of the application.

According to an aspect of the embodiments of the present application, there is provided a task request allocation method, including: acquiring a plurality of pieces of load information corresponding to each server in a task processing cluster at intervals of a preset time period, and determining the current load capacity of each server according to the plurality of pieces of load information corresponding to each server, wherein the current load capacity is used for measuring the current overall load of the server; determining a processing capacity value of each server in the task processing cluster according to multiple performance index data of the server; selecting a reference server from the servers of the task processing cluster at intervals of a preset time period, and estimating the load increment of the reference server according to the current load capacity and the current connection number of the reference server, wherein the load increment is the load capacity increased after the reference server receives an allocated task request; each time a server receives or processes a task request in a current preset time period, updating the current load capacity of the server according to the processing capacity value of the reference server, the processing capacity value of the server and the load increment of the reference server obtained when the last preset time period is finished; and if a task request is received in the current preset time period, distributing the task request to a target server for processing according to the current load capacity of each server in the task processing cluster.

According to an aspect of the embodiments of the present application, there is provided a task request distributing device, including: the acquisition unit is used for acquiring a plurality of items of load information corresponding to each server in the task processing cluster at intervals of a preset time period, and determining the current load capacity of each server according to the plurality of items of load information corresponding to each server, wherein the current load capacity is used for measuring the current overall load of the server; the determining unit is used for determining the processing capacity value of each server in the task processing cluster according to the multiple performance index data of the server; the estimating unit is used for selecting a reference server from the servers of the task processing cluster at intervals of a preset time period, and estimating the load increment of the reference server according to the current load capacity and the current connection number of the reference server, wherein the load increment is the load capacity increased after the reference server receives an allocated task request; the updating unit is used for updating the current load capacity of the server according to the processing capacity value of the reference server, the processing capacity value of the server and the load increment of the reference server obtained when the last preset time period is finished every time the server receives or processes a task request in the current preset time period; and the distribution unit is used for distributing the task request to the target server for processing according to the current load of each server in the task processing cluster if one task request is received in the current preset time period.

In some embodiments of the present application, based on the foregoing, the plurality of load information includes at least two of: CPU occupancy rate, disk read-write occupancy rate, memory occupancy rate, network bandwidth occupancy rate and request process occupancy rate; the acquisition unit is configured to: acquiring weights corresponding to various load information; and aiming at each server, determining the weighted sum of the load information corresponding to the server according to the weight corresponding to the load information, and taking the weighted sum as the current load of the server.

In some embodiments of the present application, based on the foregoing approach, the plurality of performance index data includes at least two of: CPU main frequency, memory capacity, disk read-write speed, network throughput and maximum connection number; the determination unit is configured to: acquiring weights corresponding to the performance index data; and aiming at each server in the task processing cluster, determining the weighted sum of all the performance index data of the server according to the weight corresponding to all the performance index data, and taking the weighted sum as the processing capacity value of the server.

In some embodiments of the present application, based on the foregoing scheme, the allocation unit is configured to: selecting at least one candidate server from the servers of the task processing cluster and adding the candidate server into a candidate server set, wherein the current load capacity of the candidate server is smaller than the current load capacity of other servers in the task processing cluster; determining task request allocation probability of each candidate server according to the processing capacity value of each candidate server in the candidate server set; and distributing the task requests to the target servers for processing according to the task request distribution probability of each candidate server.

In some embodiments of the present application, based on the foregoing solution, the task request is used to import a log of query statements into a server of the task processing cluster, where the log of query statements is collected by a requester of the task request from a gateway of a database, where the database receives, through the gateway, a query request containing the query statements.

In some embodiments of the present application, based on the foregoing solution, the log of the query statement is generated by the requestor of the task request by: collecting an original log from a gateway of a database; performing format conversion on query sentences in an original log to obtain abstract query sentences, wherein the abstract query sentences are used for referring to a class of query sentences including the query sentences; and adding the abstract query statement into the original log to obtain a log of the query statement.

In some embodiments of the present application, based on the foregoing solution, the log of query statements includes execution time-consuming of query statements, and the allocation unit is configured to: and distributing the task request to a target server according to the current load capacity of each server in the task processing cluster, so that the target server stores the log of the query statement, and returning the log of the query statement to a requester of the data query request according to the received data query request, wherein the requester of the data query request generates an execution time consumption curve corresponding to the abstract query statement according to the execution time consumption of the query statement in the log of the query statement.

In some embodiments of the present application, based on the foregoing scheme, the execution time-consuming curve of the abstract query statement is used to generate an anomaly detection result.

According to an aspect of the embodiments of the present application, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a task request allocation method as described in the above embodiments.

According to an aspect of an embodiment of the present application, there is provided an electronic device including: one or more processors; and a storage device for storing one or more programs, which when executed by the one or more processors, cause the one or more processors to implement the task request allocation method as described in the above embodiments.

According to an aspect of the embodiments of the present application, there is provided a computer program product comprising computer instructions stored in a computer-readable storage medium, from which computer instructions a processor of a computer device reads, the processor executing the computer instructions, causing the computer device to perform the task request allocation method as described in the above embodiments.

According to the technical scheme provided by the embodiments of the application, the load information of each server is obtained every preset time period, the current load capacity of each server for measuring the whole load is determined according to the load information, the reference server is selected from the servers, the load increment of the reference server is estimated according to the current load capacity and the current connection number of the reference server, meanwhile, the processing capacity value of the server is determined according to the obtained multiple performance index data of each server, the load information and the current load capacity of each server are prevented from being frequently obtained, and the load on the server is reduced; on the basis, if a task request is received within a current preset time period, because the acquired time of the current load of each server is a period of time from the current time, task request distribution is performed based on the current load of each server acquired recently, which may cause a problem of unbalanced load.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is apparent that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art. In the drawings:

FIG. 1 shows a schematic diagram of an exemplary system architecture to which the technical solutions of embodiments of the present application may be applied;

FIG. 2 illustrates a flow chart of a method of allocation of task requests according to one embodiment of the present application;

FIG. 3 illustrates an overall frame schematic according to one embodiment of the present application;

FIG. 4 shows a flowchart of the details of step 210 in the embodiment of FIG. 2, according to one embodiment of the present application;

FIG. 5 shows a flowchart of details of step 220 in the embodiment of FIG. 2, according to one embodiment of the present application;

FIG. 6 illustrates a flow chart of a requestor of a task request generating a log of query statements, according to one embodiment of the present application;

FIG. 7 illustrates a flow chart of distributing task requests to target servers for processing according to a current load of each server in a task processing cluster, according to one embodiment of the present application;

FIG. 8 illustrates a schematic diagram of an execution time-consuming curve corresponding to an abstract query statement, according to one embodiment of the application;

fig. 9 shows a schematic diagram of early warning information presented in group chat according to an embodiment of the present application;

FIG. 10 illustrates a block diagram of a task request distribution device according to one embodiment of the present application;

fig. 11 shows a schematic diagram of a computer system suitable for use in implementing the electronic device of the embodiments of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the present application. One skilled in the relevant art will recognize, however, that the aspects of the application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the application.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

In the related art, a conventional load balancing scheduling module may acquire loads of a plurality of servers respectively, and distribute task requests according to a load balancing policy according to the loads of the servers, where the loads of the servers are evaluated by the load balancing scheduling module according to the number of connections of the servers. This approach suffers from two distinct drawbacks:

1. the load of the server is simply represented by the connection number of the server, the load condition of the server cannot be accurately represented, and therefore, the scheduling of load balancing is inaccurate. Specifically, the load that different connections can bring to the server is different, so the same number of connections cannot represent the same load.

2. In the long-time running process of the system, the load balancing scheduling module cannot acquire the load of the server again, namely, the load balancing scheduling module does not communicate with the server for a long time, when task request distribution is performed again, the actual load of the server may change, and therefore the load balancing scheduling module cannot change the scheduling behavior of the server, and further the problem of unbalanced load is caused.

For this purpose, the present application first provides a task request allocation method. The task request distribution method provided by the embodiment of the application can overcome the defects, not only can the representation of the load condition of the server be more accurately realized, but also the accurate estimation of the load of the server can be realized under the condition that frequent communication is not carried out with the server, thereby realizing the load balance of the system.

Fig. 1 shows a schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of the present application may be applied. As shown in fig. 1, the system architecture 100 may include a user terminal 110, a database server 120, a gateway server 130, a scheduling server 140, a server cluster 150, and a web server 160. Communication connections are established between the user terminal 110 and the gateway server 130, between the gateway server 130 and the database server 120, between the gateway server 130 and the scheduling server 140, between the scheduling server 140 and the server cluster 150, between the server cluster 150 and the web server 160, and between the user terminal 110 and the web server 160, the server cluster 150 specifically comprises a first server 151, a second server 152 and a third server 153, a database is deployed on the database server 120, a first client for accessing the database and a second client for accessing the web server 160 are deployed on the user terminal 110, an acquisition process and a gateway are deployed on the gateway server 130, the acquisition process establishes a connection with a certain server in the server cluster 150 through the scheduling server 140, and a time-consuming curve generating module and a web server are deployed on the web server 160. The scheduling server 140 is an execution body in the embodiment of the present application, and when a task request allocation method provided in the present application is applied to the system architecture shown in fig. 1, one process may be as follows: first, the first client of the user terminal 110 sends a query request for querying the database to the database server 120 via the gateway server 130, and the gateway of the gateway server 130 stores an original log corresponding to a query statement in the query request; then, the collecting process on the gateway server 130 collects an original log, performs format conversion according to the query statement in the original log to obtain an abstract query statement, generates a fingerprint corresponding to the abstract query statement, and adds the abstract query statement and the fingerprint corresponding to the abstract query statement into the original log corresponding to the query statement to obtain a log corresponding to the query statement; next, the scheduling server 140 obtains multiple load information corresponding to each server of the server cluster 150 at intervals of a predetermined time period, determines a current load amount of each server according to the multiple load information corresponding to each server, selects a reference server from each server in the server cluster 150, estimates a load increment of the reference server according to the current load amount and the current connection number of the reference server, and determines a processing capacity value of each server according to the obtained multiple performance index data of each server in the server cluster 150; then, each time a server in the server cluster 150 receives or processes a task request for importing a log into the server cluster 150 from the collection process in a current predetermined period of time, the scheduling server 140 adjusts and updates the current load of the server according to the processing capacity value of the reference server, the processing capacity value of the server and the last obtained load increment of the reference server; next, when the scheduling server 140 receives a task request for importing a log into the server cluster 150 from the collecting process again at the current time within the current predetermined period, the scheduling server 140 allocates the task request to a certain server according to the current load of each server to process, so that the server obtains the log imported by the collecting process, that is, if the allocated server is the server which has already established a connection with the collecting process, the collecting process imports the log into the allocated server through the established connection, and if the allocated server has not yet established a connection with the collecting process, the collecting process establishes a connection with the allocated server and imports the log into the server; then, a time-consuming curve generating module on the web server 160 acquires the logs stored by each server in the server cluster 150 by calling an interface provided by the server cluster 150 to the outside, and generates a time-consuming curve corresponding to the abstract query statement according to the logs; finally, the web server 160 returns to the user terminal 110 and displays the time-consuming curve corresponding to the abstract query sentence on the second client according to the time-consuming curve viewing request sent by the second client on the user terminal 110.

In some embodiments of the present application, a monitoring alarm module is further provided on the web server 160, and the monitoring alarm module analyzes the time-consuming curve and alarms when an abnormality is found.

In some embodiments of the present application, the raw logs collected by the collection process on the gateway server 130 are obtained by filtering all raw logs stored by the gateway of the gateway server 130 according to a predetermined rule.

In some embodiments of the present application, the server cluster is an elastic search cluster.

In some embodiments of the present application, the reference server is randomly selected by the dispatch server 140 from among the servers of the server cluster 150.

It should be understood that the number of user terminals, database servers, gateway servers, acquisition processes on gateway servers, scheduling servers, servers in a server cluster, and web servers in fig. 1 are merely illustrative. According to the implementation requirement, the system can be provided with any number of user terminals, database servers, gateway servers, scheduling servers and web servers, the number of processes on each gateway server and the number of servers in the server cluster can be also any, for example, the number of service machines contained in the server cluster can be less than three or can exceed three, the number of acquisition processes on the gateway servers can be multiple, the database servers can be database server clusters formed by a plurality of database servers, the database server clusters and the gateway servers can be multiple, the database server clusters and the gateway servers are in one-to-one correspondence, and the original logs corresponding to query sentences in the query requests received by one database server cluster can be recorded in the corresponding gateway servers.

It should be noted that fig. 1 illustrates only one embodiment of the present application. Although in the solution of the embodiment of fig. 1, the user terminal for sending the time-consuming curve view request and the user terminal for sending the query request are the same user terminal, in other embodiments of the present application, the user terminal and the user terminal may be different user terminals; although in the solution of the embodiment of fig. 1, the entity for generating the time-consuming curves and the entity for alerting are both web servers, in other embodiments of the present application they may also be different servers; although in the solution of the embodiment of fig. 1, the user terminal is a desktop computer, and all servers in the server cluster are servers of the same type, in other embodiments of the present application, the user terminal may also be various types of terminal devices such as a notebook computer, a tablet computer, a smart phone, a portable wearable device, a vehicle-mounted terminal, a workstation, and the like, and the types of different servers in the same server cluster may also be different. The embodiments of the present application should not be limited in any way, nor should the scope of protection of the present application be limited in any way.

It is easy to understand that the task request distribution method provided in the embodiments of the present application is generally executed by a server, and accordingly, the task request distribution device is generally disposed in the server. However, in other embodiments of the present application, the terminal device may also have a similar function as the server, so as to execute the allocation scheme of the task request provided in the embodiments of the present application.

Therefore, the embodiment of the application can be applied to a terminal or a server. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligent platforms. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc. The terminal and the server may be directly or indirectly connected through wired or wireless communication, which is not limited herein.

The implementation details of the technical solutions of the embodiments of the present application are described in detail below:

fig. 2 illustrates a flow chart of a method of task request distribution that may be performed by various computing and communication capable devices, such as a user terminal including, but not limited to, a cell phone, a computer, a smart voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, etc., or a cloud server, according to one embodiment of the present application. Referring to fig. 2, the task request allocation method at least includes the following steps:

In step 210, multiple load information corresponding to each server in the task processing cluster is obtained at intervals of a predetermined time period, and the current load of each server is determined according to the multiple load information corresponding to each server.

The current load is used to measure the current overall load of the server.

The predetermined period of time may be any length of time, and the time length T of the predetermined period of time may be, for example, 30 seconds, 1 minute, 2 minutes, or the like. If the time length T of the predetermined time period is 1 minute and the time point 12:00 is the first time to obtain the multiple load information corresponding to each server in the task processing cluster, then the multiple load information corresponding to each server in the task processing cluster is obtained again every next minute after 12:00, for example, the multiple load information corresponding to each server in the task processing cluster is obtained again every time point 12:01, 12:02, 12:03, and the like after 12:00, and the current load of each server at every time point is determined.

FIG. 3 illustrates an overall frame schematic according to one embodiment of the present application. Referring to fig. 3, a scheduling module may be used to perform the steps of the embodiments of the present application, where the scheduling module may be located on a server; the task processing cluster is ES (ElasticSearch) cluster shown in fig. 3, and the servers in the task processing cluster are ES nodes in the ES cluster. The elastiscearch is a Lucene-based search server. It provides a distributed multi-user capable full text search engine based on RESTful web interface.

In one embodiment of the present application, the plurality of items of load information include at least two of: CPU occupancy rate, disk read-write occupancy rate, memory occupancy rate, network bandwidth occupancy rate and request process occupancy rate.

The disk read-write occupancy rate is the disk I/O occupancy rate, and the request process occupancy rate measures the utilization degree of CPU resources by a specific process. The plurality of items of load information may include all items listed in the above embodiment.

Fig. 4 shows a flowchart of the details of step 210 in the embodiment of fig. 2 according to one embodiment of the present application. Referring to fig. 4, determining the current load of each server according to multiple load information corresponding to each server, which may specifically include the following steps:

in step 211, weights corresponding to the load information are acquired.

The weights corresponding to the load information can be set according to the needs. Taking the example that the plurality of load information includes five load information items in the above embodiments, the weights corresponding to the load information items may be expressed in the form of vectors as λ= (λ) ₁ ,λ ₂ ,λ ₃ ,λ ₄ ,λ ₅ ) Wherein lambda is ₁ Weighting, lambda, corresponding to the CPU occupancy U (C) ₂ The weight lambda corresponding to the disk read-write occupancy U (D) ₃ Is the weight corresponding to the memory occupancy rate U (M), lambda ₄ For the weight corresponding to the network bandwidth occupancy U (N), lambda ₅ The weight corresponding to the request process occupancy U (P) is obtained. Since the server is configured to receive the imported log, the import of the log has a relatively large influence on the CPU, disk IO, and network bandwidth performance of the server, so λ may be set to λ= (0.25,0.3,0.1,0.25,0.1).

In one embodiment of the present application, obtaining weights corresponding to each item of load information includes: determining the service type of a server; and determining the weight corresponding to each item of load information according to the service type of the server.

The service type of the server can be determined according to the change condition of various load information of the server before and after the server processes the task request. Because the embodiment of the application is used for the service type of the log import service, the influence on the CPU, the disk IO and the network bandwidth performance of the server is larger, and the weight corresponding to the load information is larger. If the service type of the server is CPU and memory consumption type service, the weight corresponding to the two load information of the CPU occupancy rate and the memory occupancy rate can be increased.

In step 212, for each server, a weighted sum of the load information corresponding to the server is determined as the current load of the server according to the weight corresponding to the load information.

The weighted sum of the respective items of load information corresponding to the server may be calculated by calculating a dot product of the vector representation of the respective items of load information and the vector representation of the respective items of load information. Specifically, the weighted sum of the load information items corresponding to the server may be determined by the following formula:

U(Si)＝(λ ₁ ,λ ₂ ,λ ₃ ,λ ₄ ,λ ₅ )·(U(Ci),U(Di),U(Mi),U(Ni),U(Pi))，i＝0,1,…，

n-1, wherein U (Si) is a weighted sum of various load information corresponding to the server Si, namely the current load capacity of the server Si, U (Ci) is the CPU occupancy rate of the server Si, U (Di) is the disk read-write occupancy rate of the server Si, U (Mi) is the memory occupancy rate of the server Si, U (Ni) is the network bandwidth occupancy rate of the server Si, U (Pi) is the request process occupancy rate of the server Si, and n is the number of servers in the task processing cluster.

In step 220, for each server in the task processing cluster, a processing capacity value of the server is determined from the plurality of performance index data of the server.

The processing power of different servers in a task processing cluster may be different. When load balancing calculation is performed, if the server cluster is heterogeneous, not only the load capacity of the servers but also the processing capacity of the servers must be considered, so that more tasks can be borne by the servers with good performance.

The processing power value of the server may be pre-calculated before performing step 210.

In one embodiment of the present application, the plurality of performance index data includes at least two of: CPU main frequency, memory capacity, disk read-write speed, network throughput and maximum connection number.

The disk read-write rate is the disk I/O rate. The network throughput is the maximum amount of data that a server can send and receive in a unit time. The maximum number of connections is the upper limit on the number of connections that the server can handle simultaneously.

Fig. 5 shows a flowchart of the details of step 220 in the embodiment of fig. 2 according to one embodiment of the present application. Referring to fig. 5, for each server in the task processing cluster, determining a processing capability value of the server according to multiple performance index data of the server may specifically include the following steps:

in step 221, weights corresponding to the performance index data are obtained.

The weights corresponding to the performance index data can be set as required. Taking the example that the multiple performance index data includes five performance index data in the above embodiments, the weight corresponding to each performance index data may be expressed as β= (β) in the form of a vector ₁ ,β ₂ ,β ₃ ,β ₄ ,β ₅ ) Wherein beta is ₁ For the weight corresponding to the CPU main frequency H (C), beta ₂ For the weight corresponding to the magnetic disk read-write speed H (D), beta ₃ Is the weight corresponding to the memory capacity H (M), beta ₄ For the weight corresponding to the network throughput H (N), beta ₅ The weight corresponding to the maximum connection number H (P). Since the server is configured to receive the imported log, the import of the log has a relatively large influence on the CPU, disk IO, and network bandwidth performance of the server, so β may be set to β= (0.25,0.3,0.1,0.25,0.1).

Similar to the weights corresponding to the various load information, the weights corresponding to the various performance index data can also be determined and adjusted according to the service type of the server. If a server has multiple CPUs, the CPU dominant frequency may specifically be the sum of the dominant frequencies of all CPUs.

In step 222, for each server in the task processing cluster, a weighted sum of the performance index data of the server is determined as a processing capability value of the server according to the weight corresponding to the performance index data.

The weighted sum of the performance index data of the server may be calculated by calculating a dot product between the vector representation of the weights corresponding to the performance index data and the vector representation of the performance index data. Specifically, the weighted sum of the performance index data can be calculated by the following formula server:

H(Si)＝(β ₁ ,β ₂ ,β ₃ ,β ₄ ,β ₅ )·(H(Ci),H(Di),H(Mi),H(Ni),H(Pi))，i＝0,1,…，n-1，

Wherein, H (Si) is a weighted sum of various performance index data of the server Si, that is, a processing capability value of the server Si, H (Ci) is a CPU main frequency of the server Si, H (Di) is a disk read/write rate of the server Si, H (Mi) is a memory capacity of the server Si, H (Ni) is a network throughput of the server Si, H (Pi) is a maximum connection number of the server Si, and n is a number of servers in the task processing cluster.

In step 230, a reference server is selected from the servers of the task processing cluster at predetermined intervals, and a load increment of the reference server is estimated according to the current load amount and the current connection number of the reference server.

The load increment is the load increased after the reference server receives an allocated task request.

The execution time of step 230 and step 210 may be the same time, i.e., every predetermined period of time, and step 230 may be executed immediately after step 210 is executed.

The reference server may be selected randomly from the servers of the task processing cluster, or may be selected from the servers of the task processing cluster according to a certain rule.

Specifically, the load delta of the reference server can be estimated by the following formula:

i (M reference) =u (S reference)/P,

Wherein I (M reference) is an estimated load increment of the reference server, U (S reference) is a current load amount of the reference server obtained through step 210, and P is a current connection number of the reference server.

It can be seen that the above formula is an estimate of the load amount generated by a connection for accepting a task request.

And step 240, updating the current load capacity of the server according to the processing capacity value of the reference server, the processing capacity value of the server and the load increment of the reference server obtained when the last preset time period is finished every time the server receives or processes a task request in the current preset time period.

If the server is queried for the load information once at the time T1 and the load of the server once is calculated, the next query for the load information is performed at the time t1+T. If multiple task requests are received within a predetermined period of time T and the allocation of each task request is calculated using the load information queried at time T1, then the task requests may be allocated to the same server, resulting in load imbalance. According to the method and the device, the actual current load capacity of the server is predicted by introducing the concept of load increment, so that the situation can be avoided, and load balancing is achieved.

The load delta may also vary for heterogeneous nodes due to different processing capabilities. And should therefore be adapted to the processing capacity H (Si) of the server Si. The updated current load of the server Si can be calculated by the following formula:

u "(Si) =u (Si) +h (reference)/H (Si) ×i (M reference),

wherein U "(Si) is the updated current load amount of the server Si, U (Si) is the current load amount of the server Si obtained at the end of the last preset time period, H (reference) is the processing capacity value of the reference server, H (Si) is the processing capacity value of the server Si, and I (M reference) is the estimated load increment of the reference server at the end of the last preset time period.

In the conventional manner, if the load increment of each server needs to be calculated, the server needs to interact with each server once more, and the connection number of the servers is obtained. In the embodiment of the application, the load increment of the server is estimated by determining the ratio of the processing capacity value of the reference server to the processing capacity value of the server Si and multiplying the ratio by the load increment of the reference server, and the load increment of different servers can be calculated according to the inherent performance difference between the servers only by acquiring the load increment of the reference server once, so that the performance of the scheduling module can be effectively improved.

For example, if the reference server receives 10 task requests through the connection, the task requests increase the CPU occupancy rate and the disk I/O occupancy rate of the reference server by 10%, and assuming that there is a server that is twice as strong as the reference server in all aspects, the task requests are also allocated to the server for processing, the load increment of the server is 1/2×i (M reference) according to the above formula, which is equivalent to that the task requests are also allocated to the server for processing, and the CPU occupancy rate and the disk I/O occupancy rate are only increased by 5% respectively.

Similarly, if the server Si completes a task request within the current predetermined time period, that is, if the server Si completes a task by processing at time T3 (T1 < T3< t1+t), the updated current load of the server Si may be calculated by the following formula:

u "(Si) =u (Si) -H (reference)/H (Si) ×i (M reference),

Of course, after that, if a server accepts or processes a task request again in a current predetermined period of time, the current load of the server is updated again on the basis of the updated current load.

In step 250, if a task request is received within a current predetermined period of time, the task request is distributed to a target server for processing according to the current load of each server in the task processing cluster.

Next, the task request will be described in detail.

In one embodiment of the present application, a task request is used to import a log of query statements into a server of a task processing cluster, the log of query statements being collected from a database by a requestor of the task request.

The database here may be MySQL. By setting the slow query threshold parameter to 0, i.e., long_query_time=0, when the execution time of the query statement exceeds 0, the corresponding query statement will be recorded in the slow query log of the database.

In one embodiment of the present application, the task request is used to import a log of query statements into a server of the task processing cluster, the log of query statements being collected by a requestor of the task request from a gateway of a database, the database receiving, through the gateway, a query request containing the query statements.

The requesting party of the task request, i.e. the acquisition module shown in fig. 3, may run in the form of an acquisition thread, which may be located on the same gateway server as the gateway in the gateway group.

In the embodiment of the application, the logs of the total query sentences can be acquired on the premise of not affecting the performance of the database by acquiring the logs from the gateway of the database.

FIG. 6 illustrates a flow chart of a requestor of a task request generating a log of query statements, according to one embodiment of the present application. Referring to FIG. 6, a requestor of a task request may generate a log of query statements by:

in step 610, an original log is collected from a gateway of a database.

With continued reference to fig. 3, the client sends a query request containing a query statement, here an SQL (Structured Query Language ) statement, to a DataBase (DB), and thus the query request may be an SQL request. The gateways in the gateway group can generate an original log corresponding to the query statement according to the SQL request. The acquisition module may acquire the raw log from a gateway of the database.

When the original logs are collected from the gateway of the database, the original logs meeting the set rule can be collected only from all the original logs in the gateway of the database according to the set rule. Specifically, configuration files may be configured for the collection process of the collection module, where a path that needs to collect the log from the gateway server, a target log that needs to be collected, a log that needs to be filtered, a split that needs to be made on the log, a target end that needs to import the log, and the like are defined in the configuration files. The collection process of the collection module can collect and import the log according to the configuration file.

In step 620, format conversion is performed on the query statement in the original log to obtain an abstract query statement, where the abstract query statement is used to refer to a class of query statement that includes the query statement.

An abstract query statement, i.e., an SQL fingerprint, is used to characterize a class of SQL statements, and therefore, may be referred to as a template for a class of SQL statements. Different query statements may correspond to the same abstract query statement.

The format conversion of the query statement to obtain an abstract query statement is that the conditional part of the SQL statement is changed into a question mark, and only the main body of the SQL statement is left.

Specifically, if two SQL statements in the original log are:

select name,grade from user

where name like'Ben％'and dt>'2022-07-06'；

SELECT name,grade FROM user WHERE name like'MIKE％'and dt>'2022-04-06'；

then, the abstract query statements generated from the two SQL statements are identical, both:

select name,grade from user where name likeand dt>？。

the following describes the specific steps of how an abstract query statement is generated:

if the following SQL statements are involved in the original log:

select/*SLAVE*/id,USER,Birth from user_2022where name in('Ben','Mike','Jack')

UNION

select/*SLAVE*/id,USER,BIRTH FROM user_2019where name in('Ben','Mike','Jack','Ken')；

the steps for generating the abstract query statement according to the SQL statement are as follows:

1. the notes of the SQL statement are removed.

The result obtained after the SQL statement is annotated is as follows:

select id,USER,Birth from user_2022where name in('Ben','Mike','Jack')

UNION

select id,USER,BIRTH FROM user_2019where name in('Ben','Mike','Jack','Ken')。

2. the replacement of all the letters and numbers with question marks, for example, the replacement of the quotation marks of the strings, and the numbers embedded in the identifiers are also replaced, and the replacement of the letters and numbers is somewhat non-selective, since all the letters and numbers are replaced, which can improve the replacement efficiency.

After the treatment of this step, the following results were obtained:

select id,USER,Birth from user_？where name in('？','？','？')

UNION

select id,USER,BIRTH FROM user_？where name in('？','？','？','？')。

3. all the spaces are folded into one space.

After the treatment of this step, the following results were obtained:

select id,USER,Birth from user_？where name in('？','？','？')

UNION

select id,USER,BIRTH FROM user_？where name in('？','？','？','？')。

4. the uppercase letters of the entire SQL statement are replaced with the corresponding lowercase letters.

After the treatment of this step, the following results were obtained:

select id,user,birth from user_？where name in('？','？','？')

union

select id,user,birth from user_？where name in('？','？','？','？')。

5. all words IN the IN () and value () lists are replaced with one placeholder, regardless of the base.

After the treatment of this step, the following results were obtained:

select id,user,birth from user_？where name in(？)

union

select id,user,birth from user_？where name in(？)。

IN () represents a value list for screening data IN a where clause, and VALUES () is used to INSERT a plurality of VALUES IN an INSERT statement.

6. Multiple identical UNION queries are combined into one query.

The UNION operator is used to merge the result sets of two or more SELECT statements.

After the treatment of this step, the following results were obtained:

select id,user,birth from user_？where name in(？)。

the above steps are the log cleaning operation shown in fig. 3.

In step 630, the abstract query statement is added to the original log, resulting in a log of query statements.

In one embodiment of the present application, adding an abstract query statement to an original log to obtain a log of query statements includes: generating a fingerprint identifier corresponding to the abstract query statement; and adding the abstract query statement and the corresponding fingerprint mark into the original log to obtain a log of the query statement.

The fingerprint Identifier (ID), which is a unique identifier corresponding to the abstract query statement, may use the md5sum tool under linux to generate a summary of the abstract query statement as the fingerprint identifier corresponding to the abstract query statement.

For example, for the abstract query statement in step 6 described above, the fingerprint identification may be generated by:

md5sum"select id,user,birth from user_？where name in(？)；"，

the resulting fingerprint may be 843421dd49ca87e126d8d7f1939a25b2.

Of course, fingerprint identifiers can be generated in other manners, for example, all symbols in the abstract query statement can be arranged in reverse order to obtain the reverse-order abstract query statement; splicing the abstract query statement and the reverse-order abstract query statement to obtain a spliced statement; and generating the abstract of the spliced statement to serve as a fingerprint identifier corresponding to the abstract query statement. By taking the abstract of the spliced sentence as the fingerprint mark, the data length for generating the abstract can be prolonged, and the uniqueness of the generated fingerprint mark is further ensured.

In one embodiment of the present application, adding an abstract query statement and a corresponding fingerprint identifier to an original log to obtain a log of the query statement includes: splitting fields in the original log to obtain an original log in a target format; and adding the abstract query statement and the corresponding fingerprint mark into the original log in the target format to obtain the log of the query statement.

Specifically, a log of query statements may be as follows:

timestamp:2022-07-21 11:31:38 212033

topic:set_1

clientIP:9.9.9.9

sql_size:262

sql_type:3

sub_sql_type:0

sql:SELECT name,grade FROM user WHERE name like'MIKE％'and dt>'2022-04-06'；

sql_summary:select name,grade from user where name likeand dt>？；

sql_checksum:843421dd49ca87e126d8d7f1939a25b2

db:test

user:test

autocommit:1

timecost:600

wherein, timestamp is the inquiry time; sql represents a query statement; sql_summary is a newly added field representing an abstract query statement; sql_checksum is a newly added field representing a fingerprint identifier corresponding to the abstract query statement; timect represents the time-consuming execution of a query statement in milliseconds.

The log of another query statement may be as follows:

timestamp:2022-07-21 11:31:38 212033

topic:set_1

clientIP:9.9.9.9

sql_size:262

sql_type:3

sub_sql_type:0

sql:select name,grade from user

where name like'Ben％'and dt>'2022-07-06'；

sql_summary:select name,grade from user where name likeand dt>？；

sql_checksum:843421dd49ca87e126d8d7f1939a25b2

db:test

user:test

autocommit:1

timecost:600

the meaning of the symbol in the log is identical to the meaning of the corresponding symbol in the log of the query statement, and will not be described here again.

By adding abstract query sentences and corresponding fingerprint marks in the log, the performance change of the same type of sentences can be detected without being influenced by sentence writing methods, and the aggregate analysis of the query sentences of one type can be realized.

In one embodiment of the present application, distributing a task request to a target server according to a current load of each server in a task processing cluster for processing, includes: and selecting the server with the minimum current load as a target server, and distributing the task request to the target server for processing.

In one embodiment of the present application, distributing a task request to a target server according to a current load of each server in a task processing cluster for processing, includes: sequencing all servers in the task processing cluster according to the current load quantity from small to large; and selecting one server from the preset number of servers positioned at the forefront in sequence as a target server, and distributing the task request to the target server for processing.

When the task request is allocated, the allocation may be further performed in combination with the processing capability value of each server.

FIG. 7 illustrates a flow chart of distributing task requests to target servers for processing according to a current load of each server in a task processing cluster, according to one embodiment of the present application. Referring to fig. 7, the task request is distributed to a target server according to the current load of each server in the task processing cluster, so as to process the task request, which specifically includes the following steps:

in step 710, at least one candidate server is selected from the servers in the task processing cluster and added to the candidate server set, wherein the current load of the candidate server is smaller than the current load of other servers in the task processing cluster.

And selecting a plurality of candidate servers with the minimum current load capacity from the servers of the task processing cluster, and adding the candidate servers into the candidate server set.

In one embodiment of the present application, selecting at least one candidate server from the servers of the task processing cluster to join the candidate server set includes: the server with the minimum current load capacity is used as a target candidate server to be added into a candidate server set; and determining a server of which the difference value between the corresponding current load amount and the target candidate server is smaller than a preset difference value threshold, and adding the determined server serving as a candidate server into the candidate server set.

Specifically, the target candidate server Sj is first determined and added to the candidate server set E, where the following condition is satisfied, that is, the current load amount U "(Sj) of the target candidate server Sj is the minimum value of the current load amounts of all servers:

U”(Sj)＝min|U”(Si)|，i＝0,1,…,n-1；

then, a server meeting a certain load requirement is screened by setting an elasticity coefficient f, and if the load quantity of any other server Si meets the following conditions, the server is added into the set E:

U(Si)<U(Sj)+f，i＝0,1,…,n-1，

wherein the spring constant f is a predetermined difference threshold.

In step 720, a task request allocation probability for each candidate server is determined based on the processing power values of each candidate server in the set of candidate servers.

The sum of the processing power values of all candidate servers may be determined, and then for each candidate server, a ratio of the processing power value of that candidate server to the sum of the processing power values of all candidate servers is determined as the task request allocation probability of that candidate server.

Specifically, the task request allocation probability of the candidate server Si can be calculated by the following formula:

wherein, P (Si) is the task request allocation probability of the candidate server Si, H (Si) is the processing capacity value of the candidate server Si, and H (i) is the processing capacity value of the candidate server i.

In step 730, the task request is distributed to the target server for processing according to the task request distribution probability of each candidate server.

The greater the task request allocation probability for a candidate server, the greater the likelihood that the task request will be allocated to the candidate server.

In the following, how the scheduling module performs load scheduling will be described in connection with examples.

The three servers S1, S2 and S3 are available, and the current values corresponding to the five load information of the CPU occupancy rate, the disk read-write occupancy rate, the memory occupancy rate, the network bandwidth occupancy rate and the request process occupancy rate are respectively: s1= [50%,50%,50%,50%,50% ], s2= [40%,40%,40%,40%,40% ], s3= [30%,30%,30%,30%,30% ].

Step 1, assuming that a task request is currently received, obtaining current load amounts corresponding to three servers through the current load amount calculation formula, wherein the current load amounts are respectively as follows: u (S1) =0.5, U (S2) =0.4, and U (S3) =0.3. Since the current load of the server S3 is the lowest, it is added to the candidate server set E;

step 2. Assuming that the elastic modulus f is 0.15, then, since U (S2) < U (S3) +f, adding the server S2 to the candidate server set E;

And 3, determining task request allocation probabilities of the server S3 and the server S2 according to the calculation formula of the task request allocation probabilities, and allocating the task request to the server S3 or the server S2 according to the task request allocation probabilities, wherein the server S1 is not in the candidate server set E, so that the server S1 is directly not involved in the load balancing scheduling at the time.

Assuming that the processing capacity of the server S2 is 6 and the processing capacity of the server S3 is 4, the task request allocation probability of the server S2 is 6/6+4=60% and the task request allocation probability of the server S3 is 4/6+4=40%.

Step 4, in the predetermined period, assuming that the time length T is 30 seconds, if a new task request is received within the 30 seconds, the current load of each server is calculated according to the foregoing calculation formula of the current load, for example, let the server S2 be a reference server and the load increment be 0.1, and then the updated current load of the server S2 is:

U”(S2)＝U(S2)+1/1×0.1＝0.4+1/1×0.1＝0.5。

for the subsequently received task request, if the moment of receiving the task request is within the current preset time period, continuing to distribute the task according to the steps 1-4; if the actual load condition U (Si) of each server node is pulled again in real time after the current preset time period, the allocation logic shown in the steps 1-4 is re-entered based on the actual load condition of the re-pulling.

Specifically, the latest current load amounts corresponding to the three servers are respectively: u (S1) =0.5, U (S2) =0.5, U (S3) =0.3, according to step 1, adding the server S3 with the lowest current load to the candidate server set E; then, according to steps 2 and 3, neither server S1 nor S2 is in candidate server set E, only server S3 has participated in the current load balancing schedule; next, according to step 4, the task request allocation probability of the server S3 is 100%; finally, assuming that the load increment brought to the server S3 by the new task request is 0.1, the updated current load amount of the server S3 becomes 0.4.

In one embodiment of the present application, the log of the query statement includes time consumed for executing the query statement, and the task request is distributed to the target server for processing according to the current load of each server in the task processing cluster, including: and distributing the task request to a target server according to the current load capacity of each server in the task processing cluster, so that the target server stores the log of the query statement, returning the log of the query statement to a requester of the data query request according to the received data query request, and generating an execution time consumption curve corresponding to the abstract query statement by the requester of the data query request according to the execution time consumption of the query statement in the log of the query statement.

With continued reference to fig. 3, the SQL time-consuming curve generation module may call an interface provided by the ES cluster from outside in the manner of an HTTP request to obtain a log of query statements from the ES cluster; the SQL time-consuming curve generating module is a requester of the data query request, and generates an execution time-consuming curve according to the acquired log, wherein the time-consuming curve can be displayed at the front end according to the request of the client.

FIG. 8 illustrates a schematic diagram of an execution time-consuming curve corresponding to an abstract query statement, according to one embodiment of the application. Referring to fig. 8, a coordinate system is shown, the horizontal axis is time, the vertical axis is execution time of the SQL statement corresponding to each abstract query statement, the unit is ms, and execution time curves corresponding to a plurality of abstract query statements can be drawn in the coordinate system.

In one embodiment of the present application, an execution time-consuming curve corresponding to an abstract query statement is used to generate an anomaly detection result.

With continued reference to fig. 3, the monitoring alarm module may obtain an execution time-consuming curve from the SQL time-consuming curve generating module, analyze the execution time-consuming curve by using a machine learning model to obtain an anomaly detection result, and may also obtain a cause of the anomaly, and may alarm when the anomaly is detected.

Fig. 9 shows a schematic diagram of early warning information presented in group chat according to an embodiment of the present application. Referring to fig. 9, the early warning information may be notified to the user in group chat such as a micro-community, and the root cause of the early warning may be output, so that the user can process in time.

In summary, according to the task request distribution method provided by the embodiment of the application, the load capacity of each server in a long-time running state of the system can be ensured not to deviate greatly, so that the processing capacity of the server is fully utilized, the processing efficiency of the cluster is improved, and the log importing efficiency can be improved in a log importing scene.

The following describes an embodiment of an apparatus of the present application, which may be used to perform the task request allocation method in the above embodiment of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the task request allocation method described in the present application.

FIG. 10 illustrates a block diagram of a task request distribution device according to one embodiment of the present application.

Referring to fig. 10, a task request distribution device 1000 according to an embodiment of the present application includes: an acquisition unit 1010, a determination unit 1020, an estimation unit 1030, an update unit 1040, and an allocation unit 1050. The acquiring unit 1010 is configured to acquire multiple load information corresponding to each server in the task processing cluster at intervals of a predetermined time period, and determine a current load capacity of each server according to the multiple load information corresponding to each server, where the current load capacity is used to measure a current overall load of the server; the determining unit 1020 is configured to determine, for each server in the task processing cluster, a processing capability value of the server according to multiple performance index data of the server; the estimating unit 1030 is configured to select a reference server from the servers of the task processing cluster at intervals of a predetermined period, and estimate a load increment of the reference server according to a current load capacity and a current connection number of the reference server, where the load increment is an increased load capacity after the reference server receives an allocated task request; the updating unit 1040 is configured to update, each time a server accepts or processes a task request in a current predetermined period of time, a current load capacity of the server according to a processing capability value of the reference server, a processing capability value of the server, and a load increment of the reference server obtained when a last predetermined period of time ends; the allocation unit 1050 is configured to, if a task request is received within the current predetermined period of time, allocate the task request to a target server for processing according to the current load of each server in the task processing cluster.

In some embodiments of the present application, based on the foregoing, the plurality of load information includes at least two of: CPU occupancy rate, disk read-write occupancy rate, memory occupancy rate, network bandwidth occupancy rate and request process occupancy rate; the acquisition unit 1010 is configured to: acquiring weights corresponding to various load information; and aiming at each server, determining the weighted sum of the load information corresponding to the server according to the weight corresponding to the load information, and taking the weighted sum as the current load of the server.

In some embodiments of the present application, based on the foregoing approach, the plurality of performance index data includes at least two of: CPU main frequency, memory capacity, disk read-write speed, network throughput and maximum connection number; the determination unit 1020 is configured to: acquiring weights corresponding to the performance index data; and aiming at each server in the task processing cluster, determining the weighted sum of all the performance index data of the server according to the weight corresponding to all the performance index data, and taking the weighted sum as the processing capacity value of the server.

In some embodiments of the present application, based on the foregoing scheme, the allocation unit 1050 is configured to: selecting at least one candidate server from the servers of the task processing cluster and adding the candidate server into a candidate server set, wherein the current load capacity of the candidate server is smaller than the current load capacity of other servers in the task processing cluster; determining task request allocation probability of each candidate server according to the processing capacity value of each candidate server in the candidate server set; and distributing the task requests to the target servers for processing according to the task request distribution probability of each candidate server.

In some embodiments of the present application, based on the foregoing solution, the log of query statements includes execution time-consuming query statements, and the allocation unit 1050 is configured to: and distributing the task request to a target server according to the current load capacity of each server in the task processing cluster, so that the target server stores the log of the query statement, and returning the log of the query statement to a requester of the data query request according to the received data query request, wherein the requester of the data query request generates an execution time consumption curve corresponding to the abstract query statement according to the execution time consumption of the query statement in the log of the query statement.

It should be noted that, the computer system 1100 of the electronic device shown in fig. 11 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.

As shown in fig. 11, the computer system 1100 includes a central processing unit (Central Processing Unit, CPU) 1101 that can perform various appropriate actions and processes, such as performing the method described in the above embodiment, according to a program stored in a Read-Only Memory (ROM) 1102 or a program loaded from a storage section 1108 into a random access Memory (Random Access Memory, RAM) 1103. In the RAM 1103, various programs and data required for system operation are also stored. The CPU 1101, ROM 1102, and RAM 1103 are connected to each other by a bus 1104. An Input/Output (I/O) interface 1105 is also connected to bus 1104.

The following components are connected to the I/O interface 1105: an input section 1106 including a keyboard, a mouse, and the like; an output portion 1107 including a Cathode Ray Tube (CRT), a liquid crystal display (Liquid Crystal Display, LCD), and a speaker; a storage section 1108 including a hard disk or the like; and a communication section 1109 including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section 1109 performs communication processing via a network such as the internet. The drive 1110 is also connected to the I/O interface 1105 as needed. Removable media 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is installed as needed in drive 1110, so that a computer program read therefrom is installed as needed in storage section 1108.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1109, and/or installed from the removable media 1111. When executed by a Central Processing Unit (CPU) 1101, performs the various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present application may be implemented by means of software, or may be implemented by means of hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

As an aspect, the present application also provides a computer-readable medium that may be contained in the electronic device described in the above embodiment; or may exist alone without being incorporated into the electronic device. The computer-readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to implement the methods described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit, in accordance with embodiments of the present application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a usb disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

It will be appreciated that in the specific embodiments of the present application, where video-related data is referred to, user approval or consent is required when the above embodiments of the present application are applied to specific products or technologies, and the collection, use and processing of the related data is required to comply with relevant national and regional laws and regulations and standards.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains.

It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for distributing task requests, the method comprising:

acquiring a plurality of pieces of load information corresponding to each server in a task processing cluster at intervals of a preset time period, and determining the current load capacity of each server according to the plurality of pieces of load information corresponding to each server, wherein the current load capacity is used for measuring the current overall load of the server;

Determining a processing capacity value of each server in the task processing cluster according to multiple performance index data of the server;

selecting a reference server from the servers of the task processing cluster at intervals of a preset time period, and estimating the load increment of the reference server according to the current load capacity and the current connection number of the reference server, wherein the load increment is the load capacity increased after the reference server receives an allocated task request;

each time a server receives or processes a task request in a current preset time period, updating the current load capacity of the server according to the processing capacity value of the reference server, the processing capacity value of the server and the load increment of the reference server obtained when the last preset time period is finished;

and if a task request is received in the current preset time period, distributing the task request to a target server for processing according to the current load capacity of each server in the task processing cluster.

2. The method of task request distribution according to claim 1, wherein the plurality of items of load information include at least two of: CPU occupancy rate, disk read-write occupancy rate, memory occupancy rate, network bandwidth occupancy rate and request process occupancy rate;

The determining the current load capacity of each server according to the corresponding load information of each server comprises the following steps:

acquiring weights corresponding to various load information;

and aiming at each server, determining the weighted sum of the load information corresponding to the server according to the weight corresponding to the load information, and taking the weighted sum as the current load of the server.

3. The method of task request allocation according to claim 1, wherein the plurality of performance index data includes at least two of: CPU main frequency, memory capacity, disk read-write speed, network throughput and maximum connection number;

the determining, for each server in the task processing cluster, a processing capability value of the server according to a plurality of performance index data of the server includes:

acquiring weights corresponding to the performance index data;

and aiming at each server in the task processing cluster, determining the weighted sum of all the performance index data of the server according to the weight corresponding to all the performance index data, and taking the weighted sum as the processing capacity value of the server.

4. The method for distributing task requests according to claim 1, wherein the distributing the task requests to the target servers for processing according to the current load amounts of the servers in the task processing cluster includes:

Selecting at least one candidate server from the servers of the task processing cluster and adding the candidate server into a candidate server set, wherein the current load capacity of the candidate server is smaller than the current load capacity of other servers in the task processing cluster;

determining task request allocation probability of each candidate server according to the processing capacity value of each candidate server in the candidate server set;

and distributing the task requests to the target servers for processing according to the task request distribution probability of each candidate server.

5. The method according to any one of claims 1-4, wherein the task request is used to import a log of query statements into a server of the task processing cluster, the log of query statements being collected by a requestor of the task request from a gateway of a database, the database receiving the query request containing the query statements through the gateway.

6. The method of claim 5, wherein the log of query statements is generated by a requestor of the task request by:

Collecting an original log from a gateway of a database;

performing format conversion on query sentences in an original log to obtain abstract query sentences, wherein the abstract query sentences are used for referring to a class of query sentences including the query sentences;

and adding the abstract query statement into the original log to obtain a log of the query statement.

7. The method for distributing task requests according to claim 6, wherein the log of query sentences includes time consuming execution of query sentences, and the distributing task requests to target servers for processing according to current load amounts of servers in the task processing cluster includes:

and distributing the task request to a target server according to the current load capacity of each server in the task processing cluster, so that the target server stores the log of the query statement, and returning the log of the query statement to a requester of the data query request according to the received data query request, wherein the requester of the data query request generates an execution time consumption curve corresponding to the abstract query statement according to the execution time consumption of the query statement in the log of the query statement.

8. The method of claim 7, wherein the execution time-consuming curve of the abstract query statement is used to generate an anomaly detection result.

9. A task request distribution device, characterized in that the device comprises:

the acquisition unit is used for acquiring a plurality of items of load information corresponding to each server in the task processing cluster at intervals of a preset time period, and determining the current load capacity of each server according to the plurality of items of load information corresponding to each server, wherein the current load capacity is used for measuring the current overall load of the server;

the determining unit is used for determining the processing capacity value of each server in the task processing cluster according to the multiple performance index data of the server;

the estimating unit is used for selecting a reference server from the servers of the task processing cluster at intervals of a preset time period, and estimating the load increment of the reference server according to the current load capacity and the current connection number of the reference server, wherein the load increment is the load capacity increased after the reference server receives an allocated task request;

the updating unit is used for updating the current load capacity of the server according to the processing capacity value of the reference server, the processing capacity value of the server and the load increment of the reference server obtained when the last preset time period is finished every time the server receives or processes a task request in the current preset time period;

And the distribution unit is used for distributing the task request to the target server for processing according to the current load of each server in the task processing cluster if one task request is received in the current preset time period.

10. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs which when executed by the one or more processors cause the one or more processors to implement the method of allocation of task requests according to any one of claims 1 to 8.