CN108023831B - Token pool-based method for controlling service access automation closed-loop dynamic congestion - Google Patents
Token pool-based method for controlling service access automation closed-loop dynamic congestion Download PDFInfo
- Publication number
- CN108023831B CN108023831B CN201711257875.XA CN201711257875A CN108023831B CN 108023831 B CN108023831 B CN 108023831B CN 201711257875 A CN201711257875 A CN 201711257875A CN 108023831 B CN108023831 B CN 108023831B
- Authority
- CN
- China
- Prior art keywords
- token
- service
- priority
- pool
- monitor
- 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
- H04L47/215—Flow control; Congestion control using token-bucket
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a method for controlling service access automation closed loop dynamic congestion based on a token pool, which comprises the steps of firstly configuring priority parameters of service access congestion control and writing the priority parameters into a memory, then applying for distributing tokens to the token pool through a token scheduler according to a calling service ID, then completing service calling after distributing the tokens and returning the tokens to the token scheduler, and finally dynamically adjusting the service priority by a token monitor according to monitoring conditions. The invention has the advantages that: the method can effectively avoid the phenomena that the message flow bearing service is too much called to cause congestion and the message flow resources are too much occupied by individual service to cause that other services cannot distribute the message flow resources, ensure the normal response of the service calling, reduce the running risk of the system and ensure the running efficiency of the system.
Description
The technical field is as follows:
the invention relates to the technical field of computers, in particular to a method for service access automation closed-loop dynamic congestion control based on a token pool.
Background art:
in the existing enterprise service bus or application integration platform, automatic closed-loop dynamic congestion control is not performed on service access, all consumers call the service of a provider by adopting a consistent strategy, and priority control and congestion control are not performed. The access of the service is completely decided by the consumer, when more service requests with longer calling time occur, a large number of requests are blocked outside the message flow and are in a waiting state all the time, and therefore, the phenomenon that almost all the service requests passing through the message flow take too long due to the fact that a part of the requests take too long is caused. Such congestion may cause a situation similar to a breakdown of the message flow after reaching a certain critical point, that is, due to insufficient resources and resource contention, time consumption of all services may be significantly increased, resulting in situations such as slow service response and even down.
The invention content is as follows:
the technical problem to be solved by the invention is to provide a token pool-based method for controlling service access automation closed-loop dynamic congestion, which can effectively avoid congestion caused by too much message flow bearing service invocation and the phenomenon that other services cannot allocate message flow resources due to too much message flow resources occupied by individual services, ensure normal response of service invocation, reduce system operation risk and ensure system operation efficiency.
The technical solution of the present invention is to provide a method for service access automation closed loop dynamic congestion control based on a token pool, which comprises the following steps:
step 1: configuring priority parameters for service access congestion control and writing the priority parameters into a memory;
step 2: applying for distributing tokens to a token pool through a token scheduler according to the calling service ID;
and step 3: completing service calling and returning the token to the token scheduler after the token is distributed;
and 4, step 4: the token monitor dynamically adjusts the service priority based on the monitored conditions.
Preferably, according to the method for service access automation closed-loop dynamic congestion control based on the token pool of the present invention, the specific implementation method of step 1 is as follows: and configuring the priority parameter of the access congestion control of the specified service in the service registration center, and synchronizing the configuration information into an ESB memory by the service registration center in real time after the configuration is completed.
Preferably, in step 2, the token pool is divided into four virtual logical token pools according to service priority, the four virtual token pools are respectively black, gray, white and red, the priority level is sequentially higher, the tokens in the token pool of the lower level can be used by the service of the higher level, the red service does not allow automatic downgrading, the red service allows manual downgrading but only manual downgrading to the white service, the black service, the gray service and the white-red service only can be manually upgraded to the red service, and automatic downgrading or automatic upgrading can be performed between the white service and the gray service and between the gray service and the black service.
Preferably, according to the method for service access automation closed-loop dynamic congestion control based on the token pool in the present invention, in the step 2, the specific process of the token scheduler applying for allocating the token is as follows:
(1) after receiving the token application of the message flow, the token dispatcher firstly inquires the priority of the service from the token monitor, and the service priority is inquired as a synchronous calling process.
(1) And after the token scheduler inquires the service priority, applying for the token from the token pool according to the priority.
(2) The token dispatcher returns a token application result to the message flow.
(4) If the token is applied, the token scheduler sends a service definition ID and a token occupation start time to the token monitor so that the token monitor monitors the token usage.
Preferably, according to the method for service access automation closed-loop dynamic congestion control based on the token pool in the present invention, in step 3, the token returning process specifically includes the following steps:
(1) when the service call is completed, returning the token to the token scheduler, wherein the process is asynchronous call;
(2) the token monitor records the token end time to facilitate priority adjustment of the service.
Preferably, according to the method for service access automation closed-loop dynamic congestion control based on the token pool in the present invention, in step 4, the flow of dynamically adjusting the service priority by the token monitor specifically includes the following steps:
(1) the token monitor obtains from the configuration an adjustment policy for service priority.
(2) And the token monitor calculates the service needing to adjust the priority according to the statistical token occupation condition and by combining a priority adjustment strategy.
(3) And modifying the priority of the corresponding service according to the calculation result.
The invention has the beneficial effects that: the method for controlling the service access automation closed-loop dynamic congestion based on the token pool effectively avoids the phenomena that the message flow resource cannot be allocated to other services due to congestion caused by excessive message flow bearing service invocation and excessive message flow resource occupation of individual services through the way of distributing the tokens by the token scheduler, and ensures the normal response of the service invocation. Meanwhile, the token monitor can automatically monitor the resource occupation condition of the service level, dynamically adjust parameters and service priority, automatically degrade and isolate the service with excessive occupied resources, ensure that all services can obtain message stream resources in a relatively balanced manner, and reduce the running risk of the system. In some periods, services needing important guarantee can be set to be not allowed to be subjected to upgrading and downgrading and congestion control operation, and the operation efficiency of the system is guaranteed.
Description of the drawings:
FIG. 1 is a flow chart of a method for token pool based service access automation closed loop dynamic congestion control of the present invention;
FIG. 2 is a state transition diagram of four-color service priority in the present invention;
FIG. 3 is a flow chart of a token dispatcher applying for distributing tokens in the present invention;
FIG. 4 is a schematic diagram of the allocation of a four-color service token pool in the present invention;
FIG. 5 is a flow chart of token return in the present invention;
FIG. 6 is a flow chart illustrating a token monitor dynamically adjusting service priority according to the present invention.
The specific embodiment is as follows:
the method for automatic closed-loop dynamic congestion control for service access based on token pool according to the present invention is further described with reference to the accompanying drawings and specific embodiments.
As shown in fig. 1, the method for service access automation closed loop dynamic congestion control based on token pool of the present invention includes the following steps:
step 1, configuring priority parameters for service access congestion control and writing the priority parameters into a memory, wherein the specific implementation method of the step is as follows:
a priority parameter specifying access congestion control for a service is configured at the service registry, e.g. the priority parameter configuring congestion control for XX services is white. After the configuration is completed, the service registration center synchronizes the configuration information to the ESB memory in real time.
Step 2, applying for distributing tokens to a token pool according to the calling service ID through a token dispatcher, wherein the specific implementation method of the step is as follows:
the token pool is divided into four virtual logic token pools according to service priority, wherein the four virtual logic token pools are respectively black, gray, white and red, the priority is sequentially higher, and the high-level service can use the tokens in the low-level service token pool. The state transition diagram for four color service priority is shown in fig. 2:
(1) white service: normal services, most threads (threads embodied by way of tokens) may be used. All-purpose garment
The service defaults to white service at the beginning.
(2) Gray service: the deterioration early warning service has a deterioration trend and is subjected to preliminary control.
(3) Black service: degraded service, where degradation has occurred, will be tightly controlled to avoid causing congestion.
(4) Red service: the re-securing service can use all resources, which is equivalent to reserving a special thread for it.
The red service does not allow for automatic demotion, the red service allows for manual demotion but is only manually demoted to the white service, the black, gray, and white-red services are only manually promoted to the red service, and automatic demotion or promotion is possible between the white and gray services and between the gray and black services.
As shown in fig. 3, the specific flow of the token scheduler applying for distributing tokens is as follows:
1) after receiving the token application of the message flow, the token dispatcher firstly inquires the priority of the service from the token monitor, and the service priority is inquired as a synchronous calling process.
2) And after the token scheduler inquires the service priority, applying for the token from the token pool according to the priority.
3) The token dispatcher returns a token application result to the message flow.
4) If the token is applied, the token scheduler sends a service definition ID and a token occupation start time to the token monitor so that the token monitor monitors the token usage.
The performance test finds that the main resource occupied in the service calling process is the CPU time slice, and the phenomena of a large amount of overtime and blockage are caused by the contention and the locking mechanism of the CPU time slice resource. Therefore, the method can determine which services are qualified to use the CPU time slice or have higher priority to be distributed to the CPU time slice by issuing the token, thereby effectively filtering the service call blocked when overtime occurs and ensuring the effective operation of the system. The congestion control based on the token pool uses the four-color service token pool as described above, and as shown in fig. 4, the four-color service token pool is described in detail as follows:
1) all the services can be applied to the token when 0-20% of the tokens are common to the four-color services, i.e. when the token usage rate (used tokens/total number of tokens) is less than 20%. This token pool limits black services to take up to 20% of tokens, but not exclusively black tokens; 20% -40% of the service is special for gray, white and red; 40% -80% is special for white and red color services; 80% -100% is dedicated to red services, which are key protection services.
2) The four-color service respectively corresponds to four logical token pools, each token pool occupies a certain proportion, and the proportion can be dynamically configured in the running process.
3) The token pool is only limited in proportion, and the chances of obtaining tokens by each color service are equal for the same logic token pool, namely the priority of obtaining tokens by different color services in the same logic token pool is the same.
4) The high-level service may use tokens in the low-level token pool, i.e. the red token pool actually contains white
The token pool, the white token pool comprises a gray token pool, and the gray token pool comprises a black token pool.
And 3, completing service calling after the distributed tokens and returning the tokens to the token scheduler, wherein as shown in fig. 5, the specific implementation method of the step is as follows:
1) when the service call is completed, the token is returned to the token dispatcher, and the process is an asynchronous call.
2) The token monitor records the token end time to facilitate priority adjustment of the service.
Step 4, the token monitor dynamically adjusts the service priority according to the monitoring condition, as shown in fig. 6, the specific implementation method is as follows:
1) the token monitor obtains from the configuration an adjustment policy for service priority.
2) And the token monitor calculates the service needing to adjust the priority according to the statistical token occupation condition and by combining a priority adjustment strategy.
3) And modifying the priority of the corresponding service according to the calculation result.
The service upgrading and downgrading policy and the service downgrading policy may be set according to a specific actual situation, and a specific service upgrading and downgrading policy and a service upgrading policy are given below in this embodiment for reference.
a. Service degradation policy: and when the token occupation time of the service in the statistical period exceeds more than half of the corresponding token pool time of the service, the service is degraded.
For example, the following steps are carried out: if there is a gray service with a total number of message flow token pools of 100, a percentage of gray token pools of 40%, and a counting period of 120 seconds, the gray service will be downgraded to a black service if the gray service has consumed more than 100 x 40% 120 x 0.5 to 2400 seconds since the last counting period.
b. Service upgrade strategy: and when the token occupation time of the service in the statistical period exceeds 1/4 of the corresponding token pool time of the service, upgrading the service.
For example, the following steps are carried out: for the gray service in the above example, if the elapsed time is less than 100 × 40% 120 × 0.25 — 1200 seconds in the last statistical period, the service is upgraded to the white service.
The above-described embodiments are merely illustrative of the preferred embodiments of the present invention, and do not limit the scope of the present invention, and various modifications and improvements of the technical solution of the present invention may be made by those skilled in the art without departing from the spirit of the present invention, which is defined by the claims.
Claims (4)
1. A method for service access automation closed loop dynamic congestion control based on a token pool is characterized in that: the method comprises the following steps:
step 1: configuring priority parameters for service access congestion control and writing the priority parameters into a memory;
step 2: applying for distributing tokens to a token pool through a token scheduler according to the calling service ID;
and step 3: completing service calling and returning the token to the token scheduler after the token is distributed;
and 4, step 4: the token monitor dynamically adjusts the service priority according to the monitoring condition;
in the step 2, the token pool is divided into four virtual logical token pools according to service priority, the logical token pools are respectively in four colors of black, gray, white and red, the priority is sequentially higher, and the high-level service can use the tokens in the low-level service token pool, wherein the red service does not allow automatic degradation, the red service allows manual degradation but only can be manually degraded into the white service, the black service, the gray service and the white-red service can only be manually degraded into the red service, and the white service and the gray service and the black service can be automatically degraded or automatically upgraded;
in step 4, the token monitor dynamically adjusts the service priority flow as follows:
(1) the token monitor obtains the adjustment strategy of the service priority from the configuration;
(2) the token monitor calculates the service needing priority adjustment according to the counted token occupation condition and by combining a priority adjustment strategy;
(3) and modifying the priority of the corresponding service according to the calculation result.
2. The method of claim 1 for token pool based service access automation closed loop dynamic congestion control, wherein: the specific implementation method of the step 1 is as follows: and configuring the priority parameter of the access congestion control of the specified service in the service registration center, and synchronizing the configuration information into an ESB memory by the service registration center in real time after the configuration is completed.
3. The method of claim 1 for token pool based service access automation closed loop dynamic congestion control, wherein: in step 2, the specific process of the token scheduler applying for distributing tokens is as follows:
(1) after receiving a token application of a message flow, a token dispatcher inquires the priority of the service from a token monitor, and the service priority is inquired as a synchronous calling process;
(2) after the token scheduler inquires the service priority, applying for tokens to a token pool according to the priority;
(3) the token dispatcher returns a token application result to the message flow;
(4) if the token is applied, the token scheduler sends a service definition ID and a token occupation start time to the token monitor so that the token monitor monitors the token usage.
4. The method of claim 1 for token pool based service access automation closed loop dynamic congestion control, wherein: in step 3, the token return process is specifically as follows:
(1) when the service call is completed, returning the token to the token scheduler, wherein the process of returning the token to the token scheduler is asynchronous call;
(2) the token monitor records the token end time to facilitate priority adjustment of the service.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711257875.XA CN108023831B (en) | 2017-12-04 | 2017-12-04 | Token pool-based method for controlling service access automation closed-loop dynamic congestion |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711257875.XA CN108023831B (en) | 2017-12-04 | 2017-12-04 | Token pool-based method for controlling service access automation closed-loop dynamic congestion |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108023831A CN108023831A (en) | 2018-05-11 |
| CN108023831B true CN108023831B (en) | 2021-02-05 |
Family
ID=62078090
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711257875.XA Active CN108023831B (en) | 2017-12-04 | 2017-12-04 | Token pool-based method for controlling service access automation closed-loop dynamic congestion |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108023831B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110673968A (en) * | 2019-09-26 | 2020-01-10 | 科大国创软件股份有限公司 | Token ring-based public opinion monitoring target protection method |
| CN113158198A (en) * | 2020-01-22 | 2021-07-23 | 华为技术有限公司 | Access control method, device, terminal equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1589542A (en) * | 2000-11-17 | 2005-03-02 | 摩托罗拉公司 | Multiple service subflows within a cable modem service flow |
| CN101478491A (en) * | 2009-02-10 | 2009-07-08 | 中兴通讯股份有限公司 | Method and apparatus for implementing packet differential service |
| CN103823780A (en) * | 2014-03-03 | 2014-05-28 | 东南大学 | Real-time field bus controlling and dispatching method |
| US8861514B1 (en) * | 2007-09-27 | 2014-10-14 | Marvell International Ltd. | Method and apparatus for egress jitter pacer |
-
2017
- 2017-12-04 CN CN201711257875.XA patent/CN108023831B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1589542A (en) * | 2000-11-17 | 2005-03-02 | 摩托罗拉公司 | Multiple service subflows within a cable modem service flow |
| US8861514B1 (en) * | 2007-09-27 | 2014-10-14 | Marvell International Ltd. | Method and apparatus for egress jitter pacer |
| CN101478491A (en) * | 2009-02-10 | 2009-07-08 | 中兴通讯股份有限公司 | Method and apparatus for implementing packet differential service |
| CN103823780A (en) * | 2014-03-03 | 2014-05-28 | 东南大学 | Real-time field bus controlling and dispatching method |
Non-Patent Citations (1)
| Title |
|---|
| 基于动态令牌桶的卫星网络带宽分配方法;刘治国等;《计算机工程》;20160228;第42卷(第2期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108023831A (en) | 2018-05-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8782655B2 (en) | Controlling computing resource consumption | |
| US6385638B1 (en) | Processor resource distributor and method | |
| CN109936604B (en) | Resource scheduling method, device and system | |
| CN107066332B (en) | Distributed system and scheduling method and scheduling device thereof | |
| CN106897132A (en) | The method and device of a kind of server task scheduling | |
| CN105468458B (en) | The resource regulating method and system of computer cluster | |
| CN108023831B (en) | Token pool-based method for controlling service access automation closed-loop dynamic congestion | |
| JP2011501268A (en) | Hierarchical reserved resource scheduling infrastructure | |
| DE102006019839A1 (en) | Time-conscious systems | |
| US20180004456A1 (en) | Memory network to prioritize processing of a memory access request | |
| CN103532873B (en) | flow control policy applied to distributed file system | |
| KR101157041B1 (en) | System and method for dds monitoring and qos control | |
| CN109960591B (en) | Cloud application resource dynamic scheduling method for tenant resource encroachment | |
| JP7109549B2 (en) | Scheduling memory bandwidth based on service floor quality | |
| CN109582447A (en) | Computational resource allocation method, task processing method and device | |
| KR20140089749A (en) | Apparatus and method for controlling load allocation of cluster | |
| CN102622290A (en) | Process monitoring method and system | |
| CN112445615A (en) | Thread scheduling system, computer equipment and storage medium | |
| Nikolov et al. | Cloudfarm: An elastic cloud platform with flexible and adaptive resource management | |
| CN114416355A (en) | Resource scheduling method, device, system, electronic equipment and medium | |
| CN113010309B (en) | Cluster resource scheduling method, device, storage medium, equipment and program product | |
| JP2022025055A (en) | System and method for scheduling of resource-based command | |
| US20080022287A1 (en) | Method And System For Transferring Budgets In A Technique For Restrained Budget Use | |
| WO2021002961A1 (en) | Harvest virtual machine for utilizing cloud-computing resources | |
| CN101895960B (en) | Service admission control method and system |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210812 Address after: 230000 4th floor, office building, 355 Wenqu Road, high tech Zone, Hefei, Anhui Patentee after: Kedaduochuang cloud Technology Co.,Ltd. Address before: No. 355, Wenqu Road, hi tech Zone, Hefei City, Anhui Province Patentee before: USTC SINOVATE SOFTWARE Co.,Ltd. |
|
| TR01 | Transfer of patent right |