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

This article will explain in detail the example analysis of Redis cache penetration, cache breakdown, cache avalanche and hot Key. The editor finds it very practical, so I share it with you for reference. I hope you can get something after reading this article.

Using Redis will inevitably encounter the problems of Redis cache penetration, cache breakdown, cache avalanche and hot Key. Some students may just use Redis to access, basically using the tool class encapsulated in the project to operate. But as developers, we may encounter the above problems when using Redis, and you may not know what these nouns mean, so let's discuss them now.

First of all, the logic of using Redis is like this.

Cache penetration

It is for data that is not in the database or cache. Scenario: when the client initiates a query, the database will be checked if it is not in the cache, and the error message will be returned to the client. This is no problem, it seems that the logic is perfect, but there is a loophole here, that is, no matter what kind of Key comes to check, we will accept its request, which may be caught by hackers and initiate a large number of requests, and the Key is not available in our system, and the corresponding value cannot be found in the database. This Key is called illegal Key. So when a large number of such requests come, will not hit the Redis, and then call the DB, when the DB instantly received so many connections, the DB may not hold up and hang up. This is a hidden loophole that hackers or malicious attackers will seize to attack your system and paralyze your system.

To take this into account in the actual development, we can add a layer of filtering at the system level to intercept the key that the system considers illegal and return the error message directly to the client. How to add this layer of filtering, which is illegal Key should be determined according to the actual business logic, only the solution is given here.

Cache breakdown

It is for data that is not in the cache but in the database. The scenario is that when the Key expires, if a large number of requests suddenly pour in to request the same Key, these requests will not hit the Redis, but will be requested to the DB, resulting in too much pressure on the database, or even hang up.

The solution to this problem is:

1. Set the hotspot Key, automatically detect the hotspot Key, and increase the expiration time of the hotspot Key to never expire, or logically never expire. The specific setting method will be described later.

2. Add mutex. When it is found that the Redis has not been hit, when you check the database, add a lock on the operation of updating the cache. Whoever gets the lock will update it. At the same time, after getting the lock, get it from the cache again and return if there is one. If not, check the database and update it. (double check)

Cache avalanche

It means that a large number of Key fails at the same time, and the requests for these Key will be called to DB, which will also lead to excessive pressure on the database and even hang up.

The solution to this problem is to spread the failure time of Key, add a random value to the uniform failure time, or use a more advanced algorithm to spread the failure time.

Hot Key issues

For hotspot data, we can set hotspot Key to expire for a long time, or logically never expire. What do you mean?

This means that if we set the expiration time of hotspot data to 24 hours, we can use a listener to listen to the hotspot data and asynchronously set up a thread to update the hotspot data when it is detected that it is about to expire. It can achieve the effect that never expires logically.

In addition, we need to have a hot spot data automatic detection mechanism. That is, there is a monitoring platform to monitor the number of requests, expiration and database searches for a certain period of time in each key, to analyze whether the key is hot data, to upgrade key to hot key when a certain threshold is reached, and then follow the logic of hot data.

Only ideas are provided here, and I will not elaborate on how to achieve it. If there is a better way, you are welcome to leave a message.

This is the end of this article on "Redis cache penetration, cache breakdown, cache avalanche, hot Key example analysis". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.