CN115225580B

CN115225580B - Service isolation speed limiting method and device for multiprocessor cores

Info

Publication number: CN115225580B
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: 2024-02-02
Anticipated expiration: 2042-06-10
Also published as: CN115225580A

Abstract

The embodiment of the invention provides a service isolation speed limiting method and device for multiprocessor cores, wherein a local token cache is built in each processor core according to service types, and when a service message arrives at the processor core, each processor core firstly acquires a token in the local token cache of the processor core corresponding to the service type, so that the access times to a global token bucket are reduced, and blocking caused by lock competition of the global token bucket is avoided; meanwhile, a global token bucket shared by all processor cores is established at a global level, and the token quantity of the global token bucket is set according to the service type requirement, so that the purpose of speed limitation according to the service type is realized.

Description

Service isolation speed limiting method and device for multiprocessor cores

Technical Field

The invention relates to the field of service isolation speed limiting, in particular to a service isolation speed limiting method and device for a multiprocessor core.

Background

The current load balancing application is the most widely DPVS, is a multi-core high-performance four-layer load balancing forwarding system, but in practical application, a large amount of services exist, if some services are attacked, system resources are exhausted, other service services are affected, and therefore resource isolation is needed for the services; whereas the speed limiting module of DPVS is a separate module TC, which is not in any connection with the traffic, and requires separate configuration of the splitter and scheduler. The flow divider is a message matching rule set, and the scheduler performs scheduling according to the speed limiting parameters. The traffic needs to be matched in order according to the configured splitting rules. The principle of the speed limit of the load by the TC module of the DPVS is as follows: under a message scheduling queue, the messages are sequentially compared one by one through a diverter until the messages are completely matched with the rules, and then the speed limiting operation is carried out on the messages by using a scheduler arranged in the matched rules. While the splitter makes 8 comparisons that have not yet been fully matched, the packet is discarded directly.

In carrying out the present invention, the applicant has found that at least the following problems exist in the prior art:

under a large number of services, the speed limit of the TC module of the DPVS is very large due to the fact that the entries of the matching rules of the splitter are very large, the matching efficiency is low, and meanwhile, the matching times are limited; the requirement of individual speed limitation of a large number of businesses cannot be met.

Disclosure of Invention

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

In order to achieve the above objective, in one aspect, an embodiment of the present invention provides a traffic isolation speed limiting method for a multiprocessor core, including:

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

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

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 of the 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 validity of the local tokens 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 the tokens which correspond to the processor core and are in accordance with the number of the required tokens in the local token cache for the service type, and releasing the service message; otherwise the first set of parameters is selected,

obtaining tokens from a global token bucket corresponding to the service type, updating the tokens which are obtained in practice into a local token cache corresponding to the processor core and used for the service type, obtaining the updated token quantity corresponding to the processor core and used for the local token cache of 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 the multiprocessor 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 limiting 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.

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

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

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

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

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

Further, the step of obtaining tokens from a global token bucket corresponding to the service type and updating the tokens obtained in practice into a local token cache corresponding to the processor core and used for the service type includes:

if the validity of the local token is invalid, clearing a local token cache corresponding to the processor core and used for the service type; further, according to the expected acquired token quantity of the local token cache for the service type corresponding to the processor core, acquiring tokens from a global token bucket corresponding to the service type, and adding the actually acquired tokens into the local token cache for the service type corresponding to the processor core;

And if the local token validity is valid and the number of the local tokens is smaller than the number of the required tokens of the service message, acquiring the tokens from a global token bucket corresponding to the service type according to the expected acquired token number of the local token cache corresponding to the processor core and used for the service type, and adding the actually acquired tokens into 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 service type according to the expected obtained token number of the local token cache corresponding to the processor core, including:

if the current token quantity in the global token bucket corresponding to the service type meets the expected acquired token quantity, acquiring a token consistent with the expected acquired token quantity in the global token bucket corresponding to the service type;

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

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

if the number of the updated tokens is greater than or equal to the number of the required tokens of the service message, consuming the tokens which correspond to the processor core and are in accordance with the number of the required tokens in a local token cache for the service type, and releasing the service message;

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

On the other hand, the embodiment of the invention provides a service isolation speed limiting device for a multiprocessor core, which comprises the following components:

a service type determining unit, configured to determine, for each processor core, a service type of a 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;

a local cache checking unit, configured to further check, if the global token bucket corresponding to the service type is valid, the validity of the local token and the number of the local tokens in the local token cache corresponding to the service type and corresponding to the processor core; if the validity of the local tokens 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;

the second message filtering unit is used for consuming tokens with the same quantity as the required tokens in the local token caches for the service types corresponding to the processor cores and releasing the service messages;

the local cache updating and message filtering unit is used for acquiring tokens from a global token bucket corresponding to the service type, updating the actually acquired tokens into the local token caches corresponding to the processor core and used for the service type, obtaining the updated token quantity corresponding to the processor core and used for the local token caches of the service type, and processing the service message based on the updated token quantity;

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

the local cache updating and message filtering unit comprises:

the first message filtering module is used for consuming tokens in the local token cache for the service type corresponding to the processor core and releasing the service message if the updated token number is greater than a preset critical token number threshold; 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 identification of the global token bucket corresponding to the service type to be invalid if the updated token quantity is smaller than or equal to the critical token quantity threshold value.

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

the first local cache updating module is used for clearing the local token cache corresponding to the processor core and used for the service type 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 local token validity is valid and the number of the local tokens is smaller 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 acquired token quantity of the local token cache corresponding to the processor core and used for the service type, and adding the actually acquired tokens into 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 acquired token quantity, acquiring a token consistent with the expected acquired token quantity in the global token bucket corresponding to the service type; and if the current token quantity in the global token bucket corresponding to the service type does not meet the expected acquired token quantity, acquiring all tokens in the global token bucket corresponding to the service type.

Further, the first message filtering module includes:

the message filtering module when the tokens are sufficient is used for consuming the tokens which correspond to the processor core and are used for the local token cache of the service type and are consistent with the required token number if the updated token number is greater than or equal to the required token number of the service message, and releasing the service message;

the token deficiency is a message filtering module, configured to consume all tokens 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 smaller 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: when a service message arrives at a processor core, each processor core firstly acquires a token from the local token cache of the processor core corresponding to the service type, so that the access times to a global token bucket are reduced, meanwhile, a global token bucket shared by all the processor cores is built on the global level, the number of tokens of the global token bucket is set according to the requirement of the service type, the purpose of speed limitation according to the service type is realized, and meanwhile, the local cache is built on each processor core to prevent each processor core from frequently accessing the global token bucket, so that blocking caused by lock competition of the global token bucket is avoided, and the effect that the speed limitation according to the service type is respectively realized based on the multiprocessor cores, and the whole speed limitation system can stably operate when a large number of service isolation speed limits are processed is ensured.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a traffic isolation speed limiting method for a multiprocessor core, in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram of a traffic isolation speed limiter for a multiprocessor core according to one embodiment of the present invention;

FIG. 3 is a diagram of a multiprocessor core, traffic types, and global token bucket correspondence in accordance with one embodiment of the present invention;

fig. 4 is another flow chart of a traffic isolation speed limiting method for a multiprocessor core in accordance with an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

In one aspect, as shown in fig. 1, an embodiment of the present invention provides a traffic isolation speed limiting method for a multiprocessor core, including:

step S100, for 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 the step S102, and if yes, namely the global token bucket corresponding to the service type is valid, executing the step S103;

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

step S103, further checking the validity of the local tokens and the number of the local tokens in the local token caches for the service types corresponding to the processor cores;

step S104, judging whether the validity of the local tokens is valid and the number of the local tokens is larger than or equal to the number of the required tokens of the service message; if yes, that is, the validity of the local tokens 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 step S105, otherwise, executing step S106;

Step S105, consuming tokens with the same number as the required tokens in the local token caches for the service types corresponding to the processor cores, and releasing the service message;

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

In some embodiments, each processor core may receive a service message of one or more service types, and in a local access range of each processor core, a local token cache for each service type that the processor core may receive is respectively established for the service type; global token buckets corresponding to traffic types are set for each possible traffic type separately within the reach of 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 for caching tokens that is configured locally in advance for each processor core. Each processor core receives at least one type of service message, and local token caches with specified local cache sizes are respectively configured in advance for each service type in the local area of the processor core. 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 shared by all processor cores which is configured in the global scope in advance; the global token buckets are respectively configured according to the service types, and a plurality of global token buckets are correspondingly configured if a plurality of service types exist. The maximum token number of each global token bucket is respectively determined according to the speed limiting 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 the same or different, so that the purpose of respectively limiting the speed of the service messages of each service type is realized. By setting a local token buffer memory for each service type of each processor core and setting corresponding shared global token buffer memories for all the processor cores according to the service types, when tokens are available in the local token buffer memories corresponding to the service types, the processor cores directly acquire the tokens from the local token buffer memories when processing service messages of the service types, and the global token barrel corresponding to the service types is not required to be accessed, so that the global token barrel blocking caused by the processing of a large number of services of the multiprocessor cores is avoided to a certain extent, and the stability of the system is improved. The global token bucket is updated according to a designated token updating period, tokens generated in one token updating period are valid only in the token updating period, and when the system time exceeds the token updating period as the system time passes, the tokens generated in the token updating period are regarded as invalid, and the release amount of service messages 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 comprises, 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 a preset classification matching item one by one; each classification matching item corresponds to a service type, and each matching item contains a specific value of interested service message information; preferably, the message information of the service message can be hashed to obtain an index value, and the service type of the service message is searched 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, corresponding global token buckets are set for each service type, and the number of the service types and the number of the corresponding global token buckets are set; when a service message of a certain service type is processed, tokens can only be obtained from a global token bucket corresponding to the service type or a local token cache applied to the service type by checking a processor for processing the service message; the aim of limiting the speed of the service message according to the service type can be realized by respectively setting the updated token quantity in the unit time of each global token bucket; when there are no tokens in the global token bucket or there are residual tokens, the global token bucket is considered invalid when the residual tokens have been invalidated, that is, step S102 needs to be executed, and the message received before the next update of the global token bucket needs to be discarded. If the global token bucket is valid, step S103 is executed to obtain the validity and the number of local tokens in the local token cache corresponding to the processor core and used for the service type, and step S104 is further executed to check whether the validity of the local tokens is valid and the number of local tokens is greater than or equal to the number of tokens required by the service packet, and because of the asynchronous relationship between the local token cache and the global token cache, the tokens cached in the local token cache may be unused tokens left in the last token update period, and then in the current token update period, the tokens 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 tokens in the local token cache do not belong to the time range corresponding to the current token update period, and then the tokens in the local token cache may be invalid, otherwise, if the update time of the tokens in the local token cache is within the time range corresponding to the current token update period, the tokens in the local token cache are considered valid. When the tokens in the local token cache are valid, the number of tokens therein also needs to be checked to determine if the tokens in the local token cache are sufficient for the current traffic message to be consumed. When the global token bucket is valid, the service message of the service type is indicated to have available tokens, at the moment, whether the local token cache has enough available tokens is judged, if the processor checks that the local token cache applied to the service type has enough tokens for the number of the required tokens of the service message, the processor can directly acquire the tokens from the local token cache and release the service message, namely, the step S105 is executed, so that the number of times of acquiring the tokens from the global token bucket is reduced, and the competition when accessing the global token bucket among processor cores is obviously reduced; if the processor core that receives the service packet checks that the number of valid local tokens in the local token cache for the service type is smaller than the number of required tokens of the service packet, the processor core will attempt to acquire tokens from the global token bucket corresponding to the service type, and add the acquired tokens to the local token cache for the service type corresponding to the processor core, and execute step S106 by processing 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 comprises the steps of, 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 by the service message may be determined according to the number of bytes of the service message, one byte or a specified number of bytes may correspond to one token, or one or more tokens may also correspond to one or more numbers in units of one message. When tokens are obtained from the global token bucket and added to the local token cache, the tokens taken out from the global token bucket are removed from the global token bucket, for example, 100 tokens are in the global token bucket, 10 tokens are obtained and added to the local token cache this time, and 90 tokens are 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 buffer memory according to the service type in each processor core, when a service message arrives at the processor core, each processor core firstly acquires a token in the local token buffer memory of the processor core corresponding to the service type, so that the access times to a global token bucket are reduced, simultaneously, establishing global token buckets which are shared by all the processor cores and respectively correspond to each service type in a global layer, setting the token quantity of the global token buckets corresponding to the service type according to the requirement of the service type, realizing the purpose of speed limitation according to the service type, and simultaneously, avoiding access conflict caused by each processor and frequently accessing the global token buckets by establishing the local buffer memory in each processor core, thereby avoiding the blocking of the global token bucket, achieving the effect of respectively speed limitation according to the service type based on the multiprocessor core and ensuring that the whole speed limiting system can stably operate when processing a large amount of service isolation speed limitation.

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, namely, when the global token bucket corresponding to the service type is found to be exhausted, the tokens generated in the current token updating period (namely, the current unit time) are exhausted; the tokens in the global token bucket expire, that is, the remaining unused tokens in the global token bucket are updated in the last unit time before entering the critical state of the current unit time from the last unit time and before executing the update for the global token bucket, and the tokens should be regarded as expired tokens in the current unit time; a validity flag may be set for each global token bucket, the validity flag being set to be invalid when the global token bucket is exhausted, and the validity flag being set to be valid when the global token bucket is updated. Boolean-type values or other types of values may be used to represent valid and invalid, respectively, for validity identification; preferably, the time may be used as a value of the validity identifier, in some specific embodiments, when a global token bucket corresponding to a certain service type has no token available, the validity identifier corresponding to the global token bucket may be set as a current time, when checking whether the global token bucket corresponding to the service type is valid, specifically, by determining whether the time recorded by the validity identifier corresponding to the global token bucket belongs to the current unit time, if so, the global token bucket is considered invalid; since the system time is automatically elapsed, after the global token bucket is updated in the next unit time, the time of the validity identification record does not naturally belong to the next unit time in the next unit time, so that the automatic elapse of the system time is equivalent to the automatic marking of the global token bucket as valid when the global token bucket is updated. When each processor core processes the service message of the service type, 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 received before the next update of the global token bucket corresponding to the service type. Thus, the situation that the global token bucket is still accessed every time the service message arrives when the token is exhausted is avoided, and a large amount of accesses to the global token bucket are avoided. Judging whether the time of the validity identification record belongs to the current unit time or not, considering the time of the validity identification record and the accuracy of the unit time, for example, the unit time is 1 second, and the minimum accuracy of the time of the validity identification record is 1 second, if the time of the validity identification record is equal to the current unit time, considering that the time of the validity identification record belongs to the current unit time, otherwise, not belonging 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 quantity is smaller than the quantity of the required tokens of the service message; the threshold value of the critical token number can be flexibly set according to specific requirements.

When the number of updated tokens is less than or equal to the threshold of critical token number, the processor that is processing the service message checks that the number of tokens in the local token cache for the service type of the service message is too small to allow the service message to pass, so the service message is discarded.

If the number of updated tokens is greater than a preset threshold number of critical tokens, the service message can be released, and the processor which is processing the service message checks the tokens in the local token cache applied to the service type of the service message, wherein the specific number of consumed tokens can be the minimum value of the number of updated tokens and the number of required tokens of the service message.

Preferably, the threshold of the critical token number is set to 0, and when the new token number is less than or equal to the threshold of the critical token number (0 at this time) after updating from the global token bucket corresponding to the service type of the service message being processed, that is, when the number of tokens in the local token cache applied to the service type is checked to be 0 by the processor processing the service message, it is indicated that no token is available in both the global token bucket and the local token cache, and the service message needs to be discarded.

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

The embodiment of the invention has the following technical effects: by setting a validity identifier for the global token bucket corresponding to each service type and checking the validity identifier before processing the service message corresponding to the service type, a large number of continuous 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 global token bucket blocking is avoided; 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, the validity identification is not required to be specially set when the global token bucket is updated, the operation complexity of the token validity identification is simplified, and the structure of a program is simplified.

The expected acquired token number is larger than the required token number of all service messages, so that when the tokens of the global token bucket are sufficient, the tokens supplemented to the local token cache from the global token bucket are ensured to be enough for the consumption of the current service messages; in addition, on the basis that the number of expected acquired tokens is larger than the number of required tokens of all service messages, the number of expected acquired tokens is reasonably determined according to the number of processor cores and the total number of tokens in a global token bucket, namely the number of times of accessing the global token bucket needs to be reduced by the processor cores, the tokens in the global token bucket corresponding to the corresponding service type also need to be distributed to local token caches of the corresponding service type in each processor core in a more reasonable mode, and the phenomenon that insufficient tokens are obtained by other processor cores due to too many cached tokens acquired by some processor cores is avoided.

