CN115225580A

CN115225580A - Service isolation speed limiting method and device for multiple processor cores

Info

Publication number: CN115225580A
Application number: CN202210658279.7A
Authority: CN
Inventors: 杨峰明; 徐永健; 肖立美; 黄保华; 张哲瑜
Original assignee: Sina Technology China Co Ltd
Current assignee: Sina Technology China Co Ltd
Priority date: 2022-06-10
Filing date: 2022-06-10
Publication date: 2022-10-21
Anticipated expiration: 2042-06-10
Also published as: CN115225580B

Abstract

The embodiment of the invention provides a method and a device for limiting the speed of a multi-processor core by service isolation.A local token cache is established in each processor core according to a service type, when a service message reaches the processor core, each processor core firstly obtains a token in the local token cache of the processor core corresponding to the service type, so that the access times of a global token bucket are reduced, and the blocking caused by the lock competition of the global token bucket is avoided; meanwhile, a global token bucket shared by all processor cores is established on a global level, the number of tokens of the global token bucket is set according to the requirement of the service type, and the purpose of limiting the speed according to the service type is achieved.

Description

Service isolation speed limiting method and device for multiple processor cores

Technical Field

The invention relates to the field of service isolation speed limit, in particular to a service isolation speed limit method and device for a multi-processor core.

Background

The most widely used current load balancing application is DPVS, which is a multi-core high-performance four-layer load balancing forwarding system, but in practical application, a large number of services exist, if some services are attacked, system resources are exhausted, other service services are affected, and therefore, the services need to be isolated by resources; the speed limiting module of the DPVS is an independent module TC, and the module has no connection with the service, so that a splitter and a scheduler need to be configured independently. The shunt, namely the message matching rule set, and the scheduler, namely the scheduler, carry out scheduling according to the speed limiting parameters. The services need to be matched in order according to the configured distribution rule. The principle of the speed limit of the load by the TC module of the DPVS is as follows: under a queue for message scheduling, messages are compared in sequence by one rule through a flow divider until the rules are completely matched, and then a scheduler arranged in the matched rules is used for carrying out speed-limiting operation on the messages. If the comparison is not completely matched for 8 times at the same time, the packet is directly discarded.

In the process of implementing the invention, the applicant finds that at least the following problems exist in the prior art:

under a large amount of services, the speed limit of a TC module of the DPVS is low in matching efficiency due to the fact that a plurality of shunt matching rule entries exist, and meanwhile, the matching times are limited; the requirement of respectively limiting the speed of a large number of services can not be met.

Disclosure of Invention

The embodiment of the invention provides a service isolation speed-limiting method and device for a multi-processor core, which solve the problem that the prior art cannot meet the requirement that a large number of services are respectively limited in speed according to service types.

To achieve the above object, in one aspect, an embodiment of the present invention provides a method for limiting a speed of a service isolation for multiple processor cores, including:

aiming at each processor core, determining the service type of the service message according to the message information of the service message received by the processor core;

checking whether a global token bucket corresponding to the service type is valid;

if the global token bucket corresponding to the service type is invalid, discarding the service message of the service type before the global token bucket corresponding to the service type is updated next time;

if the global token bucket corresponding to the service type is valid, further checking the validity and the number of local tokens in a local token cache corresponding to the processor core and used for the service type;

if the validity of the local token is checked to be valid and the number of the local tokens is larger than or equal to the number of the required tokens of the service message, consuming tokens which are consistent with the number of the required tokens in a local token cache corresponding to the processor core and used for the service type, and releasing the service message; if not, then,

obtaining tokens from a global token bucket corresponding to the service type, updating the actually obtained tokens to a local token cache corresponding to the processor core and used for the service type to obtain the updated token quantity of the local token cache corresponding to the processor core and used for the service type, and processing the service message based on the updated token quantity;

the global token bucket is a preset token bucket which is shared by multiple processor cores and corresponds to the service type; the total number of tokens in each global token bucket in unit time is respectively set according to a speed limit requirement preset by a service type corresponding to the global token bucket, and the tokens in the global token bucket are updated by taking the unit time as a period.

Further, the checking whether the global token bucket corresponding to the service type is valid includes:

checking whether the validity identification of the global token bucket corresponding to the service type is valid; the validity mark is set to be valid when the global token bucket corresponding to the service type is updated each time;

the processing the service packet based on the updated token number specifically includes:

if the updated token number is larger than a preset critical token number threshold value, consuming tokens in a local token cache corresponding to the processor core and used for the service type, and releasing the service message; the threshold value of the critical token number is smaller than the number of the required tokens of the service message;

and if the updated token number is less than or equal to the threshold value of the critical token number, discarding the service message, and updating the validity identification of the global token bucket corresponding to the service type to be invalid.

Further, the obtaining tokens from the global token bucket corresponding to the traffic type and updating the actually obtained tokens to the local token cache corresponding to the processor core and used for the traffic type includes:

if the validity of the local token is invalid, clearing the local token cache which is corresponding to the processor core and is used for the service type; further, obtaining tokens from a global token bucket corresponding to the service type according to the expected number of obtained tokens of the local token cache corresponding to the processor core and used for the service type, and adding the actually obtained tokens to the local token cache corresponding to the processor core and used for the service type;

