Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to understand Redis avalanche, breakdown, penetration, preheating and degradation

2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to understand Redis avalanche, breakdown, penetration, preheating, degradation". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand Redis avalanche, breakdown, penetration, preheating, degradation"!

Cache breakdown

Cache breakdown cannot be understood by name at all, and it is easy to get confused with another word-cache penetration. Cache breakdown means that a key has been carrying high concurrency, which means that a large number of requests get the corresponding value of the key.

And this key suddenly expires at some time, does that mean that a large number of requests can not get data in the cache, but to request the database, which is likely to cause the database to be destroyed. This is cache breakdown.

So now that the problem is known, how to deal with it? This is relatively simple. Since this key is popular, do not set the expiration time. If the data of the key is updated, update it by mutex.

Why use mutexes? If you don't use mutexes, it can easily lead to data inconsistencies, so here you have to sacrifice a little bit of efficiency in order to ensure the consistency between the cache and the database.

Cache avalanche

I don't know where all my friends come from, but there is a dialect on our side called "Avalanche", which means things have been smashed. The Redis avalanche here seems to be a little similar. First, we need to know what a Redis avalanche is.

Redis avalanche is generally called cache avalanche, which means that at a certain time node, a large number of key fails, resulting in a large number of requests that can not get data from the cache and request the database. According to the picture above, let's draw what the avalanche looks like:

The black part above indicates that the cache is invalid, which means that all requests need to query the data in the database. Then the pressure on the database must be greatly increased, if it is in the scenario of ultra-high concurrency such as the first-line Internet, the database goes down directly.

Rebooting is also useless, because after rebooting, there will be a huge influx of traffic, and then continue to be downtime. So it is of great significance to prevent the occurrence of cache avalanches.

Add random values to the cache avalanche solution

The above has described in detail what a cache avalanche is, how it happened, and how to prevent it?

It's simple, because as mentioned above, cache avalanches are caused by a large number of key failures on nodes at a certain time, so the problem now is how to prevent a large number of key failures on nodes at the same time.

The simplest case is to spread the expiration time of key, that is, to add a random value when setting the expiration time of key, so that the problem of cache avalanche can be solved perfectly.

But you think I'm done here? Since it's a full arrangement, I'm sure I won't just tell you a solution. Keep looking.

Locking of cache avalanche solution

Many people may see that this scheme is not accepted, isn't locking limiting concurrency? Locking will inevitably lead to blocking. If it is locked, then the execution will look like this:

The process is like this: when multiple requests arrive at the business system at the same time, only one thread can acquire the lock, and then continue to cache or query the data in the database, and then the later process is the same as the previous one. Release the lock after execution, and then other threads scramble for the lock, and then repeat the previous process.

The advantage of this scheme is that it can protect the database from being linked, but the disadvantage is that the degree of concurrency is very low.

In fact, the above scheme can be further optimized:

This is if it is not available in the cache, then go to the serial access data to see that it does not have to be serial here, but can cooperate with the thread pool to control a certain number of concurrency.

Although there are many disadvantages, it is also a solution. Whether you need it or not depends on the actual business scenario. After all, there are no useless technical solutions, only technical solutions that are not suitable for business scenarios (manual dog head).

Cache penetration

Cache traversal means that a key that does not exist has been accessed all the time, and it turns out that there is no such data in the database. As a result, all requests to access the key are requested directly to the database. If it is a scenario with high concurrency, it is easy to destroy the database. Have you noticed that some of the things we do are to protect the "weak database"?

Now that the problem is known, how can we solve it?

Cache empty data for cache traversal solution

What do you mean, cache empty data? It is assumed that some key data does not exist, then it is fine to save a NULL, but do not forget to set the expiration time, because it is assumed that the record of id=3 does not exist, and then no data is queried in this visit. What is stored in the cache is null. If a new data is recorded as 3 after a while, if the cache does not set the expiration time, then this data will never be obtained.

