Understand redis cache avalanche, cache breakdown and cache penetration in one article

This article brings you relevant knowledge about Redis, which mainly introduces the relevant content about cache avalanche, cache breakdown and cache penetration. Let’s take a look at it together. I hope it will be helpful to you. Everyone is helpful.

Recommended learning: Redis video tutorial

About Redis’ high-frequency issues, cache avalanche, cache breakdown and cache penetration It must be indispensable. I believe everyone has been asked similar questions during interviews. Why are these questions so popular? Because when we use Redis cache, these problems are easy to encounter. Next, let’s take a look at how these problems arise and what the corresponding solutions are.

Cache avalanche

First let’s take a look at cache avalanche. The concept of cache avalanche is: a large number of requests are not processed in the Redis cache, resulting in requests flooding into the database. , and then the pressure on the database increases dramatically.

The reasons causing cache avalanche can be summarized as two:

• There is a large amount of data in the cache that expires at the same time, so a large number of requests are sent to the database at this time.
• The Redis cache instance fails and cannot handle a large number of requests, which also causes the requests to go to the database.

Let’s take a look at the first scenario: a large amount of data in the cache expires at the same time.

A large amount of data in the cache expires at the same time

Combined with the legend, it means that a large amount of data expires at the same time, and then there are many requests to read the data at this time. Of course, a cache avalanche will occur, causing a dramatic increase in database pressure.

Solutions for a large amount of data to expire at the same time

To deal with the problem of a large amount of data to expire at the same time, there are usually two solutions:

• Add a random time to the data expiration setting: that is, when you use the expire command to set the expiration time for the data, add a random time. For example, data a expires in 5 minutes, and 10-120 seconds are randomly added to the 5 minutes. This prevents large amounts of data from expiring at the same time.
• Service degradation: that is, when a cache avalanche occurs, (1) if the access is not core data, when there is no cache hit, the database will not go to the database, and preset information, such as null values ​​or errors, will be returned directly. Information; (2) When accessing core data and the cache misses, database query is allowed. In this way, all requests that are not core data will be rejected and sent to the database.

#After looking at the situation where a large amount of data expires at the same time, let’s take a look at the situation where the Redis cache instance fails.

Cache avalanche caused by Redis cache instance failure

In this case, Redis cannot process the read request, and the request will naturally be sent to the database.

Generally speaking, we have two ways to deal with this situation:

• Do a good job of service circuit breaker/request current limiting in the business system.
• Precaution in advance: Build a Redis high-reliability cluster, such as master-slave cluster switching.

Service circuit breaker means that when Redis fails, requests for access to the cache system are suspended. Wait until Redis returns to normal before opening the request for access.

In this way we need to monitor the running status of Redis or the database, such as MySQL's load pressure, Redis's CPU usage, memory usage and QPS, etc. When it is discovered that the Redis instance cache has collapsed, the service will be suspended.

This situation can effectively place a large number of requests and put pressure on the database. However, access requests will be suspended, which will have a great impact on the business end.

Therefore, in order to reduce the impact on the business end, we can use the request current limiting method to control QPS and avoid too many requests to the database. For example, in the illustration below, there are 20,000 requests per second, but it was down due to a Redis failure. Our current limiting operation reduced the qps to 2,000 per second, and the database still had no problem processing 2,000 qps.

Cache breakdown

Cache breakdown means that individual frequently accessed hotspot data cannot be cached, and then requests are poured into the database. It often happens when hotspot data expires.

Regarding the cache breakdown problem, we know that these are hot data that are accessed very frequently, so the processing method is simple and crude, and the expiration time is not set directly. Just wait until the hotspot data is not accessed frequently and then handle it manually.

Cache Penetration

Cache avalanche is something special. It means that the data to be accessed is neither in the Redis cache nor in the database. When a large number of requests enter the system, Redis and the database will be under tremendous pressure.

There are usually two reasons for cache penetration:

• The data is accidentally deleted, resulting in no data in the cache and database. However, the client doesn't know this and is still requesting frantically.
• In the case of malicious attacks: that is, someone is targeting you to check for data that is not available.

For cache penetration, you can refer to the following solutions:

• is to set a null value or default value for the cache value. For example, when cache penetration occurs, set a null value/default value in the Redis cache. Subsequent queries for this value will directly return this default value.
• Use Bloom filter to determine whether the data exists and avoid querying from the database.
• Perform request detection on the front end. For example, filter some illegal requests directly on the front end instead of sending them to the back end for processing.

The first and third points are easier to understand and will not be described here. Let’s focus on the second point: Bloom filters.

Bloom filter

The Bloom filter is mainly used to determine whether an element is in a set. It consists of a fixed-size binary vector (can be understood as a bit array with a default value of 0) and a series of mapping functions.

Let’s first take a look at how the Bloom filter marks a data a:

• In the first step, multiple mapping functions (hash functions) will be used. Each Each function will calculate the hash value of this data a;
• In the second step, these calculated hash values ​​will be modulo the length of the bit array respectively, so that each hash value on the array is obtained position;
• The third step is to set the positions obtained in the second step to 1 on the bit array respectively.

After these 3 steps, data labeling is completed. Then you need to query the data when it is not there:

• First calculate the multiple positions of this data in the bit array;
• Then check these positions of the bit array respectively bit value. Only if the bit value of each position is 1, it means that the data may exist, otherwise the data must not exist.

Combined with the picture below, the basic principle is like this.

Recommended learning: Redis video tutorial

The above is the detailed content of Understand redis cache avalanche, cache breakdown and cache penetration in one article. For more information, please follow other related articles on the PHP Chinese website!