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

This article mainly introduces how to achieve API interface current limit, the article is very detailed, has a certain reference value, interested friends must read it!

Similarly, in the Internet industry, there is also such a scenario, we call it-- current restriction, why limit it for the following reasons:

At the beginning of the system launch, when the number of users and visits are small, several application servers are generally deployed, and the database can basically withstand the separation of read and write, but with the passage of time, the number of users and daily active users increases, and the pressure on the system is increasing. We all know that the expansion of the application server is very convenient, but the database expansion is troublesome, if the amount of database requested is too large. Or encounter malicious attacks, the database is very likely to downtime, resulting in the entire site unavailable.

In order to avoid this happening, we usually have to limit the number of requests made by users. For legitimate users, we need to limit the number of calls to the interface per unit time, and for malicious attackers, put them directly on the blacklist.

We usually use the zset data structure in Redis to limit the current. Because the underlying zset uses a jump table to store data, sorting by score field from smallest to largest, we can store the timestamp in the score field. With the passage of time, the timestamp of each request is stored in score, but what about member? It doesn't matter what you store, but don't store too much data. As shown below:

If we require no more than 100 calls to the API in a minute, then the orange rectangular area in the figure is a time window within a time period, and the border of the rectangle is the current time, which moves to the right a little bit as time goes by. The left border of the rectangle is in front of 1min, and the width of the rectangle is 1min. We can easily calculate the amount of data in this time range through the zcount command of Redis. If the amount of data exceeds 100, it means that the user requests too quickly and should limit the flow. Let's look at a simple piece of code:

/ * * based on zset current limit * @ param key redis key * @ param maxCount, the maximum number of passes in a specified time * @ param timeRange time window range Unit: second * @ return can continue to request * / public static boolean rateLimiterByZset (String key,int maxCount,int timeRange) {try (Jedis jedis = jedisPool.getResource ()) {long currentTime = new Date () .getTime () / / current timestamp long secondTime = currentTime-timeRange*1000; / second second timestamp long memberCount = jedis.zcount (key,secondTime,currentTime); if (memberCount > = maxCount) {return false;}

Jedis.zadd (key,currentTime,currentTime+ ""); / / Delete the data outside the time box because they are no longer using jedis.zremrangeByScore (key,0,secondTime);} return true;}

Haha, it's that simple. It is important to note that please delete the data outside the time box (that is, outside the left box in the image above) in time, because they are useless and consume a lot of memory resources.

Do you have such a question: is there a performance problem with such frequent zset operations? In fact, we do not have to worry too much, after all, the data structure of Redis is carefully designed, and the sexual performance is very high. You can refer to this article in the editor to learn the data structure of Redis.

Analyze why Redis performance is so high from the point of view of data storage

Liu Yun, official account: pay homage to the code to analyze why Redis performance is so high from the perspective of data storage.

The test program and output are as follows:

@ Test public void test1 () throws Exception {int I = 1; while (true) {Thread.sleep (5); boolean flag = RedisRateLimiter.rateLimiterByZset ("keysss", 10L1); if (flag) {System.out.println ("1st" + I + "request successful") } else {System.out.println ("th" + I + "restricted current");} iTunes + The first request succeeds, the second request succeeds, the third request succeeds, the fourth request succeeds, the fifth request succeeds, the sixth request succeeds, the seventh request succeeds, the eighth request succeeds, the ninth request succeeds, the 10th request succeeds, the 11th is restricted, the 12th is restricted. 42nd, 43rd, 44th, 45th, 46th, 47th, 48th, 49th, 50th, 51st, 52nd, 53rd, 53rd, 53rd, 54th, 55th The above is all the contents of the article "how to achieve API Interface current limit". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.