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

This article introduces the knowledge of "how to use spring-cache code to solve the cache breakdown problem". In the operation of actual cases, many people will encounter such a dilemma, so 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!

Current defects in the text

First of all, why do the current plans circulated on the Internet have poor landing? because they all lack a real scene that can be combined with SpringBoot, they are basically separated from SpringBoot, and only stand at the level of Java to analyze. So the question is, are there any companies that only use SpringMvc but don't use SpringBoot? Therefore, this paper attempts to combine this scheme with SpringBoot to talk about a really feasible and landing scheme!

Of course, let's first talk about several sets of plans currently circulating on the Internet, which are not reliable in the end!

(1) Bloom filter

I won't say much about the Bloom filter, which is understood here as a filter that is used to quickly retrieve whether an element is in a collection; then when a request comes, quickly determine whether the requested key is in the specified collection! If the description is valid, it will be released. If not, the intercept is invalid. As for implementation, the major bloggers also said that they used the google

Com.google.guava guava 19.0

There are ready-written java classes in this package for you to use, of course, I will not post the demo code, grab a lot! Of course, it seems to be perfect! Everything is so appropriate!

However, at this point, I really ask, do you really use this plan?

If I guess correctly, few people should have encountered the problem of cache breakdown.

What's more, prove the correctness of this statement.

One of the biggest problems with this solution is that the Bloom filter does not support reverse deletion. For example, the number of active key in your project is only 1000w, but the total number of key is 5000w, then all the 5000w key will be stored in the Bloom filter!

Until one day, you will find that the filter is too crowded, the misjudgment rate is too high, and you have to rebuild it!

So, do you think this is really reliable?

So where does the term Bloom filter come from? Everyone must be curious about whether it is right!

Of course, it is the xx organization ~ ~ here to protect their dog's head ~ ~ remember, in order to cut leeks, they must choose some schemes that look very high-end, but the landing is extremely unreliable (this is also the benchmark to distinguish whether an organization is cutting leeks or really has a level, Xiaobai does not understand, it is easy to be cheated) ~ ~ see here, really ashamed, my first article also wrote this plan, but in the landing process. Something is wrong (the review article of 10,000 words is omitted here, brother Yan rubbish).

(2) cuckoo filter

Then, in order to solve the problems of weak query performance, low space utilization efficiency and no support for reverse operation of Bloom filter, another article was born, advocating the use of Boog filter to solve the problem of cache breakdown!

However, the amazing thing is that basically all the articles are talking about how powerful the cuckoo filter is, but there is no landing plan.

Remember, we usually write code, it must be how convenient to come! And remember, the interview is one thing, the code landing is another.

So, what is the really simple solution? Come on, let's take it step by step.

Real plan

Suppose you are using the version of springboot-2.x, and in order to be able to connect to redis, you add the following dependencies in the pom file

Org.springframework.boot spring-boot-starter-data-redis

Then, we modify the application.yml

Spring: datasource:... Redis: database:... Host:... Port:... (save trouble, not all posted)

Ok, at this point, we have to talk about spring-cache. After Spring3.1, annotation caching technology was introduced, which in essence is not a specific cache implementation, but an abstraction of cache use. By adding a small amount of custom annotation to the existing code, you can achieve the effect of returning objects using cached objects and caching methods. Spring's cache technology has considerable flexibility. It can not only use SpEL (Spring Expression Language) to define cache key and various condition, but also provide out-of-the-box cache temporary storage scheme, but also support integration with mainstream professional cache.

For example, we often have such a logic in the code that before the execution of the target method, we will first query whether there is any data in the cache according to the key, and then directly return the value corresponding to the key in the cache, and no longer execute the target method; if not, execute the target method, query the corresponding value in the database, and store it in the cache in the form of key-value pairs.

If we do not use an annotation framework such as spring-cache, your code will be filled with a lot of redundant code, and after using this framework, take the @ Cacheable annotation as an example, which indicates that the return result of the method can be cached.

That is, the return result of the method is placed in the cache so that when the method is called later with the same parameters, the value in the cache is returned without actually executing the method.

So, that's all your code needs to write.

@ Override@Cacheable ("menu") public Menu findById (String id) {Menu menu = this.getById (id); if (menu! = null) {System.out.println ("menu.name =" + menu.getName ());} return menu;}

