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

This article introduces the relevant knowledge of "what is the method to solve cache avalanche, breakdown, penetration". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations! I hope you can read it carefully and be able to achieve something!

one。 Cache avalanche

Cache avalanche generally means that a large number of key expires at the same time, when a large number of requests are sent to the database at the same time, resulting in a sudden increase in database pressure and database downtime.

Solution:

First of all, we can avoid setting the same expiration time for a large amount of data. We can set a random time (1-3 minutes) for each piece of data when we use the command EXPIRE command to set the time for each piece of data, so that different data have different expiration time, which ensures that the data will not expire at the same time.

In addition to setting the expiration time, you can also use service degradation to deal with cache avalanches. The so-called service degradation is the use of different processing mechanisms when a cache avalanche occurs.

When the business application accesses non-core data (such as some attributes of some e-commerce), it pauses to query the data from the cache, but customizes some predetermined data, null values or error messages.

When the business application accesses the core data (such as the price inventory of electrical goods), we allow the query cache, if the cache does not hit, we can query the database to query the data through the database.

In this way, only part of the core data of the query will be sent to the database, reducing the pressure on the database.

In addition to a large amount of data that expires at the same time, another solution can lead to cache avalanches, that is, Redis downtime, there is no way to process requests, so all requests go to the database layer, resulting in cache avalanches.

Generally speaking, the number of requests processed by Redis can reach tens of thousands of levels, while the processing requests of databases can reach thousands of levels. Redis is more than 10 times the size of the database. When Redi downtime occurs, it is conceivable that 10 times more requests will be sent to the database. The database will definitely cause downtime.

At this point, if the Redis goes down, we need to use other schemes to respond to the cache avalanche. Solutions are as follows:

1. It is to do the service breaker or request current limit mechanism in the business system.

Service breakers say that when a cache avalanche occurs, in order to prevent a chain of database crashes, or even the entire system crash, we can suspend access to the cache. Generally speaking, by stopping the caching service, when the request comes, we do not process the request, wait until the Redis service is restored, and then process the request, so that when a large number of requests are sent, we can ensure the normal operation of the data.

During the running time of the business, we can look at the load, cache and database cpu share and memory utilization and the number of access requests through the server. When the number of requests on the server where the database is located suddenly increases, a cache avalanche occurs, and we can start the service circuit breaker and suspend user access, thus reducing the access to the database.

In this way, the database can be well protected, which has a great impact on the business. In order to minimize the impact on the business, we can adopt current-limiting operations. In popular terms, current-limiting operations, such as 10,000 visits per second at the business layer, can limit access to Redis services because there are too many circuit breakers. At this time, we only allow 1,000 requests per second to operate the database, which can avoid a large number of requests directly requesting the database, resulting in database downtime.

two。 It is a reliable cluster of Redis built in the service. When the master node goes down, a slave node is selected as the new master node to continue to provide services, which effectively avoids the cache avalanche problem caused by cache downtime.

two。 Cache breakdown

Cache breakdown means that when there is no way to process the hotspot data in the cache for a request that is very frequent, then all the requests for accessing the hotspot data are requested to the database, resulting in increased pressure on the database and affecting the operation of other businesses. The solution of cache breakdown is relatively straightforward. For particularly frequent data requests, we do not set the expiration time, so that the access to hot data is carried out in Redis, while the high performance of Redis can well handle concurrent access.

three。 Cache penetration

Cache traversal means that the data is neither in the Redis nor in the database, resulting in no data when the cache is requested. Indeed, when you go to access the database, you will find that there is no data in the database. The cache is equivalent to no setting, and the application can not read messages from the database, so the cache is the same as none. If there is a large amount of data access, it will bring great pressure on the data.

Generally speaking, there are two situations under which cache penetration can occur:

The operation of the business layer is wrong, and the cached data and the data of the database are deleted by mistake, so there is no data in the database and cache.

Malicious attack: special access to data not available in the database.

There are three main solutions:

1. Cache null or default values.

Once cache traversal occurs, we can cache a null value in Redis or negotiate with the business layer to determine the default value for the queried data. Then, when the subsequent requests sent by the application are queried, the null and default values can be read directly from the Redis and returned to the business, which prevents all requests from going to the database layer and keeps the database running normally.

two。 Use Bloom filter to quickly determine whether the data exists and avoid querying from the database.

Explain the principle of Bloom filter. The Bloom filter consists of data with an initial value of 0 and N hash functions, which can quickly determine whether the data exists or not. If we want to tag some data, we can mark it in three operations.

First, N hash functions are used to calculate the hash value of this data, and N hash values are obtained.

Second, take the N hash values corresponding to the hash value corresponding to the length of the bit array to get the position in the data where each hash value is located.

Third, we set the hash value corresponding to bit in the two-point array to 1, which completes the data marking in the Bloom filter.

3. Request detection is performed at the front end of the request entry. One of the reasons for cache penetration is that there are a large number of malicious requests to access data that does not exist. An effective solution is to legally detect the accessed requests, filter the malicious requests directly, and prevent the requests from reaching the cache and database layer. In this way, cache penetration does not occur.

The solutions to these three major problems are summarized in the table below.

Problem cause solution cache avalanche

A large amount of data expires at the same time

Cache server downtime

Set the expiration time plus random time to the cache to prevent a large amount of data from expiring at the same time.

Service degradation

Service circuit breaker, request current limit

Redis cache main memory cluster

Cache breakdown access hotspot data does not exist or expires

Do not set the expiration time for hot spot data, but keep it consistently

The cache breaks through data that is not in the cache or database for access.

Cache null or default

Quick judgment using Bloom filter

The front end of the request entry checks the validity of the request

Use the following options as much as possible:

For cache avalanche, set the expiration time of hotspot key reasonably, and build a cluster with high cache reliability.

For cache breakdown, do not set the expiration time when caching hot data that is accessed very frequently.

For cache penetration, the request is detected at the entrance and exit of the front-end interface in advance to standardize the deletion operation of the database and avoid accidental data deletion. Using the Bloom filter.

This is the end of the content of "what is the solution to cache avalanche, breakdown, penetration". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.