and if the validity of the local token is valid and the number of the local tokens is less than the number of the required tokens of the service message, obtaining tokens from a global token bucket corresponding to the service type according to the expected number of the obtained tokens of the local token cache corresponding to the processor core and used for the service type, and adding the actually obtained tokens to the local token cache corresponding to the processor core and used for the service type.

Further, the obtaining tokens from the global token bucket corresponding to the traffic type according to the expected number of obtaining tokens of the local token cache corresponding to the processor core for the traffic type includes:

if the current token quantity in the global token bucket corresponding to the service type meets the expected acquisition token quantity, acquiring tokens in the global token bucket corresponding to the service type, wherein the tokens are consistent with the expected acquisition token quantity;

and if the current token quantity in the global token bucket corresponding to the service type does not meet the expected token obtaining quantity, obtaining all tokens in the global token bucket corresponding to the service type.

Further, if the updated number of tokens is greater than a preset threshold value of the number of critical tokens, consuming tokens in a local token cache corresponding to the processor core and used for the service type, and releasing the service packet includes:

if the updated token number is larger than or equal to the required token number of the service message, consuming tokens which are consistent with the required token number and are in the local token cache corresponding to the processor core and used for the service type, and releasing the service message;

and if the updated token number is less than the required token number of the service message and greater than the threshold value of the critical token number, consuming all tokens in a local token cache corresponding to the processor core and used for the service type, and releasing the service message.

On the other hand, an embodiment of the present invention provides a service isolation speed limiting device for multiple processor cores, including:

a service type determining unit, configured to determine, for each processor core, a service type of the service packet according to packet information of the service packet received by the processor core;

a global token bucket checking unit, configured to check whether a global token bucket corresponding to the service type is valid;

the first message filtering unit is used for discarding the service message of the service type before the global token bucket corresponding to the service type is updated next time if the global token bucket corresponding to the service type is invalid;

the local cache checking unit is used for further checking the validity of local tokens and the number of the local tokens in the local token cache corresponding to the processor core and used for the service type if the global token bucket corresponding to the service type is valid; if the validity of the local token is checked to be effective and the number of the local tokens is larger than or equal to the number of the required tokens of the service message, triggering the second message filtering unit, otherwise, triggering the local cache updating and message filtering unit;

a second message filtering unit, configured to consume tokens, of which the number is consistent with that of the demand tokens, in a local token cache for the service type corresponding to the processor core, and pass the service message;

a local cache updating and message filtering unit, configured to obtain a token from a global token bucket corresponding to the service type, update an actually obtained token into a local token cache for the service type corresponding to the processor core, obtain an updated token number of the local token cache for the service type corresponding to the processor core, and process the service message based on the updated token number;

Further, the global token bucket checking unit is specifically configured to: checking whether the validity identification of the global token bucket corresponding to the service type is valid; the validity mark is set to be valid when the global token bucket corresponding to the service type is updated each time;

the local cache updating and message filtering unit comprises:

a first message filtering module, configured to consume a token in a local token cache for the service type corresponding to the processor core and release the service message if the updated token number is greater than a preset threshold of the critical token number; the threshold value of the critical token quantity is smaller than the quantity of the required tokens of the service message;

and the second message filtering module is used for discarding the service message and updating the validity identifier of the global token bucket corresponding to the service type to be invalid if the updated token number is less than or equal to the threshold value of the critical token number.

Further, the local cache updating and message filtering unit includes:

a first local cache updating module, configured to empty a local token cache for the service type corresponding to the processor core if the validity of the local token is invalid; further, triggering a third local cache updating module;

the second local cache updating module is used for directly triggering a third local cache updating module if the validity of the local token is valid and the number of the local tokens is less than the number of the required tokens of the service message;

and the third local cache updating module is used for acquiring tokens from a global token bucket corresponding to the service type according to the expected number of acquired tokens of the local token cache corresponding to the processor core and used for the service type, and adding the actually acquired tokens to the local token cache corresponding to the processor core and used for the service type.

Further, the third local cache updating module is specifically configured to:

if the current token quantity in the global token bucket corresponding to the service type meets the expected acquisition token quantity, acquiring tokens in the global token bucket corresponding to the service type, wherein the tokens are consistent with the expected acquisition token quantity; and if the current token quantity in the global token bucket corresponding to the service type does not meet the expected token obtaining quantity, obtaining all tokens in the global token bucket corresponding to the service type.

Further, the first packet filtering module includes:

the message filtering module is used for consuming tokens which are consistent with the required token number in the local token cache corresponding to the processor core and used for the service type and release the service message if the updated token number is larger than or equal to the required token number of the service message;

and the token-deficient message filtering module is used for consuming all tokens in the local token cache corresponding to the processor core and used for the service type and releasing the service message if the updated token number is less than the required token number of the service message and greater than the threshold value of the critical token number.

The technical scheme has the following beneficial effects: the method comprises the steps of establishing a local token cache according to the service type at each processor core, when a service message reaches the processor cores, firstly, obtaining tokens by the processor cores through the local token caches at the processor cores corresponding to the service types, so that the access times of a global token bucket are reduced, meanwhile, establishing the global token bucket shared by all the processor cores at the global level, and setting the token quantity of the global token bucket according to the requirements of the service types, so that the purpose of speed limitation according to the service types is realized, and meanwhile, avoiding frequent access of the global token bucket by the processor cores through establishing the local cache at the processor cores, so that the blockage caused by lock competition of the global token bucket is avoided, the effect of respectively limiting the speed according to the service types based on multiple processor cores is achieved, and the effect that the whole speed limiting system can stably run when processing a large number of service speed limitation isolations is ensured.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a flowchart of a traffic isolation speed limiting method for multiple processor cores according to one embodiment of the present invention;