In this example, the findById method is associated with a cache called menu. When the method is called, the menu cache is checked, and if there is a result in the cache, the method is not executed.

Ok, speaking of which, in fact, everyone knows things! Let's start with our topic: how to solve the cache breakdown problem! By the way, talk about penetration and avalanches!

Come on, let's recall the concepts of cache breakdown, penetration, and cache avalanche!

Cache penetration

In high concurrency, when querying a non-existent value, the cache will not be hit, resulting in a large number of requests falling directly to the database, such as querying a non-existent activity in the active system. Talkative sentence: cache penetration refers to the request for data that is not available in the cache and database!

For the cache traversal problem, there is a very simple solution, that is, cache null value ~ the data that cannot be fetched from the cache is not fetched in the database, and a null value is returned directly.

So in spring-cache, there is a configuration that looks like this.

Spring.cache.redis.cache-null-values=true

With this configuration, you can cache the null value. It is worth mentioning that the cache time should be set less, for example, 15 seconds. If the setting is too long, the normal cache will not work.

Cache breakdown

Under high concurrency, a specific value is queried, but at this time the cache expires and the cache misses, resulting in a large number of requests falling directly to the database, such as querying activity information in the active system. but the active cache suddenly expired during the activity. A mouthful: cache breakdown means that there is no cache in the request, and there is some data in the database!

Remember, the easiest way to solve the breakdown is to limit the current! As for how to limit, in fact, each can show his magical powers! For example, the Bloom filter and cuckoo filter mentioned in other articles are just one of the ways to limit the current! Even, you can use some other current-limiting components!

Here is another configuration of spring-cahce!

After the cache expires, if multiple threads request access to some data at the same time, it will go to the database at the same time, resulting in an instant increase in the load of the database. Spring4.3 provides a new parameter "sync" for the @ Cacheable annotation (boolean type, default is false). When it is set to true, only one thread's request goes to the database, and the other threads wait until the cache is available. This setting reduces instant concurrent access to the database.

See here! Isn't this a current-limiting scheme?

So the solution is to add an attribute sync=true, which is fine. The code looks like this

Cacheable (cacheNames= "menu", sync= "true")

After using this property, you can instruct the underlying layer to lock the cache so that only one thread can enter the calculation, while the other threads block until the return result is updated to the cache.

Of course, when I see this, someone will argue with me! Here's his problem!

This is only for the current limit of the single machine, not the current limit of the whole cluster! In other words, suppose your cluster has 3000 pod, and in the worst case, each pod on 3000 pod will initiate a request to query the database, which will still lead to insufficient database connections, and other resource problems!

I can only say about this question! Young man, as long as your company's products reach this scale of traffic, you will not be reading my article at the moment! What you care about right now is:

(1) Hey, buy Shenzhen Bay No.1 or Shenzhen Bay residence, entanglement!

(2) the US stock market fell again yesterday, losing two more homes.

(3) the order was withdrawn ahead of schedule yesterday, and tens of thousands of less money was earned.

.... (omit 10,000 words)

Of course, if you have to solve it, there is a way. There are tricks in spring's aop. For example, @ Transactional's Advice is TransactionInterceptor, then cache also corresponds to a CacheInterceptor. As long as we change the CacheInterceptor, this aspect can be solved. Make a distributed lock in it! The pseudo code is as follows

Flag: = take the distributed lock if flag {go to the database query and cache the results} {sleep for a period of time and try to get the value of key again}

However, I still want to mention, there is really no need to remember a sentence, based on reality, whenever your business reaches that level, you can achieve regional deployment, and you can completely avoid this kind of problem.

Cache avalanche

In the case of high concurrency, a large number of cache key expires at the same time, resulting in a large number of requests falling on the database, such as a lot of activities in the active system at the same time, but all active caches expire at a certain point in time.

So the simplest solution to this problem is to add a random value to the expiration time!

But the trouble is that when we use the @ Cacheable annotation, the native feature cannot directly set the random expiration time.

To be honest, there is no good way to inherit RedisCache, enhance it, rewrite the put method, and bring random time!

This is the end of "how to use spring-cache code to solve the cache breakdown problem". Thank you for 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.