Bloom filter for cache traversal solution

Bloom filter? What exactly does this thing mean?

Bloom filter is a kind of data structure, or more accurately, a probabilistic data structure, because it can judge that an element must not exist or may exist.

This sentence has fooled a lot of people, and I have to make you clear today. The Bloom filter is an array of bit, a long array of bit, and a series of hash functions. Look at the following picture first.

Let's take an example now. Suppose there are two people, Xiaoqiang and Wangcai, who get the subscript after three times of hash. (the Bloom filter does not store elements, only marks whether an element exists or not.)

After passing the above three hash, Xiaoqiang gets subscripts of 2, 4 and 5, respectively, so the positions of 2, 4 and 5 of the array will be set to 1, which is what it looks like at this time.

Similarly, Wangcai gets the subscripts of 3, 7 and 11 after the above three hash, then the positions of 3, 7 and 11 of the array will be set to 1, which is what it looks like at this time.

Now suppose a 007 passes through the above three hash and the subscript is 11, 13, 15, respectively. Because 13, and 15 positions are 0, it must be judged that 007 does not exist. But now there's another one.

9527 after the above three hash to get the subscript are: 2, 5, 7, but you will find that the three positions are all 1, so does this mean that 9527 exists or does not exist?

From our explanation above, it does not exist before 9527, but because of the hash conflict, the three subscript values of 9527 also fall in the subscript position that has been set to 1, which makes it impossible to judge whether 9527 exists at this time. This is how the Bloom filter works.

How about a piece of code to suppress the shock?

Let's use the classes under the google package to test. The first step is to add dependencies

Com.google.guava guava 30.1-jre

The code is as follows (I have written a detailed explanation in the comments, this is the code that can be used in actual production)

Public class BloomFilterDemo {public static void main (String [] args) {/ * create an insert object for 100 million Bloom filter with a false positive rate of 0.01% * does not exist * does not exist * / BloomFilter bloomFilter = BloomFilter.create (Funnels.stringFunnel (Charset.forName ("utf-8")), 100000000, 0.0001) BloomFilter.put ("death"); bloomFilter.put ("Java"); bloomFilter.put ("Redis"); System.out.println (bloomFilter.mightContain ("Redis")); System.out.println (bloomFilter.mightContain ("death")); System.out.println (bloomFilter.mightContain ("knock")); System.out.println (bloomFilter.mightContain ("Java"));}}

Result

End.

Wait a minute... Cache penetration, warm-up, downgrade you haven't said yet. Oh, I really thought this article was over.

So how does the Bloom filter solve the problem of cache penetration? Now that we know the principle of the Bloom filter, we can quickly determine whether a key exists in the database through the Bloom filter. If it is possible, then go to the database query. If it does not exist in the Bloom filter, then you need to go to the database query.

Cache warm-up

What the heck is this? Why do you have so many problems with a cache? why do you need caching?

The so-called cache warm-up is to pre-set some frequently used data to the cache when the system is started, so as to avoid querying in the database when it is used.

This is cache warm-up, famous, actually very simple, this cache warm-up I often use in the actual scene.

Another way is to add a cache refresh page to add some key that may be hot spots to the cache through human intervention.

Cache degradation

When there is a sudden surge in traffic (for example, when everyone is browsing their cell phones on the subway at the end of the day), when there is something wrong with the service (such as slow response time or non-response), or when non-core services affect the performance of the core process, you still need to ensure that the service is still available, even if it is damaging.

The system can be automatically downgraded according to some key data, and the ultimate goal of the downgrade is to ensure the availability of core services, even if it is harmful. However, the core services of some businesses cannot be downgraded. This is a kind of thought of losing pawn and keeping Shuai.

Thank you for your reading, the above is the content of "how to understand Redis avalanche, breakdown, penetration, preheating, degradation". After the study of this article, I believe you have a deeper understanding of how to understand Redis avalanche, breakdown, penetration, preheating and degradation, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report