FIG. 2 is an architecture diagram of a traffic isolation speed limiter for multiple processor cores according to one embodiment of the present invention;

FIG. 3 is a diagram illustrating a mapping relationship between a multi-processor core, a service type and a global token bucket according to an embodiment of the present invention;

fig. 4 is another flowchart of a traffic isolation speed limiting method for multiple processor cores according to one embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

On one hand, as shown in fig. 1, an embodiment of the present invention provides a method for limiting a speed of a service isolation for multiple processor cores, including:

step S100, aiming at each processor core, determining the service type of the service message according to the message information of the service message received by the processor core;

step S101, checking whether a global token bucket corresponding to the service type is valid; if not, namely the global token bucket corresponding to the service type is invalid, executing step S102, and if yes, namely the global token bucket corresponding to the service type is valid, executing step S103;

step S102, before the global token bucket corresponding to the service type is updated next time, discarding the service message of the service type;

step S103, further checking the validity and the number of local tokens in the local token cache corresponding to the processor core and used for the service type;

step S104, judging whether the validity of the local token is valid and the number of the local tokens is more than or equal to the number of the required tokens of the service message; if yes, namely the validity of the local token is valid and the number of the local tokens is greater than or equal to the number of the required tokens of the service message, executing a step S105, otherwise, executing a step S106;

step S105, consuming tokens with the same quantity as the required tokens in a local token cache corresponding to the processor core and used for the service type, and releasing the service message;

step S106, obtaining tokens from the global token bucket corresponding to the service type, and updating the actually obtained tokens to the local token cache corresponding to the processor core and used for the service type to obtain the updated token quantity of the local token cache corresponding to the processor core and used for the service type; processing the service message based on the updated token number;

the global token bucket is a preset token bucket which is shared by multiple processor cores and corresponds to the service type; the total number of tokens in each global token bucket in unit time is respectively set according to the speed limit requirement preset by the service type corresponding to the global token bucket, and the tokens in the global token bucket are updated by taking the unit time as a period.

In some embodiments, each processor core may receive a traffic packet of one or more traffic types, and within a local access range of each processor core, a local token cache for each traffic type that may be received by the processor core is respectively established for the traffic type; a global token bucket corresponding to the traffic type is set separately for each traffic type that may occur, within a range accessible to all processors. A local token cache for a certain traffic type can only obtain tokens from the global token bucket corresponding to that traffic type. The local token cache is a cache configured locally for each processor core in advance for caching tokens. Each processor core can receive at least one type of service message, and a local token cache with a specified local cache size is configured for each type of service in advance in the local part of the processor core. The tokens in the local token cache come from a global token bucket corresponding to the same service type; the global token bucket is a token bucket which is configured in a global scope in advance and is shared by all the processor cores; and the global token buckets are respectively configured according to the service types, and if there are several service types, the global token buckets are correspondingly configured. The maximum token number of each global token bucket is respectively determined according to the speed limit requirement specified by the service type corresponding to the global token bucket, namely the maximum token number of each global token bucket can be respectively set and can be set to be the same or different, so that the aim of respectively limiting the speed of the service message of each service type is fulfilled. By setting a local token cache for each service type of each processor core and setting a corresponding shared global token cache for all the processor cores according to the service types, when a token is available in the local token cache corresponding to the service type, the processor core directly obtains the token from the local token cache when processing a service message of the service type without accessing a global token bucket corresponding to the service type, thereby avoiding global token bucket blocking caused by processing a large number of services by a plurality of processor cores to a certain extent and improving the stability of the system. The global token bucket is updated according to a specified token updating period, the token generated in one token updating period is valid only in the token updating period, and when the system time exceeds the token updating period along with the lapse of the system time, the token generated in the token updating period is regarded as invalid, so that the release amount of the service message in each token updating period can be limited through the mechanism. Step S100, determining the service type of the service message according to the message information of the service message received by the processor core; the message information of the service message includes but is not limited to information such as a protocol number, a destination IP address and/or a port, and when the service message is classified, the message information of the service message can be matched with preset classification matching items one by one; each classified matching item corresponds to a service type, and each matching item contains a specific value of the interested service message information; preferably, hash can be performed on the message information of the service message to obtain an index value, and the service type of the service message is retrieved according to the obtained index value; the method can determine the service type through one-time calculation without matching a plurality of classification matching items one by one, thereby improving the efficiency of determining the service type. Step S101, checking whether a global token bucket corresponding to the service type is valid; the service message is divided into various different service types, and a corresponding global token bucket is set for each service type, wherein the number of the service types is the number of the corresponding global token buckets; when a service message of a certain service type is processed, a token can be obtained only from a global token bucket corresponding to the service type or a local token cache used for the service type and corresponding to a processor core processing the service message; the aim of limiting the speed of the service message respectively according to the service type can be achieved by respectively setting the updated token quantity in unit time of each global token bucket; when there is no token in the global token bucket or there are remaining tokens, but the remaining tokens have failed, the global token bucket is considered to be invalid, that is, step S102 needs to be executed, and all messages received before the global token bucket is updated next time need to be discarded. If the global token bucket is valid, step S103 is executed to obtain the validity of the local token and the number of the local tokens in the local token cache for the service type corresponding to the processor core, and further step S104 is executed to check whether the validity of the local token is valid and the number of the local tokens is greater than or equal to the required token number of the service packet, because an asynchronous relationship exists between the local token cache and the global token cache, the token cached in the local token cache may be a token that has not been used up in a previous token update cycle, and in the current token update cycle, the token cached in the local token cache may be invalid, for example, by checking the token update time in the local token cache, it is found that the token does not belong to the time range corresponding to the current token update cycle, the token in the local token cache may be considered invalid, otherwise, if the update time of the token in the local token cache is within the time range corresponding to the current token update cycle, the token in the local token cache is considered to be valid. When the token in the local token cache is valid, the number of tokens in the local token cache needs to be checked to determine whether the token in the local token cache is sufficient for the current service packet to be consumed. When the global token bucket is valid, it is indicated that the service message of the service type has available tokens, at this time, it is determined whether the local token cache has enough available tokens, if the local token cache corresponding to the processor core and used for the service type has tokens with the quantity enough for the required tokens of the service message, the token can be directly obtained from the local token cache and the service message is released, that is, step S105 is executed, thereby reducing the number of times of obtaining tokens from the global token bucket and remarkably reducing competition between the processor cores when accessing the global token bucket; if the number of valid local tokens in the local token cache for the service type corresponding to the processor core that receives the service packet is less than the number of required tokens of the service packet, the processor core attempts to acquire a token from the global token bucket corresponding to the service type, adds the acquired token to the local token cache for the service type corresponding to the processor core, and performs step S106 by processing the release or discard of the service packet based on the updated number of tokens. The method for determining the number of the required tokens of the service message includes but is not limited to pre-specifying according to the service type of the service message or dynamically calculating according to the message information of the service message; for example, the number of tokens required for a service packet may be determined according to the number of bytes of the service packet, one byte or a specified number of bytes may correspond to one token, and one or more tokens may also correspond to one packet as a unit. When obtaining tokens from the global token bucket and adding the tokens to the local token cache, removing the tokens taken out of the global token bucket from the global token bucket, for example, if there are 100 tokens in the global token bucket and 10 tokens obtained this time are added to the local token cache, then there are 90 tokens left in the global token bucket; it will also be appreciated that tokens consumed in the local token cache are also removed from the local token cache.

