CN109450803B - Traffic scheduling method, device and system - Google Patents
Traffic scheduling method, device and system Download PDFInfo
- Publication number
- CN109450803B CN109450803B CN201811058687.9A CN201811058687A CN109450803B CN 109450803 B CN109450803 B CN 109450803B CN 201811058687 A CN201811058687 A CN 201811058687A CN 109450803 B CN109450803 B CN 109450803B
- Authority
- CN
- China
- Prior art keywords
- queue
- threshold
- request
- length
- processed
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
A traffic scheduling method, system and device are disclosed. The method comprises the following steps: acquiring the length of a queue to be processed of each process; enabling the process with the length of the queue to be processed higher than or lower than a first threshold value to seize a request to be distributed based on different rules; and enabling the process with the length of the queue to be processed higher than the second threshold value to pause the process of preempting the request to be distributed. Therefore, the three-division processing aiming at the queue length is realized through the introduction of the first threshold and the second threshold, and the rationality of the system in dealing with various flows is improved. The multi-process flow scheduling mechanism of the invention can ensure efficient resource scheduling in the flow valley through the setting of the water level threshold, simultaneously ensure the robustness of the system and reduce the rejection rate in the flow peak, and can effectively solve the surprise group problem and improve the request delay through the introduction of the scheduling parameters, thereby improving the response capability of a single machine when coping with flow fluctuation and improving the whole service processing capability.
Description
Technical Field
The present invention relates to the field of internet, and in particular, to a method, an apparatus, and a system for traffic scheduling.
Background
Under some high-concurrency and high-flow internet service scenes, a network service framework which is strong in throughput capacity, small in machine resource overhead, low in delay and tightly combined with the service scenes is needed. The industry's high performance network business framework typically employs multi-threading and multi-process processing models.
In connection with domain-specific business scenarios (e.g., searching), the network business framework may need to load a large amount of resources, such as dictionary resources. In consideration of the robustness of the network framework, the requirement of hot upgrade and other characteristics, a multi-process communication model can be selected. In a multiprocess, how to consider throughput capability, request processing delay and system resource overhead is a problem to be solved urgently.
In the prior art, a method of adding a tag has been used to solve the problem of group-frightening benefit when multiple processes monitor the same port, and the problem of request delay can be alleviated to some extent by setting a request queue. However, because the traffic of the network service in actual application fluctuates, the existing traffic scheduling mechanism still cannot deal with a series of problems caused by the traffic fluctuation while considering the above problems of throughput, delay and overhead.
For this reason, there is still a need for a traffic scheduling mechanism that can solve the above problems.
Disclosure of Invention
In order to solve at least one problem, the invention provides a traffic scheduling mechanism aiming at local multi-process. Through the setting of the water level threshold, efficient resource scheduling can be ensured in the flow valley, the robustness of the system is ensured in the flow peak, and the rejection rate is reduced, so that the coping capability of a single machine when coping with flow fluctuation is improved, and the whole service processing capability is improved.
According to an aspect of the present invention, a traffic scheduling method is provided, including: acquiring the length of a queue to be processed of each process; enabling the process with the length of the queue to be processed higher than or lower than a first threshold value to seize the request to be distributed based on different rules; and enabling the process with the length of the queue to be processed higher than the second threshold value to pause the process of preempting the request to be distributed. Therefore, the three-division processing aiming at the queue length is realized through the introduction of the first threshold and the second threshold, and the rationality of the system in dealing with various flows is improved.
The first threshold may be a low water threshold and the second threshold may be a high water threshold. Thus, preempting the to-be-allocated request based on different rules by the process having the pending queue length above or below the first threshold may include: and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed. Thereby. By fully utilizing the processing capacity of each process when the system is idle. For example, the requests to be allocated may be made to be evenly allocated among processes whose pending queue length is less than the low water threshold, thereby increasing overall processing efficiency.
Preferably, the process of making the pending queue length higher or lower than the first threshold preempts the pending allocation request based on different rules comprises: and the process of making the length of the queue to be processed between the high and low water level thresholds preempts the request to be allocated based on the length of the queue to be processed, and further, the process of making the length of the queue to be processed between the high and low water level thresholds and the queue length rank of the queue to be processed higher than a third threshold participates in the preemption of the request to be allocated. Therefore, through the introduction of the weighting parameter, the process with the shortest queue always participates in the request preemption, and the frightening group effect can be effectively solved.
Preferably, at least one of the following parameters is dynamically set based on the system configuration: a first threshold value; a second threshold value; a third threshold value; and the number of processes. Therefore, the adaptation degree of the invention for various application scenes is improved.
The traffic scheduling method of the present invention may further include: the processes that make the length of the queue to be processed higher or lower than at least one fourth threshold value, which is greater than the first threshold value and less than the second threshold value, preempt the request to be allocated based on different rules. Thus, the processing for different queue lengths can be refined by introducing more water lines.
Preferably, the obtaining the length of the queue to be processed of each of the plurality of processes may include: each process updates its own pending queue length to the shared queue area. Thereby conveniently realizing the maintenance and the acquisition of the queue length information.
According to another aspect of the present invention, a service processing system is provided, which includes: a scheduling server for allocating requests to a plurality of service servers; a plurality of service servers, each service server receiving a request assigned by the scheduling server and executing the assigned request using a plurality of processes, and scheduling of the request among the plurality of processes comprising: acquiring the length of a queue to be processed of each process; enabling the process with the length of the queue to be processed higher than or lower than a first threshold value to seize the request to be distributed based on different rules; and enabling the process with the length of the queue to be processed higher than the second threshold value to pause the process of preempting the request to be distributed.
Preferably, the first threshold may be a low water level threshold, the second threshold may be a high water level threshold, and the traffic server may be configured to: and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed.
Preferably, the service server may be configured to: and enabling the process with the queue length to be processed being higher than the third threshold to participate in the process of preempting the request to be allocated in the process with the queue length to be processed being between the high and low water level thresholds.
Preferably, the obtaining the length of the queue to be processed of each of the plurality of processes may include: so that each process updates its own pending queue length to the shared queue area.
The traffic server may reject the request newly allocated by the scheduling server if the pending queue length of all processes is greater than a second threshold.
According to another aspect of the present invention, a traffic scheduling apparatus is provided, including: a queue length obtaining unit, configured to obtain a length of a queue to be processed of each of the multiple processes; and the process rule setting unit is used for enabling the process with the length of the queue to be processed higher than or lower than the first threshold value to preempt the request to be distributed based on different rules, and enabling the process with the length of the queue to be processed higher than the second threshold value to pause the preemption of the request to be distributed.
The first threshold may be a low water level threshold, the second threshold may be a high water level threshold, and the process rule setting unit may be further configured to: and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed.
Preferably, the process rule setting unit may be further configured to: and enabling the process with the queue length to be processed being higher than the third threshold to participate in the process of preempting the request to be allocated in the process with the queue length to be processed being between the high and low water level thresholds.
Preferably, the queue length obtaining unit may be further configured to: so that each process updates its own pending queue length to the shared queue area.
According to yet another aspect of the invention, there is provided a computing device comprising: a processor; and a memory having executable code stored thereon, which when executed by the processor, causes the processor to perform the traffic scheduling method as in any one of the above.
According to an aspect of the invention, a non-transitory machine-readable storage medium is proposed, having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform the traffic scheduling method as defined in any of the above.
The invention realizes a single-machine multi-process flow dynamic scheduling scheme on the basis of a distributed system, and can effectively schedule and optimally utilize each process resource when the flow is low, thereby reducing the request processing delay; when the flow is in a peak, the robustness of processing requests can be improved, and the rejection rate is reduced, so that the throughput capacity is improved; and when the flow is between the peak and the valley, the surprise group effect can be effectively solved, and the optimization of request processing delay, throughput capacity and system resource overhead is realized.
Drawings
The foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the disclosure as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts throughout the exemplary embodiments of the disclosure.
Fig. 1 is a flowchart illustrating a traffic scheduling method according to an embodiment of the present invention.
Fig. 2 is a flowchart illustrating a traffic scheduling method according to another embodiment of the present invention.
Fig. 3 shows an example of a business processing system.
Figure 4 shows a more detailed example of a business processing system.
Fig. 5 is a schematic diagram illustrating a traffic scheduling apparatus according to an embodiment of the present invention.
Fig. 6 is a schematic structural diagram of a computing device that can be used to implement the traffic scheduling method according to an embodiment of the present invention.
Detailed Description
Preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
As described above, in the single-machine multi-process model, how to consider throughput capability, request processing delay, and system resource overhead is an urgent problem to be solved.
Specifically, in order to improve the parallel processing capability, multiple processes are usually used to monitor the same port, and under the condition of a large flow and a short queue to be processed of each process, the multiple processes can quickly acquire each request sent by the port. However, in the case of a small flow, where multiple processes wait for an event at the same time, although an event can only be processed by one process, the event will "wake up" the multiple processes listening to the port, which is a group effect problem that may cause system overhead.
In addition, in order to improve the throughput, a request queue is generally required to be set, and how to process the request queue of the process to acquire and process the request at a more proper time becomes another big problem.
To solve the group effect problem, the industry generally adopts a lock marking method, for example, after the linux2.6 version, the group effect problem of the kernel processing accept () function is solved by adding a mark so that only one process is woken up at a time.
In addition, the method similar to the above-mentioned lock marking method is adopted by Nginx (i.e. engine x, which is a high-performance HTTP and reverse proxy server, and is also an IMAP/POP3/SMTP server), and a method combining mutually exclusive locks and request queues is adopted to solve the above-mentioned two problems of frightening effect and request receiving opportunity.
The above methods still have some disadvantages. Because actual flow fluctuates and has high peaks and low valleys, the technical problem to be solved urgently in the field is solved by reasonably responding to the situation that the flow is high and low valleys while the frightened group effect is solved and the opportunity is obtained based on the queue optimization request.
Therefore, the invention provides a new local multi-process traffic scheduling scheme, which ensures that each process resource is effectively scheduled to reduce request processing delay in the low-valley of traffic and can ensure the robustness of processing requests in the high-peak of traffic by introducing high and low water lines. Fig. 1 is a flowchart illustrating a traffic scheduling method according to an embodiment of the present invention.
In step S110, the queue length to be processed of each of the processes is obtained. In order to improve the acquisition efficiency of the queue length, a shared memory area (e.g., a queue area) may be set up for each process, where each process occupies a slot, and the slot has a number (slot number) and may store process queue information therein. Each process can update its own pending queue length to the shared queue region, thereby facilitating real-time acquisition of the queue length for each process.
At step S120, processes that have a pending queue length above or below the first threshold preempt the pending assignment request based on different rules, and at step S130, processes that have a pending queue length above the second threshold pause preempt the pending assignment request. Here, the first threshold value is lower than the second threshold value.
The introduction of the second threshold may ensure a robust execution of the requests already present in its queue by the respective process at times of traffic peaks. And the introduction of the first threshold value can allocate different preemption rules to processes with different queue lengths when the processes have the rain treatment, thereby realizing the optimization of the request acquisition opportunity by each process.
Here, the concept of a water line may be established for the request queue. The first threshold may be a low water level threshold, i.e. a low water level line, and the second threshold may be a high water level threshold, i.e. a high water level line.
When the queue length is lower than the low water level line, the system resource is idle, and all processes meeting the low water level line can freely preempt the request. That is, no preemption restrictions are imposed for processes with shorter queues to be processed. In another embodiment, the requests to be allocated may also be made to be equally allocated among processes whose queue length to be processed is smaller than the low water level threshold, for example, by further adding other thresholds to control the queue length of each process.
When the queue length is higher than the high-water line, the system resources are busy, the process rejects new requests, but still processes the requests already in the queue, even if the queue time of the requests in the queue is longer than the timeout time, so that the request results in the queue can be ensured to be stored in a cache system, the cache hit rate is improved, and the system pressure is relieved.
For the process with the length of the queue to be processed between the high and low water level thresholds, different rules of the length of the queue to be processed can be used for requesting preemption. Preferably, the pending allocation request can be preempted by a process with the pending queue length between the high and low water level thresholds and with the pending queue length rank higher than the third threshold.
The processing of processes between high and low water levels is defined based on the number of processes rather than the dimension of the queue length (although related to the queue length) by introducing a call weight parameter BatchExecutors (as a third threshold). Here, BatchExecutors may be the number of processes electing to preempt a request in one request distribution process. The BatchExecutors parameter is preferably stored in the shared memory area, or may be read in advance by processes. Each process can determine its own priority by accessing the QueueArea area and referring to batcheecutors when its queue length is between high and low water lines. When batcheecutors takes the value m, the process with the queue length between the high-level lines and the low-level lines can confirm whether the process is one of the first m processes with the shortest queue among all the processes with the queue length between the high-level lines and the low-level lines by accessing the queue area. If so, the process continues to participate in requesting preemption. If not, then not participating in preemption of new requests, only participating in the processing of requests in its own queue and updates to the QueueArea.
By introducing the scheduling parameter BatchExecutors, the number of processes participating in the request preemption can be controlled when the queue length is no longer smaller than the low-level line, thereby avoiding the overhead increase caused by the startling group effect when the system is no longer idle. Further, since this parameter can ensure that the first m processes, which are always the shortest queues, participate in preemption, it can enable relatively even distribution of requests among the processes.
Fig. 2 is a flowchart illustrating a traffic scheduling method according to another embodiment of the present invention. As shown, this method is a preferred embodiment of the traffic scheduling method of the present invention, which is set forth from a process perspective. As shown in the figure, each process 210 of the local computer can know the values of the high and low water level lines in advance, and keep the judgment of the own water level line (S220), and if the queue length is lower than the low water level line, can freely participate in requesting preemption and registering the preempted event (S230). If the queue length is higher than the high-water line, the request preemption is not participated (S240), and only the processing of the request in the queue is carried out and the queue length is updated in the shared memory area. When the queue length is located between the high and low water lines, the process needs to access the shared memory area to know whether the queue length rank of the process is the shortest before BatchExecutors compared with other processes whose queue lengths are also located between the high and low water lines (S250). If the priority ranking is forward, i.e. the queue length is one of the shortest m, the process is free to participate in process preemption. If the priority ranking is late, the process does not participate in process preemption.
In the high-performance IO business framework realized based on the scheme, the low-water-level line, the high-water-level line, the BatchExecutors and the number of processes can be dynamically set in a framework parameter configuration mode. That is, in one embodiment, at least one of the following parameters may be dynamically set based on the system configuration: a first threshold value; a second threshold value; a third threshold value; and the number of processes. Here, the high/low water line may be a parameter for characterizing the length of the pending queue, for example, the number of pending requests in the queue.
Therefore, the resource scheduling of each process can be dynamically adjusted by adjusting the configuration parameters, and various flow service scenes can be adapted. When the flow changes from a low valley to a high peak, the system scheduling resources can be effectively adjusted, the sub-process starvation state is removed, the system delay is reduced, and the single machine throughput is improved.
For example, the number of processes that can freely participate in preemption can be adjusted by appropriately setting the low water line. When the low water line is set to 1, the process can freely participate in the process preemption only when the number of the pending requests in the queue is not more than 1. In one embodiment, even the low waterline may be set to 0, i.e., process preemption may be free only if the queue is empty. In one embodiment, for example, the high water line may be set to 5, i.e., more than 5 pending requests in progress, then the new request is denied. At this time, the size of the BatchExecutors can be reasonably selected accordingly (for example, when the total number of processes is 10, the batchexecutor is set to 3), and if the queue length of all the processes is between 0 and 5, that is, the queue length of all the 10 processes is before the high and low water lines, it can be ensured that the process participating in the request preemption is always the 3 processes with the shortest queue length at this time. Thereby solving the surprise group problem well and minimizing the request latency.
The present invention, as described above, solves the scheduling efficiency problem under traffic fluctuation well by introducing high and low water lines and preferably introducing the scheduling parameters batcheeculors. In other embodiments, the present invention may also set more water lines, for example, one or more median water lines between high and low water lines, and may set different preemption and processing rules for these water lines. Therefore, the traffic scheduling method of the present invention may further include preempting the to-be-allocated request based on different rules by a process having a pending queue length higher or lower than at least one fourth threshold, where the fourth threshold is greater than the first threshold and smaller than the second threshold.
The traffic scheduling method is used for being executed under a single-machine multi-process scene. It should be understood that the multiple processes mentioned above may be multiple processes in a single machine for performing the same requested task, and in some embodiments, these multiple processes may also be referred to as multiple sub-processes, such as under the Linux system. The application of the solution of the invention in a business system will be described below in connection with fig. 3 and 4.
Fig. 3 shows an example of a business processing system. The service processing system 300 can implement the service traffic scheduling method of the present invention. It should be understood that the illustrated dispatch server 310 and plurality of service servers 320 may be part of the overall service processing system 300, in other words, the service processing system 300 may also include other portions for implementing its complete service functionality.
As shown in fig. 3, the system 300 may include a dispatch server 310 and a plurality of traffic servers 320. The dispatch server 310 may be used to distribute requests to multiple traffic servers 320. Each traffic server 320 may receive requests assigned by the scheduling server 310 and execute the assigned requests using multiple processes. The request for scheduling among the plurality of processes may be according to the traffic scheduling method of the present invention described above. Specifically, in the service server 320, requesting scheduling among a plurality of processes includes: acquiring the length of a queue to be processed of each process; enabling the process with the length of the queue to be processed higher than or lower than a first threshold value to seize the request to be distributed based on different rules; and enabling the process with the length of the queue to be processed higher than the second threshold value to pause the process of preempting the request to be distributed. Here, obtaining the length of the queue to be processed of each of the plurality of processes may include: so that each process updates its own pending queue length to the shared queue area.
The first threshold is a low water threshold, the second threshold is a high water threshold, and the traffic server 320 may be configured to: and enabling the process with the length of the queue to be processed being smaller than the low water level threshold to freely preempt the request to be distributed. Further, the service server may be configured to: and enabling the process with the queue length to be processed being higher than the third threshold to participate in the process of preempting the request to be allocated in the process with the queue length to be processed being between the high and low water level thresholds.
Further, the traffic server 320 may reject the request newly allocated by the scheduling server 310 if the pending queue length of all its processes is greater than the second threshold.
Figure 4 shows a more detailed example of a business processing system. As shown in fig. 4, the dispatch server 410 takes a number of requests from upstream and distributes them to various service servers 420 (e.g., service server 1, service server 2 … in the figure). The service server 420 (here, the service server 1 is 1) includes n processes that can be used to process requests, and is provided with a shared memory area QueueArea in which another slot is maintained for each process to update the queue length of the process in real time. Each process is provided with a scheduler, a Queue to be processed (Queue) is maintained by the scheduler, each process processes the request in the Queue, whether the request is occupied or not is determined by the flow scheduling method, and Queue information is synchronized to a shared memory area.
In another embodiment, the traffic scheduling scheme of the present invention may also be implemented as a traffic scheduling apparatus. Fig. 5 is a schematic diagram illustrating a traffic scheduling apparatus according to an embodiment of the present invention.
As shown in fig. 5, the traffic scheduling apparatus 500 may include a queue length obtaining unit 510 and a process rule setting unit 520. The queue length obtaining unit 510 may be configured to obtain a pending queue length of each of the plurality of processes. The process rule setting unit 520 may be configured to enable the process with the length of the queue to be processed being higher than or lower than the first threshold to preempt the request to be allocated based on different rules, and enable the process with the length of the queue to be processed being higher than the second threshold to pause the preemption of the request to be allocated.
Here, the first threshold is a low water level threshold, the second threshold is a high water level threshold, and the process rule setting unit 520 may be further configured to: and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed.
Preferably, the process rule setting unit 520 may be further configured to: and enabling the process with the queue length to be processed being higher than the third threshold to participate in the process of preempting the request to be allocated in the process with the queue length to be processed being between the high and low water level thresholds.
The queue length obtaining unit 510 may be further configured to: so that each process updates its own pending queue length to the shared queue area.
Fig. 6 is a schematic structural diagram of a computing device that can be used to implement the traffic scheduling method according to an embodiment of the present invention.
Referring to fig. 6, computing device 600 includes memory 610 and processor 620.
The processor 620 may be a multi-core processor or may include a plurality of processors. In some embodiments, processor 620 may include a general-purpose host processor and one or more special coprocessors such as a Graphics Processor (GPU), a Digital Signal Processor (DSP), or the like. In some embodiments, processor 620 may be implemented using custom circuitry, such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA).
The memory 610 may include various types of storage units, such as system memory, Read Only Memory (ROM), and permanent storage. Wherein the ROM may store static data or instructions for the processor 620 or other modules of the computer. The persistent storage device may be a read-write storage device. The persistent storage may be a non-volatile storage device that does not lose stored instructions and data even after the computer is powered off. In some embodiments, the persistent storage device employs a mass storage device (e.g., magnetic or optical disk, flash memory) as the persistent storage device. In other embodiments, the permanent storage may be a removable storage device (e.g., floppy disk, optical drive). The system memory may be a read-write memory device or a volatile read-write memory device, such as a dynamic random access memory. The system memory may store instructions and data that some or all of the processors require at run-time. In addition, the memory 610 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), magnetic and/or optical disks, may also be employed. In some embodiments, memory 610 may include a removable storage device that is readable and/or writable, such as a Compact Disc (CD), a digital versatile disc read only (e.g., DVD-ROM, dual layer DVD-ROM), a Blu-ray disc read only, an ultra-dense disc, a flash memory card (e.g., SD card, min SD card, Micro-SD card, etc.), a magnetic floppy disk, or the like. Computer-readable storage media do not contain carrier waves or transitory electronic signals transmitted by wireless or wired means.
The memory 610 has stored thereon executable code that, when processed by the processor 620, causes the processor 620 to perform the traffic scheduling methods described above.
The traffic scheduling method, apparatus and system according to the present invention have been described in detail above with reference to the accompanying drawings. According to the scheme, the IO resources of the system are adjusted to be in a local optimal state by means of flow scheduling of the assembly line, and the performance and robustness of the system are improved.
[ application example ]
In a server for processing a specific service, the traffic scheduling scheme of the present invention can be applied based on the following procedures.
1) The number of low water lines (LowWatermark), the number of high water lines (highWatermark), BatchExecutors and the number of processes are dynamically set in the form of frame parameter configuration.
2) And starting a program, and monitoring a port and fork subprocess. When the child process is initialized, the shared information (dictionary information and the like) of the parent process is loaded, the information of the child process is initialized, the configuration is analyzed, and the water level line information, BatchExecutors and QueueArea are set.
3) And performing request related processing in the main thread of the subprocess, checking the water level line of the subprocess, adding a request receiving event when the water level line is lower than the low water level line, and updating slot information of the process in the QueueArea.
4) With the increase of the request amount, when the water level line of a part of the sub-processes is higher than the low water level line and lower than the high water level line, the QueueArea is accessed, the number of the QueueArea is sorted (under the scene of high concurrency and large single processing delay, the processing time for sorting and positioning the priority is far lower than the queuing time of the request queue), the processing priority of the process is positioned, and if the number of the sub-processes is less than or equal to BatchExecutors, the processing event is added. Otherwise, the process is not carried out.
5) When the requests are further increased and request flooding occurs under abnormal conditions, there will be partial process requests that occur above the high water line condition. At this time, the process does not participate in the contending request state any more, and only participates in updating QueueArea, and maintains information updating.
6) When all processes reach the condition higher than the high water level line, the local processes reach the full load state, each process can reject the upstream request, and the upstream can dispatch the request to other single machines of the distributed system. The native process will continue to process the queue request even if the queue time of the request is greater than the timeout time. Therefore, the request result can be stored in the cache system, so that the cache hit rate is improved, and the system pressure is relieved.
Furthermore, the method according to the invention may also be implemented as a computer program or computer program product comprising computer program code instructions for carrying out the above-mentioned steps defined in the above-mentioned method of the invention.
Alternatively, the invention may also be embodied as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) having stored thereon executable code (or a computer program, or computer instruction code) which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the steps of the above-described method according to the invention.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, 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 and/or flowchart illustration, and combinations of blocks in the block diagrams and/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.
Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims (14)
1. A traffic scheduling method comprises the following steps:
acquiring the length of a queue to be processed of each process, wherein each process updates the length of the queue to be processed of each process to a shared queue area;
enabling the process with the length of the queue to be processed higher than or lower than a first threshold value to seize the request to be distributed based on different rules; and
processes having a pending queue length above the second threshold are caused to suspend preemption of pending allocation requests,
and the process with the queue length between the first threshold and the second threshold confirms whether the process is one of the first m processes with the shortest queue by accessing the shared queue area, if so, the process participates in the request preemption, and if not, the process does not participate in the preemption of a new request.
2. The method of claim 1, wherein the first threshold is a low water level threshold and the second threshold is a high water level threshold.
3. The method of claim 2, wherein preempting the pending requests based on different rules by the processes having pending queue lengths above or below the first threshold comprises:
and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed.
4. The method of claim 2, wherein preempting the pending requests based on different rules by the process that causes the pending queue length to be above or below the first threshold comprises:
so that the requests to be allocated are evenly allocated among processes whose queue length to be processed is less than the low water level threshold.
5. The method of claim 1, wherein preempting pending requests based on their pending queue lengths in progress between high and low water level thresholds comprises:
and enabling the process with the queue length to be processed being higher than the third threshold to participate in the process of preempting the request to be allocated in the process with the queue length to be processed being between the high and low water level thresholds.
6. The method of claim 5, wherein at least one of the following parameters is dynamically set based on the system configuration:
the first threshold value;
the second threshold value;
the value of m is selected; and
and (4) the number of processes.
7. The method of claim 1, further comprising:
the processes that make the length of the queue to be processed higher or lower than at least one fourth threshold value, which is greater than the first threshold value and less than the second threshold value, preempt the request to be allocated based on different rules.
8. A business processing system comprising:
the scheduling server is used for distributing requests to the plurality of service servers, wherein each process updates the length of the queue to be processed of the process to the shared queue area;
a plurality of service servers, each service server receiving a request assigned by the scheduling server and executing the assigned request using a plurality of processes, and scheduling the request among the plurality of processes comprising:
acquiring the length of a queue to be processed of each process;
enabling the process with the length of the queue to be processed higher than or lower than a first threshold value to seize a request to be distributed based on different rules; and
processes having a pending queue length above the second threshold are caused to suspend preemption of pending allocation requests,
and the process with the queue length between the first threshold and the second threshold confirms whether the process is one of the first m processes with the shortest queue by accessing the shared queue area, if so, the process participates in the request preemption, and if not, the process does not participate in the preemption of a new request.
9. The system of claim 8, wherein the first threshold is a low water threshold, the second threshold is a high water threshold, and the traffic server is to:
and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed.
10. The system of claim 9, wherein the traffic server rejects a request newly allocated by the scheduling server if the pending queue length of all processes is greater than a second threshold.
11. A traffic scheduling apparatus, comprising:
a queue length obtaining unit, configured to obtain respective lengths of queues to be processed of multiple processes, where each process updates its own length of the queue to be processed to the shared queue area;
a process rule setting unit configured to cause a process having a pending queue length higher or lower than a first threshold to preempt the request to be allocated based on a different rule, and cause a process having a pending queue length higher than a second threshold to suspend preemption of the request to be allocated,
and the process with the queue length between the first threshold and the second threshold confirms whether the process is one of the first m processes with the shortest queue by accessing the shared queue area, if so, the process participates in the request preemption, and if not, the process does not participate in the preemption of a new request.
12. The apparatus of claim 11, wherein the first threshold is a low water level threshold, the second threshold is a high water level threshold, and the process rule setting unit is further configured to:
and enabling the process with the length of the queue to be processed being smaller than the low water level threshold value to freely preempt the request to be distributed.
13. A computing device, comprising:
a processor; and
a memory having executable code stored thereon, which when executed by the processor, causes the processor to perform the method of any one of claims 1-7.
14. A non-transitory machine-readable storage medium having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform the method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811058687.9A CN109450803B (en) | 2018-09-11 | 2018-09-11 | Traffic scheduling method, device and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811058687.9A CN109450803B (en) | 2018-09-11 | 2018-09-11 | Traffic scheduling method, device and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109450803A CN109450803A (en) | 2019-03-08 |
| CN109450803B true CN109450803B (en) | 2022-05-31 |
Family
ID=65532544
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811058687.9A Active CN109450803B (en) | 2018-09-11 | 2018-09-11 | Traffic scheduling method, device and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109450803B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114553792B (en) * | 2020-11-25 | 2024-07-05 | 华为技术有限公司 | Scheduling parameter adjusting method, device, equipment and computer readable storage medium |
| CN113282395B (en) * | 2021-06-09 | 2024-07-02 | 中国农业银行股份有限公司 | Redis-based job request scheduling method, device, equipment and medium |
| CN114374657A (en) * | 2022-01-04 | 2022-04-19 | 京东科技控股股份有限公司 | Data processing method and device |
| CN115643309A (en) * | 2022-10-27 | 2023-01-24 | 极道科技（北京）有限公司 | Dynamic flow control method and system based on request scheduling queue length |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101369971A (en) * | 2008-10-15 | 2009-02-18 | 南京邮电大学 | Overload control method for conversation launching protocol signaling network |
| CN102096599A (en) * | 2009-12-14 | 2011-06-15 | 中国移动通信集团公司 | Multi-queue task scheduling method and related system and equipment |
| CN102223668A (en) * | 2010-04-15 | 2011-10-19 | 中兴通讯股份有限公司 | Resource seizing method for long term evolution (LTE) system during service congestion |
| EP2720422A1 (en) * | 2012-10-12 | 2014-04-16 | Telefonaktiebolaget L M Ericsson (Publ) | Queue monitoring to filter the trend for enhanced buffer management and dynamic queue threshold in 4G IP network/equipment for better traffic performance |
| CN104426800A (en) * | 2013-08-22 | 2015-03-18 | 塔塔顾问服务有限公司 | System and method for managing message queues in a peer-to-peer communication network |
| CN104854831A (en) * | 2012-12-07 | 2015-08-19 | 思科技术公司 | Output queue latency behavior for input queue based device |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9350631B2 (en) * | 2013-09-30 | 2016-05-24 | Broadcom Corporation | Identifying flows causing undesirable network events |
-
2018
- 2018-09-11 CN CN201811058687.9A patent/CN109450803B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101369971A (en) * | 2008-10-15 | 2009-02-18 | 南京邮电大学 | Overload control method for conversation launching protocol signaling network |
| CN102096599A (en) * | 2009-12-14 | 2011-06-15 | 中国移动通信集团公司 | Multi-queue task scheduling method and related system and equipment |
| CN102223668A (en) * | 2010-04-15 | 2011-10-19 | 中兴通讯股份有限公司 | Resource seizing method for long term evolution (LTE) system during service congestion |
| EP2720422A1 (en) * | 2012-10-12 | 2014-04-16 | Telefonaktiebolaget L M Ericsson (Publ) | Queue monitoring to filter the trend for enhanced buffer management and dynamic queue threshold in 4G IP network/equipment for better traffic performance |
| CN104854831A (en) * | 2012-12-07 | 2015-08-19 | 思科技术公司 | Output queue latency behavior for input queue based device |
| CN104426800A (en) * | 2013-08-22 | 2015-03-18 | 塔塔顾问服务有限公司 | System and method for managing message queues in a peer-to-peer communication network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109450803A (en) | 2019-03-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109450803B (en) | Traffic scheduling method, device and system | |
| CN106406987B (en) | Task execution method and device in cluster | |
| US8424007B1 (en) | Prioritizing tasks from virtual machines | |
| CN109697122B (en) | Task processing method, device and computer storage medium | |
| CN109564528B (en) | System and method for computing resource allocation in distributed computing | |
| US9910704B1 (en) | Run time task scheduling based on metrics calculated by micro code engine in a socket | |
| CN111258745B (en) | Task processing method and device | |
| CN105955809B (en) | Thread scheduling method and system | |
| CN109117280B (en) | Electronic device, method for limiting inter-process communication thereof and storage medium | |
| US10778807B2 (en) | Scheduling cluster resources to a job based on its type, particular scheduling algorithm,and resource availability in a particular resource stability sub-levels | |
| Bok et al. | An efficient MapReduce scheduling scheme for processing large multimedia data | |
| CN107515781B (en) | Deterministic task scheduling and load balancing system based on multiple processors | |
| WO2016202154A1 (en) | Gpu resource allocation method and system | |
| CN105022668B (en) | Job scheduling method and system | |
| CN112764904A (en) | Method for preventing starvation of low priority tasks in multitask-based system | |
| CN109117279B (en) | Electronic device, method for limiting inter-process communication thereof and storage medium | |
| CN111694669A (en) | Task processing method and device | |
| CN109729113B (en) | Method, server system and computer program product for managing dedicated processing resources | |
| WO2023071969A1 (en) | Manycore system-based task scheduling method and system, electronic device, and medium | |
| CN112860387A (en) | Distributed task scheduling method and device, computer equipment and storage medium | |
| CN111597044A (en) | Task scheduling method and device, storage medium and electronic equipment | |
| CN112925616A (en) | Task allocation method and device, storage medium and electronic equipment | |
| US20170344266A1 (en) | Methods for dynamic resource reservation based on classified i/o requests and devices thereof | |
| CN113391911B (en) | Dynamic scheduling method, device and equipment for big data resources | |
| CN113626173A (en) | Scheduling method, device and storage medium |
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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200810 Address after: 310052 room 508, floor 5, building 4, No. 699, Wangshang Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province Applicant after: Alibaba (China) Co.,Ltd. Address before: 510627 Guangdong city of Guangzhou province Whampoa Tianhe District Road No. 163 Xiping Yun Lu Yun Ping square B radio tower 13 layer self unit 01 Applicant before: Guangdong Shenma Search Technology Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: Room 554, 5 / F, building 3, 969 Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province Applicant after: Alibaba (China) Co.,Ltd. Address before: 310052 room 508, 5th floor, building 4, No. 699 Wangshang Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province Applicant before: Alibaba (China) Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |