This section will introduce its basic usage through token limit (tokenlimit).
On the whole, the token bucket production logic is as follows:
- The average sending rate configured by the user is r, then a token is added to the bucket every 1/r second;
- Assume that at most b tokens can be stored in the bucket. If the token bucket is full when the token arrives, then the token will be discarded;
- When the traffic enters at the rate v, the token is taken from the bucket at the rate v, the traffic that gets the token passes, and the traffic that does not get the token does not pass, and the fuse logic is executed;
go-zero adopts the method of
lua script under both types of current limiters, relying on redis to achieve distributed current limiting, and
lua script can also achieve atomicity of token production and read operations.
Let's take a look at several key attributes controlled by
|ARGV||rate 「How many tokens are generated per second」|
|ARGV||burst 「Maximum token bucket」|
|ARGV||get token nums 「The number of tokens that the developer needs to obtain」|
|KEYS||Tokenkey representing the resource|
|KEYS||The key that represents the refresh time|
It can be seen from the above that the
lua script: only involves the operation of the token, ensuring that the token is produced and read reasonably.
Seen from the above flow:
- There are multiple guarantee mechanisms to ensure that the current limit will be completed.
- If the
redis limiterfails, at least in the process
rate limiterwill cover it.
- Retry the
redis limitermechanism to ensure that it runs as normally as possible.
tokenlimit current limiting scheme in
go-zero is suitable for instantaneous traffic shocks, and the actual request scenario is not at a constant rate. The token bucket is quite pre-request, and when the real request arrives, it won't be destroyed instantly. When the traffic hits a certain level, consumption will be carried out at a predetermined rate.
However, in the production of
token, dynamic adjustment cannot be made according to the current flow situation, and it is not flexible enough, and further optimization can be carried out. In addition, you can refer to Token bucket WIKI which mentioned hierarchical token buckets, which are divided into different queues according to different traffic bandwidths.