The embodiment of the invention has the following technical effects; the method comprises the steps of establishing a local token cache according to the service type at the local part of each processor core, obtaining tokens by the local token cache of the processor core corresponding to the service type when a service message reaches the processor core, reducing the access times of a global token bucket, establishing the global token bucket shared by all the processor cores and corresponding to each service type at the global level, setting the number of the tokens of the global token bucket corresponding to the service type according to the requirements of the service type, realizing the purpose of limiting the speed according to the service type, avoiding access conflicts caused by accessing the global token bucket frequently by each processor and by establishing the local cache at the local part of each processor core, avoiding the blockage of the global token bucket, limiting the speed according to the service type based on multiple processor cores, and ensuring that the whole speed limiting system can stably run when processing a large number of service isolations.

In some embodiments, invalidation of the global token bucket may include exhaustion of tokens in the global token bucket and/or expiration of tokens in the global token bucket; the tokens in the global token bucket are exhausted, that is, the tokens generated in the current token updating period (that is, the current unit time) when the global token bucket corresponding to the service type is found are exhausted; the method comprises the following steps that when a token in a global token bucket is expired, namely a critical state of the current unit time is entered from the last unit time, and before updating for the global token bucket is executed, the rest unused token in the global token bucket or updated in the last unit time is considered as an expired token in the current unit time; a validity flag may be set for each global token bucket, the validity flag being set invalid when the global token bucket is exhausted, and the validity flag being set valid when the global token bucket is updated. Boolean values or other types of values may be used for validity indications to indicate validity and invalidity, respectively; preferably, time may be used as a value of the validity flag, in some specific embodiments, when a global token bucket corresponding to a certain service type has no token available, the validity flag corresponding to the global token bucket may be set to be a current time, when it is checked whether the global token bucket corresponding to the service type is valid, specifically, by determining whether a time recorded by the validity flag corresponding to the global token bucket belongs to a current unit time, if the time belongs to the current unit time, the global token bucket is considered to be invalid; since the system time is automatically lapsed, and the time of the validity flag record does not naturally belong to the next unit time after the global token bucket is updated in the next unit time, it is equivalent to using the automatic lapsing of the system time to automatically mark the global token bucket as valid when the global token bucket is updated. When a processor core processes a service message of the service type each time, firstly checking the validity identification of the global token bucket corresponding to the service type, and if the validity identification is invalid, discarding the service message belonging to the service type and received before the next update of the global token bucket corresponding to the service type. Therefore, the situation that the service message still accesses the global token bucket every time when the token is exhausted is avoided, and further a large amount of accesses to the global token bucket are avoided. Judging whether the moment recorded by the validity identifier belongs to the current unit time or not, considering the moment recorded by the validity identifier and the precision of the unit time, for example, the unit time is 1 second, and the minimum precision of the moment recorded by the validity identifier is also 1 second, if the moment recorded by the validity identifier is equal to the current unit time, the moment recorded by the validity identifier is considered to belong to the current unit time, otherwise, the moment recorded by the validity identifier does not belong to the current unit time; for another example, if every 10 seconds is taken as a unit time, the time of the validity flag record is considered to belong to the current unit time if the corresponding time on the time axis is within the time range covered by the unit time of 10 seconds.

