Java programming--Application limit of server design scheme

Preface

It is very important to control traffic in a high-concurrency system, and it may not be possible to make the interface unusable if the huge amount of traffic is requested directly to our server, and the entire application will be unavailable even if it is not processed.
For example, recently there is a demand, I as the client to Kafka production data, and Kafka consumers will continue to consume data, and the consumption of data all request to the Web server, although the load (there are 4 Web servers) but the amount of business data is also huge, Tens of thousands of data may be generated per second. If the producer produces data directly, it is highly likely that the Web server will be dragged down.
This must be done to limit the flow of processing, the production of a certain amount of data per second to Kafka, so as to greatly guarantee the normal operation of the web.
In fact, regardless of the scenario, the essence is to reduce the flow of high-availability applications.

Common Algorithms

There are two common algorithms for limiting current:

leaky bucket algorithm token bucket Algorithm

Leaky bucket algorithm is relatively simple, that is, the flow into the bucket, the leaky bucket at a certain rate of outflow, if the flow is too fast, it will overflow (leaky barrels will not increase the outflow rate). The overflow flow is discarded directly.
As shown in the following:
Https://user-gold-cdn.xitu.io/2018/8/2/164fa068dd4175c4?imageslim
This practice is simple and brutal.
Although the leaky bucket algorithm is simple, it cannot cope with real-world scenarios, such as sudden bursts of traffic.
Then you need to use the token bucket algorithm:
The token bucket puts tokens in a fixed-size bucket at a constant rate and takes one or more tokens when there is traffic. Discard or block the current request when there is no token in the bucket.
In contrast, the token bucket can handle a certain burst of traffic.
Https://user-gold-cdn.xitu.io/2018/8/2/164fa0714e2165b1?imageslim
Ratelimiter implementation
For the code implementation of the token bucket, you can use the Ratelimiter in the guava package directly.
Https://user-gold-cdn.xitu.io/2018/8/2/164fa078d7ea98f5?imageslim
The result of the call is as follows:
Https://user-gold-cdn.xitu.io/2018/8/2/164fa07c2181e936?imageslim
The code can see that two tokens are placed in the bucket every second, and the request consumes one token at a time. So only two requests per second can be sent. This is true by the time shown in the figure (the return value is the time it takes to get this token, almost every 500ms).
There are several notable places to use:
Allow the first consumption, after payment, means it can come to a request at a time to take away a few or all of the remaining tokens or even more, but the subsequent request to pay for the last request, it needs to wait for the token in the bucket to be completed before continuing to obtain tokens.

Summary

The pin is sufficient for a single application, if a distributed environment can be done with Redis.

Java programming--Application limit of server design scheme