In some embodiments, after a certain processor core receives a service message and determines a service type of the service message, confirming that a global token bucket corresponding to the service type is valid, and further checking the validity of a local token and the number of local tokens in a local token cache applied to the service type by the processor core; since the tokens in the local token caches for the service types come from the global token buckets corresponding to the same service types, and the tokens in the global token buckets are updated in a unit time as a period, when the tokens in the local token caches are found to be the tokens in the last unit time in the current unit time, the tokens in the local token caches are invalid, and at the moment, the validity of the local tokens in the local token caches corresponding to the service types by the processor cores is invalid. If the token in the local token buffer is found to be the token in the current unit time, the token in the local token buffer is valid, and whether the number of tokens meets the requirement can be further checked.

If the processor currently processing the service message checks that the validity of the local token in the local token cache of the service type applied to the service message is invalid, indicating that the tokens in the local token cache are unavailable, clearing the local token cache, further acquiring the tokens from the global token cache corresponding to the service type according to the expected number of acquired tokens, and adding the actually acquired tokens into the local token cache.

If the processor currently processing the service message checks that the validity of the local token in the local token cache of the service type applied to 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, the fact that the tokens in the local token cache are valid is indicated, but the number of the local tokens is insufficient for the number of the required tokens of the service message, namely the number of the tokens in the local token cache is insufficient, the tokens are required to be acquired from the global token cache corresponding to the service type according to the expected number of the acquired tokens, and the actually acquired tokens are added into the local token cache.

In some embodiments, the upper limit token number of the local token buffer may be specified, when the local token buffer for a certain service type is obtained by obtaining token replenishment from a global token bucket corresponding to the certain service type, the difference between the upper limit token number of the local token buffer and the number of valid tokens currently remained in the local token buffer is calculated first, and the difference is taken as the expected obtained token number to obtain tokens from the global token bucket, where the number of tokens obtained from the global token bucket each time may be the same or different, and is related to the remaining valid local token number in the local token bucket.