The threshold value of the critical token number is smaller than the number of the required tokens of the service message; the threshold value of the number of critical tokens can be flexibly set according to specific requirements.

When the updated token number is less than or equal to the threshold value of the critical token number, too few tokens are in the local token cache corresponding to the processor core which is processing the service message and used for the service type of the service message, and the service message cannot be allowed to pass through, so the service message is discarded.

If the updated token number is greater than the preset threshold value of the critical token number, the service packet may be released, and the token in the local token cache for the service type of the service packet corresponding to the processor core that is processing the service packet is consumed, where the specific number of the consumed token may be the minimum value between the updated token number and the required token number of the service packet.

Preferably, the threshold of the critical token number is set to 0, and after the global token bucket corresponding to the service type of the service packet being processed is updated, if the number of the new tokens is less than or equal to the threshold of the critical token number (at this time, 0), that is, the number of the tokens in the local token cache for the service type corresponding to the processor core processing the service packet is 0, it indicates that both the global token bucket and the local token cache have no token available, and the service packet needs to be discarded.

If the updated token number is greater than a preset threshold token number (0 at this time), the service packet may be released, and a token in a local token cache for the service type of the service packet corresponding to a processor core that is processing the service packet is consumed, where the specific number of consumed tokens may be a minimum value of the updated token number and a required token number of the service packet.

The embodiment of the invention has the following technical effects: by setting validity identification for the global token bucket corresponding to each service type and checking the validity identification before processing the service message corresponding to the service type, a large number of attempts to acquire tokens from the global token bucket when the global token bucket corresponding to the service type is empty can be avoided, so that the global token bucket is prevented from being blocked; furthermore, the validity identification is set by using the current time, the characteristic that the system time line automatically passes in the future is fully utilized, and the validity identification does not need to be specially set when the global token bucket is updated, so that the operation complexity of the token validity identification is simplified, and the structure of a program is simplified.

The expected token obtaining quantity is larger than the required token quantity of all the service messages, so that when the token of the global token bucket is sufficient, the token supplemented from the global token bucket to the local token cache is ensured to be enough for the current service message to be consumed; in addition, on the basis that the number of expected tokens is greater than the number of tokens required by all service messages, the number of expected tokens is reasonably determined according to the number of processor cores and the total number of tokens in the global token bucket, that is, it is necessary to ensure that the processor cores reduce the number of times of accessing the global token bucket, and it is also necessary to ensure that the tokens in the global token bucket corresponding to the corresponding service type are allocated to the local token caches of the corresponding service types in the processor cores in a more reasonable manner, so that the phenomenon that the number of cached tokens obtained by some processor cores is too large, which causes other processor cores not to obtain enough tokens is avoided.

In some embodiments, after receiving a service packet and determining a service type of the service packet, a certain processor core determines that a global token bucket corresponding to the service type is valid, and further, checks validity of local tokens and the number of local tokens in a local token cache corresponding to the processor core and used for the service type; because the tokens in the local token cache for the service type come from the global token bucket corresponding to the same service type, and the tokens in the global token bucket are updated in a cycle of unit time, when the token in the local token cache is found to be the token in the last unit time period in the current unit time, it indicates that the token in the local token cache is invalid, and at this time, the validity of the local token in the local token cache for the service type corresponding to the processor core is invalid. If the token in the local token cache is found to be the token in the current unit time, the token in the local token cache is valid, and whether the number of the tokens meets the requirement can be further checked.

If the validity of the local token in the local token cache corresponding to the processor core for processing the service message and used for the service type of the service message is invalid, the token in the local token cache is not available, the local token cache needs to be cleared, further tokens are obtained from the global token cache corresponding to the service type according to the expected number of the obtained tokens, and the actually obtained tokens are added into the local token cache.

If the validity of the local token in the local token cache corresponding to the processor core currently processing the service message and used for the service type of the service message is valid and the number of the local tokens is smaller than the number of the required tokens of the service message, it indicates that the token in the local token cache is valid, but the number of the local tokens is not enough than the number of the required tokens of the service message, that is, the token in the local token cache is not enough, the token needs to be obtained from the global token cache corresponding to the service type according to the expected number of the tokens, and the actually obtained token is added to the local token cache.

In some embodiments, an upper limit token number of a local token cache may be specified, when obtaining a local token cache for a certain traffic type from a global token bucket corresponding to the traffic type for supplementing tokens, a difference between the upper limit token number of the local token cache and a number of currently remaining valid tokens in the local token cache is calculated first, and a token is obtained from the global token bucket by taking the difference as an expected obtaining token number, where at this time, the number of tokens obtained from the global token bucket each time may be the same or different, and is related to the number of remaining valid local tokens in the local token bucket.

In other embodiments, a preset expected total amount of tokens may be used as the expected number of tokens to be obtained, and when obtaining a local token cache for a certain service type from a global token bucket corresponding to the service type in addition to the tokens to be obtained, the tokens are obtained from the global token bucket according to the expected number of tokens to be obtained (i.e., the expected total amount of tokens at this time), and the actually obtained tokens are added to the local token cache. At this time, the local token cache may not set the upper limit of the number of tokens, so that the total number of tokens to be expected will not overflow after being accumulated with the original remaining tokens in the local token cache. In some embodiments, a token number upper limit may also be set for the local token cache, and in order to avoid overflow of the token number stored in the local token cache, the tokens acquired from the global token bucket may be cached in a temporary variable, and after the temporary variable and the tokens in the current local token cache are consumed according to the required token number of the message being currently processed, the remaining tokens in the temporary variable may be added to the local token cache.

The embodiment of the invention has the following technical effects: the current available tokens are acquired from the global token bucket to the maximum extent by taking the expected acquired token number as the maximum extent, so that the time for the processor core to use the local token cache is prolonged as much as possible, the processing capacity of the processor core is fully utilized, and the frequency of frequently accessing the global token bucket is reduced as much as possible.

if the current token quantity in the global token bucket corresponding to the service type meets the expected token obtaining quantity, obtaining tokens in the global token bucket corresponding to the service type, wherein the tokens are consistent with the expected token obtaining quantity;

In some embodiments, since the number of tokens remaining in the global token bucket corresponding to the service type of the currently processed service packet may be greater than, less than, or equal to the expected number of tokens to be obtained, when the number of tokens remaining in the global token bucket is greater than or equal to the expected number of tokens to be obtained, the number of actually obtained tokens is consistent with the expected number of tokens to be obtained, and if the number of tokens remaining in the global token bucket is less than the expected number of tokens to be obtained, all tokens in the global token bucket are taken out and added to a corresponding local token cache.

Further, if the updated token number is greater than a preset threshold token number, consuming tokens in a local token cache corresponding to the processor core and used for the service type, and releasing the service packet includes:

In some embodiments, when the updated number of tokens in the local token cache is greater than or equal to the required number of tokens of the service packet, it indicates that there are enough tokens for the service packet to use, so that the tokens in the local token cache are consumed according to the required number of tokens, and the service packet is released;

when the updated token number in the local token cache is smaller than the required token number of the service message, it indicates that after the token is supplemented to the local token cache from the global token bucket corresponding to the service type this time, the token in the global token bucket corresponding to the service type in the time range corresponding to the current token updating period is exhausted, but the token number in the local token cache after the token is supplemented is still not enough for the service message, but because the condition only occurs when the corresponding global token bucket is exhausted, in order to maintain the consistency between the local token cache and the global token bucket, the service message processed in the critical state is still released, and all the tokens in the local token cache are consumed; when the next service message of the same service type arrives, the local token cache is empty, the global token bucket is triggered to be accessed, the global token bucket is also empty, so that an invalid identifier of the global token bucket is established, the next service message is discarded, and meanwhile, the subsequent service message which arrives is discarded in the updating period of the global token bucket. Therefore, the service processing capacity of the processor core is fully utilized, and the service message of the service type which subsequently reaches the processor core in the token updating period is discarded when the global token bucket corresponding to the service type does not have available messages, so that the effect of limiting the speed is achieved.

On the other hand, as shown in fig. 2, an embodiment of the present invention provides a traffic isolation speed limiting device for multiple processor cores, including:

a service type determining unit 200, configured to determine, for each processor core, a service type of the service packet according to packet information of the service packet received by the processor core;

a global token bucket checking unit 201, configured to check whether a global token bucket corresponding to the service type is valid;

a first packet filtering unit 202, configured to discard the service packet of the service type before the global token bucket corresponding to the service type is updated next time if the global token bucket corresponding to the service type is invalid;

a local cache checking unit 203, configured to further check, if the global token bucket corresponding to the service type is valid, the validity of local tokens and the number of local tokens in a local token cache corresponding to the processor core and used for the service type; if the validity of the local token is checked to be valid and the number of the local tokens is greater than or equal to the number of the required tokens of the service packet, triggering the second packet filtering unit 204, otherwise, triggering the local cache updating and packet filtering unit 205;

a second packet filtering unit 204, configured to consume tokens, of which the number is consistent with that of the demand tokens, in a local token cache for the service type corresponding to the processor core, and pass the service packet;

a local cache updating and message filtering unit 205, configured to obtain a token from the global token bucket corresponding to the service type, update the actually obtained token into the local token cache corresponding to the processor core and used for the service type, obtain an updated token number of the local token cache corresponding to the processor core and used for the service type, and process the service message based on the updated token number;

Further, the global token bucket checking unit 201 is specifically configured to: checking whether the validity identification of the global token bucket corresponding to the service type is valid; the validity mark is set to be valid when the global token bucket corresponding to the service type is updated each time;

the local cache updating and packet filtering unit 205 includes:

a first message filtering module, configured to consume a token in a local token cache for the service type corresponding to the processor core if the updated token number is greater than a preset critical token number threshold, and release the service message; the threshold value of the critical token number is smaller than the number of the required tokens of the service message;

Further, the local cache updating and packet filtering unit 205 includes:

Further, the third local cache updating module is specifically configured to:

if the current token quantity in the global token bucket corresponding to the service type meets the expected token obtaining quantity, obtaining tokens in the global token bucket corresponding to the service type, wherein the tokens are consistent with the expected token obtaining quantity; and if the current token quantity in the global token bucket corresponding to the service type does not meet the expected token quantity, acquiring all tokens in the global token bucket corresponding to the service type.

Further, the first packet filtering module includes:

