Shulou(Shulou.com)06/02 Report--

Many novices are not very clear about how to understand the Gubernator rate limit service. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Gubernator is a distributed, high-performance, cloud-native and stateless rate-limiting service.

Key characteristics

Gubernator can limit the average rate of requests to the entire cluster, which means that you can simply expand the system service capacity smoothly by adding more nodes.

Gubernator does not rely on external caching, such as MemCache or Redis, nor on other services, which means that this service can dynamically increase service capacity.

Gubernator maintains the stateless capacity of the disk, based on the configuration processing capacity of each request.

Gubernator provides access to API interfaces for GPRC and HTTP.

It can be used as an edge service or a separate service to limit the rate.

It can be used as a library for custom services.

Support for rate limiting in scalable external environments.

Gubernator is the English pronunciation of a Russian officer. It sounds good.

Stateless configuration

Gubernator is a stateless service that does not require disk space to hold historical operations, no configuration and data will be cached to disk, because every request, including configuration information, rate limit configuration information is only a 64-bit integer.

For example, restrict GRPC

Rate_limits: # name of rate limit-name: requests_per_sec # a unique key Instance name used to identify request limit: unique_key: account_id=123 | number of source_ip=172.0.0.1 # requests hits: 1 # Total number of requests for speed limit limit: 100 # cycle length of speed limit (Ms) duration: 1000 # algorithm for calculating rate limit 0 signal bucket 1 drip bucket algorithm: 0 # the behavior of speed limit 0 allows each batch request 1 not only batch request 2 allows global buffering The storage rate limit behavior: 0 is as follows: rate_limits: # status of speed limit OK=0 OVER_LIMIT = 1-status: 0, # current configuration limit limit: 10 # request hold quantity remaining: 7 # unix timestamp of barrel limit If the limit is exceeded, the setting time will no longer return OVER_LIMIT reset_time: 155130921926 # additional raw information about the rate limit per request metadata: "owner": "api-n03.staging.us-east-1.mailgun.org:9041" rate limit algorithm signal bucket

It starts with an empty bucket, and each command request adds 1 to the data in the bucket until the bucket is full. If the bucket is full, it will return OVER_LIMIT, go to the timer zero, and then start the loop.

Hourglass bucket

When the bucket is full, OVER_LIMIT is returned, and then the data in the bucket is calculated by the duration / limit. At this point, if there is space, you can continue to enter the data.

Performance

In our production environment, each API per request is limited to 2, which is limited by the specified time. As shown in the following figure, the batch response of more than 2000 requests per second is less than 1 millisecond.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.