In other embodiments, the preset expected token total amount may be used as the expected acquired token amount, when the local token cache for a certain service type is obtained by supplementing the acquired token from the global token bucket corresponding to the certain service type, the tokens are acquired from the global token bucket according to the expected acquired token amount (namely the expected token total amount at the moment), and the actually acquired tokens are added into the local token cache. At this time, the local token cache may not set an upper limit on the number of tokens so that the tokens of the expected total number of tokens do not overflow after accumulating with the tokens originally remaining in the local token cache. In some embodiments, an upper limit of the number of tokens may also be set for the local token cache, in order to avoid overflow of the number of tokens stored in the local token cache, the tokens acquired from the global token bucket may be cached in a temporary variable first, and after the temporary variable and the tokens in the current local token cache are consumed according to the number of tokens required by the message currently being processed, the remaining tokens in the temporary variable are added to the local token cache.

The embodiment of the invention has the following technical effects: and the number of expected acquired tokens is taken as the maximum limit to acquire the currently available tokens from the global token bucket, 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.

In some embodiments, since the number of tokens remaining in the global token bucket corresponding to the service type of the currently processed service message may be greater than, less than, or equal to the expected acquisition token number, when the number of tokens remaining in the global token bucket is greater than or equal to the expected acquisition token number, the number of tokens actually acquired is consistent with the expected acquisition token number, and if the number of tokens remaining in the global token bucket is less than the expected acquisition token number, all the token fetches in the global token bucket are added to the corresponding local token caches.

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

when the number of updated tokens in the local token cache is smaller than the number of required tokens of the service message, the situation that after the global token bucket corresponding to the service type supplements the tokens to the local token cache this time, the tokens of the global token bucket corresponding to the service type in the time range corresponding to the current token updating period are exhausted, and the number of the tokens in the local token cache after the tokens are supplemented is still insufficient for the service message, but because the situation only happens when the corresponding global token bucket is exhausted, in order to keep the consistency of 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 with the same service type arrives, the local token buffer is empty, so that the access to the global token bucket is triggered, and the global token bucket is also empty, thereby establishing an invalid identifier of the global token bucket, discarding the next service message, and discarding the service message which arrives later in the current updating period of the global token bucket. So as to fully utilize the service processing capability of the processor core and discard the service message of the service type which subsequently arrives at the processor core in the token updating period when the global token bucket corresponding to the service type does not have the available message, thereby achieving the effect of speed limitation.

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

a service type determining unit 200, configured to determine, for each processor core, a service type of a 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 message filtering unit 202, configured to discard a 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;

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 the local token and the number of local tokens in the 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 message, triggering the second message filtering unit 204, otherwise, triggering the local cache updating and message filtering unit 205;

A second message filtering unit 204, configured to consume tokens with the number consistent with the number of the required tokens in a local token cache for the service type corresponding to the processor core, and release the service message;

a local cache updating and message filtering unit 205, configured to obtain a token from a global token bucket corresponding to the service type, update the actually obtained token to a local token cache corresponding to the processor core and used for the service type, obtain an updated token number corresponding to the processor core and used for the local token cache of 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 mark of the global token bucket corresponding to the service type is valid or not; the validity identification is set to be valid each time the global token bucket corresponding to the service type is updated;

The local cache update and message filtering unit 205 includes:

Further, the local cache update and message filtering unit 205 includes:

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

Further, the first message filtering module includes:

The embodiment of the invention has the following technical effects: when a service message arrives at a processor core, each processor core firstly acquires a token from the local token cache of the processor core corresponding to the service type, so that the access times to a global token bucket are reduced, meanwhile, a global token bucket shared by all the processor cores is built on the global level, the number of tokens of the global token bucket is set according to the requirement of the service type, the purpose of speed limitation according to the service type is realized, and meanwhile, the local cache is built on each processor core to prevent each processor core from frequently accessing the global token bucket, so that blocking caused by lock competition of the global token bucket is avoided, and the effect that the speed limitation according to the service type is respectively realized based on the multiprocessor cores, and the whole speed limitation system can stably operate when a large number of service isolation speed limits are processed is ensured.