The embodiment of the invention has the following technical effects: the method comprises the steps of establishing a local token cache according to the service type at each processor core, when a service message reaches the processor cores, firstly, obtaining tokens by the processor cores through the local token caches at the processor cores corresponding to the service types, so that the access times of a global token bucket are reduced, meanwhile, establishing the global token bucket shared by all the processor cores at the global level, and setting the token quantity of the global token bucket according to the requirements of the service types, so that the purpose of speed limitation according to the service types is realized, and meanwhile, avoiding frequent access of the global token bucket by the processor cores through establishing the local cache at the processor cores, so that the blockage caused by lock competition of the global token bucket is avoided, the effect of respectively limiting the speed according to the service types based on multiple processor cores is achieved, and the effect that the whole speed limiting system can stably run when processing a large number of service speed limitation isolations is ensured.

The embodiments of the service isolation speed-limiting device for multiple processor cores provided in the embodiments of the present invention are embodiments corresponding to the aforementioned service isolation speed-limiting methods for multiple processor cores in a one-to-one manner, and the embodiments of the service isolation speed-limiting device for multiple processor cores can be understood according to the foregoing description of the embodiments of the service isolation speed-limiting methods for multiple processor cores, and are not described herein again.

The above technical solutions of the embodiments of the present invention are described in detail below with reference to specific application examples, and reference may be made to the foregoing related descriptions for technical details that are not described in the implementation process.

The service isolation of the embodiment of the invention adds the speed limit configuration aiming at the service level, and adopts an improved token bucket mode to limit the speed and isolate, wherein the token bucket takes the service as a unit, and the same service among multiple cores shares the same token bucket. The shunting and speed limiting of the embodiment of the invention do not adopt a mode of a TC module in DPVS.

The speed limit of the split service message is realized by sequentially passing through token buckets, as shown in fig. 3, wherein core1, core2 and core3 represent 3 processor cores, and the service 1 token bucket, the service 2 token bucket and the service 3 token bucket respectively represent a global token bucket corresponding to the service type 1, a global token bucket corresponding to the service type 2 and a global token bucket corresponding to the service type 3. Each processor core can receive service messages of different service types, the speed limit is distinguished according to the service types, each service type is associated with an independent global token bucket, and the same service is subjected to speed limit through the same global token bucket.

Aiming at a multi-processor core service forwarding system, the competition of obtaining tokens among multiple cores is prevented, and the local token cache of each processor core is increased, namely when a token is taken from a global token bucket, the token can be taken according to the set local token cache size and is placed in the local token cache, and the cache number is recorded as cache _ tokens; the token for subsequent message processing is consumed only by caching from the local token, so that frequent shared memory competition caused by the fact that each message requests the global token bucket is avoided. The token validity period of the local token cache is only at this time, the time is recorded as cache _ update _ time (unit: second), the next time is invalid (namely, the token in the global token bucket is updated once per second), and the global token bucket needs to be moved again to request the token cache.

At a certain moment, the token cannot be taken from the global token bucket, which indicates that the token in the second is consumed, and then the subsequent messages in the second are discarded without requesting the token; this time is denoted drop time (units: seconds), preventing each message from requesting shared global token bucket cost performance in the event that the token is exhausted at the current time.

And updating the token of the global token bucket, namely calculating the difference between the current time curr _ time (unit: second) and the time tokens _ update _ time (unit: second) of the last token updating when the token is acquired, so as to update the token of the global token bucket.

Another flow chart of the traffic isolation speed limiting method for multiple processor cores is shown in fig. 4. Wherein get tokens represents the number of tokens actually taken from the token bucket and need to be consumed. The specific treatment steps are as follows:

the first step is as follows: checking whether a drop _ time is set or not, if the drop _ time is the current time and represents that the token of the second is consumed, discarding the subsequent message of the second; if the discard time is not the current time, the next step is entered.

The second step is that: checking whether a local cache corresponding to the service type of the processor core has a cached token or not, if so, checking whether the cached time is the current time or not, and if so, representing that the cache is effective; otherwise, clearing the token in the local token cache and entering a third step; if the cached tokens are effective and the number of the cached tokens is enough to be consumed by the current message, the tokens cached by the processor core are directly consumed, and the message passes; otherwise, entering the third step.

The third step: and according to the size of a local token cache corresponding to the service type of the processor core, taking a token from a global token bucket corresponding to the service type, adding the token into the local token cache corresponding to the service type of the processor core, and updating the local cache time to be the current time.

The fourth step: checking whether the updated local token cache is empty, if so, discarding the message, and updating the drop _ time to be the current time; if not, checking whether the cached token is enough to be consumed by the message, if so, subtracting the consumed token and passing, and if not, allowing the message to pass and emptying the cache (in order to avoid that the cache cannot be emptied and the message consumption cannot be satisfied, each subsequent message needs to read the shared token bucket before the cache fails, thereby causing performance waste and allowing the message to pass).

Wherein: and updating the token bucket, and calculating time difference updating when tokens are added or obtained regularly.

The embodiment of the invention has the following technical effects:

the isolation speed limit of the multi-core system to a large number of service levels is realized, and the requirement of isolation of any number of service speed limits can be met; in the aspect of performance, a 4-core processor is adopted, 64-byte messages are adopted, the processor is fully loaded for testing, and the performance loss is less than 15%; in practical application, the size of the report Wen Da is generally 300-1000 bytes, and the influence on the performance is less than 5%. The original TC module has low efficiency of message matching rules, so that the matching times are limited, and the separate isolation speed limit of a large number of services cannot be met. The technical scheme of the invention can meet the requirement of multi-service speed limit under high concurrency of a multi-core system, has small influence on performance and can meet the actual use.