The embodiments of the service isolation speed limiting device for the multiprocessor core provided by the embodiment of the invention are embodiments corresponding to the service isolation speed limiting method for the multiprocessor core one by one, and the embodiments of the service isolation speed limiting device for the multiprocessor core can be understood according to the foregoing description of the embodiments of the service isolation speed limiting method for the multiprocessor core, which are not described herein.

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

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

The speed limit of the shunted 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 service 1 token bucket, service 2 token bucket and service 3 token bucket represent a global token bucket corresponding to service type 1, a global token bucket corresponding to service type 2 and a global token bucket corresponding to service type 3 respectively. 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 the service forwarding system of the multiprocessor cores, the competition of obtaining tokens among the multiple cores is prevented, and the local token cache of each processor core is increased, namely, each time a token is taken from a global token bucket, the token can be taken according to the set local token cache size and is put in the local token cache, and the cache number is recorded as cache_tokens; the tokens processed by the subsequent messages are only consumed by the local token cache, so that frequent shared memory competition caused by the fact that each message requests a global token bucket is avoided. The valid period of the local token buffer is only at the moment, the moment is recorded as cache_update_time (unit: second), the next moment is invalid (namely, the token in the global token bucket is updated every second), and the global token bucket needs to be sent again to request the token buffer.

At a certain moment, no token is taken from the global token bucket, and the subsequent message of the second is discarded without requesting the token when the token of the second is consumed; this time is denoted drop_time (in seconds), and each message requests shared global token bucket consumption performance while preventing the current time token from being exhausted.

And when the token is acquired, calculating the difference between the current time curr_time (unit: second) and the last token updating time token_update_time (unit: second) to update the token of the global token bucket.

Another flow chart of a traffic isolation speed limiting method for a multiprocessor core is shown in fig. 4. Where get_tokens represent the number of tokens actually taken from the token bucket and need_tokens are the number of tokens that need to be consumed. The specific processing steps are as follows:

the first step: checking whether drop_time is set, if the drop_time is the current time, the token representing the second is consumed, and discarding the subsequent message of the second; if the discard time is not the current time, then go to the next step.

And a second step of: 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, 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 valid and the quantity is enough to consume the message currently, directly consuming the cached tokens of the processor core, and allowing the message to pass; otherwise, the third step is carried out.

And a third step of: and according to the size of the local token cache corresponding to the service type of the processor core, taking a token from the 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.

Fourth step: checking whether the updated local token buffer is empty, discarding the message if the updated local token buffer is empty, and updating drop_time to be the current time; if the buffer is not empty, checking whether the buffer token is enough to consume the message, if the buffer token is enough to subtract the consumed token and pass, and if the buffer token is insufficient, allowing the message to pass and emptying the buffer (in order to avoid that the buffer cannot be emptied and the buffer consumption is not satisfied, each subsequent message needs to read the shared token bucket before the buffer is invalid, so that performance waste is caused, and the buffer is allowed to pass).

Wherein: the token bucket is updated and time difference updates may be calculated using timed additions or acquisition of tokens.

The embodiment of the invention has the following technical effects:

the multi-core system realizes the isolation and speed limit of a large number of service levels, and can meet the requirement of the isolation of any more service speed limits; in terms of performance, a 4-core processor and 64-byte messages are adopted, so that the processor is fully loaded for testing, and the performance loss is less than 15%; in practical application, the size of the message is generally 300-1000 bytes, and the influence on the performance is less than 5%. The conventional 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-core system for high concurrency multi-service speed limit, 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 are examples of exemplary approaches. Based on 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 meant 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 this detailed description, with each claim standing on its own as a separate preferred embodiment of this 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. As will be apparent 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.

The foregoing description 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, as used in the specification or claims, the term "comprising" is intended to be inclusive in a manner similar to the term "comprising," as "comprising: "as interpreted in the claims as a joinder word. Furthermore, any use of the term "or" in the specification of the claims is intended to mean "non-exclusive or".

Those of skill in the art will further appreciate that the various illustrative logical blocks (illustrative logical block), units, and steps described in connection with the embodiments of the invention may be implemented by electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components (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. Those skilled in the art may implement the described functionality in varying ways for each particular application, but such implementation is not to be understood as beyond the scope of the embodiments of the present invention.

The various illustrative logical blocks or units described in the embodiments of the invention 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. A general purpose processor may be a microprocessor, but in the alternative, the general purpose 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. In an example, a storage medium may be coupled to the processor such that 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 reside in a user terminal. In the alternative, the processor and the storage medium may reside as distinct components in a user terminal.

In one or more exemplary designs, the above-described functions of 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 a computer-readable medium or transmitted as one or more instructions or code on the computer-readable medium. Computer readable media includes both computer storage media and communication media that facilitate transfer of computer programs from one place to another. A 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 may 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 that may be used to carry or store program code in the form of instructions or data structures and other data structures that may be read by a general or special purpose computer, or a general or special purpose processor. Further, any connection is properly termed a computer-readable medium, e.g., 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 wireless such as infrared, radio, and microwave, and is also included in the definition of computer-readable medium. The disks (disks) and disks (disks) include compact disks, laser disks, optical disks, DVDs, floppy disks, and blu-ray discs where disks usually reproduce data magnetically, while disks usually reproduce data optically with lasers. Combinations of the above may also be included within the computer-readable media.

The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the invention, and is not meant to limit the scope of the invention, but to limit the invention to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the invention are intended to be included within the scope of the invention.

Claims

1. A traffic isolation speed limiting method for a multiprocessor core, comprising:

2. The traffic isolation speed limiting method for a multiprocessor core according to claim 1, wherein said checking whether a global token bucket corresponding to said traffic type is valid comprises:

3. The traffic isolation speed limiting method for a multiprocessor core according to claim 1, wherein the steps of acquiring tokens from a global token bucket corresponding to the traffic type, and updating the actually acquired tokens into a local token cache corresponding to the processor core for the traffic type, comprise:

4. The traffic isolation speed limiting method for a multiprocessor core according to claim 3, wherein said obtaining tokens from a global token bucket corresponding to said traffic type according to an expected number of obtained tokens for a local token cache for said traffic type corresponding to said processor core comprises:

5. The traffic isolation speed limiting method for a multiprocessor core according to claim 2, wherein if the updated token number is greater than a preset critical token number threshold, consuming a token in a local token cache for the traffic type corresponding to the processor core, and releasing the traffic message, comprising:

6. A traffic isolation speed limiting device for a multiprocessor core, comprising:

a local cache checking unit, configured to further check, if the global token bucket corresponding to the service type is valid, the validity of the local token and the number of the local tokens in the local token cache corresponding to the service type and corresponding to the processor core; if the validity of the local tokens 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 a second message filtering unit, otherwise, triggering a local cache updating and message filtering unit;

7. The traffic-isolation speed-limiting device for a multiprocessor core of claim 6, wherein the global token bucket inspection unit is specifically configured to: checking whether the validity mark of the global token bucket corresponding to the service type is valid or not; the validity identification is set to be valid each time the global token bucket corresponding to the service type is updated;

The local cache updating and message filtering unit comprises:

8. The traffic-isolation speed limiter for multiprocessor cores of claim 6, wherein the local cache update and message filter unit comprises:

9. The traffic-isolation speed limiting device for a multiprocessor core of claim 8, wherein the third local cache update module is specifically configured to:

10. The traffic-isolation speed limiter for a multiprocessor core of claim 7, wherein the first message filter module comprises:

and the message filtering module is used for consuming all tokens in the local token cache for the service type corresponding to the processor core and releasing the service message if the updated token quantity is smaller than the required token quantity of the service message and larger than the threshold value of the critical token quantity.