It should be understood that the specific order or hierarchy of steps in the processes disclosed is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged without departing from the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

In the foregoing detailed description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the subject matter require more features than are expressly recited in each claim. Rather, as the following claims reflect, invention lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. To those skilled in the art; various modifications to these embodiments will be readily apparent, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of various embodiments are possible. Accordingly, the embodiments described herein are intended to embrace all such alterations, modifications and variations that fall within the scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising: as interpreted by the use of "in the claims as a conjunction. Furthermore, any use of the term "or" in the specification of the claims is intended to mean a "non-exclusive or".

Those of skill in the art will further appreciate that the various illustrative logical blocks, units, and steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate the interchangeability of hardware and software, various illustrative components, elements, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design requirements of the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.

The various illustrative logical blocks, or elements, described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor, an Application Specific Integrated Circuit (ASIC), a field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other similar configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. For example, a storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC, which may be located in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary designs, the functions described in the embodiments of the present invention may be implemented in hardware, software, firmware, or any combination of the three. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media that facilitate transfer of a computer program from one place to another. Storage media may be any available media that can be accessed by a general purpose or special purpose computer. For example, such computer-readable media can include, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store program code in the form of instructions or data structures and which can be read by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Additionally, any connection is properly termed a computer-readable medium, and, thus, is included if the software is transmitted from a website, server, or other remote source via a coaxial cable, fiber optic cable, twisted pair, digital Subscriber Line (DSL), or wirelessly, e.g., infrared, radio, and microwave. Such discs (disk) and disks (disc) include compact disks, laser disks, optical disks, DVDs, floppy disks and blu-ray disks where disks usually reproduce data magnetically, while disks usually reproduce data optically with lasers. Combinations of the above may also be included in the computer-readable medium.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A service isolation speed limiting method for a multi-processor core is characterized by comprising the following steps:

if the validity of the local token is checked to be effective and the number of the local tokens is larger than or equal to the number of the required tokens of the service message, consuming tokens, which are consistent with the number of the required tokens, in a local token cache corresponding to the processor core and used for the service type, and releasing the service message; if not, then,

2. The method for limiting the speed of traffic isolation for multiple processor cores according to claim 1, wherein the checking whether the global token bucket corresponding to the traffic type is valid comprises:

checking whether the validity identification of the global token bucket corresponding to the service type is valid; the validity identification is set to be valid when the global token bucket corresponding to the service type is updated each time;

3. The traffic isolation speed limiting method for the multi-processor core according to claim 1, wherein the obtaining the tokens from the global token bucket corresponding to the traffic type and updating the actually obtained tokens to the local token cache corresponding to the processor core for the traffic type comprises:

if the validity of the local token is invalid, clearing the local token cache which is corresponding to the processor core and is used for the service type; further, obtaining tokens from a global token bucket corresponding to the service type according to the expected number of obtained tokens in the local token cache corresponding to the processor core and used for the service type, and adding the actually obtained tokens to the local token cache corresponding to the processor core and used for the service type;

4. The traffic isolation speed limiting method for the multi-processor core as recited in claim 3, wherein the obtaining of the tokens from the global token bucket corresponding to the traffic type according to the expected number of obtaining tokens of the local token cache corresponding to the processor core for the traffic type comprises:

5. The method for limiting the speed of the traffic isolation for the multi-processor core according to claim 2, wherein if the updated number of tokens is greater than a preset threshold value of the critical number of tokens, consuming the tokens in the local token cache corresponding to the processor core and used for the traffic type, and passing through the traffic packet comprises:

6. A service isolation speed limiting device for a multi-processor core is characterized by comprising:

a local cache checking unit, configured to further check validity of local tokens and a number of local tokens in a local token cache for the service type corresponding to the processor core if the global token bucket corresponding to the service type is valid; if the validity of the local token is checked to be valid and the number of the local tokens is larger than or equal to the number of the required tokens of the service message, triggering the second message filtering unit, otherwise, triggering the local cache updating and message filtering unit;

7. The traffic isolation speed limiting device for the multi-processor core as claimed in claim 6, wherein the global token bucket checking unit is specifically configured to: checking whether the validity identification of the global token bucket corresponding to the service type is valid; the validity mark is set to be valid when the global token bucket corresponding to the service type is updated each time;

the local cache updating and message filtering unit comprises:

8. The traffic isolation speed limiting device for the multi-processor core as claimed in claim 6, wherein the local cache updating and message filtering unit comprises:

a first local cache updating module, configured to, if the validity of the local token is invalid, clear a local token cache, corresponding to the processor core, that is used for the service type; further, triggering a third local cache updating module;

9. The traffic isolation rate limiting device for the multi-processor core according to claim 8, wherein the third local cache updating module is specifically configured to:

10. The traffic isolation speed limiting device for the multi-processor core according to claim 7, wherein the first packet filtering module comprises:

and the token shortage module is a message filtering module and is used for consuming all tokens in the local token cache corresponding to the processor core and used for the service type and releasing the service message if the updated token number is less than the required token number of the service message and greater than the threshold value of the critical token number.