I haven't encountered these three problems. I'm sorry to say that I used redis

Caching is an indispensable part of Internet applications . When it comes to caching , I have to ask three classic questions —— Cache penetration 、 Cache breakdown and cache avalanche , I call them the three brothers of cache problems .

Cache has two main functions ： To improve access speed ; Second, to protect the database . When the business is small , Usually there is no big problem . But when the business volume increases , If the cache is not properly used , The three brothers will come as promised , Let you experience the cruelty of reality .

If the three brothers don't come, they will be gone , One light will affect the system performance , The most important thing is to directly drag down the database , Cause system paralysis . therefore , We should not take it lightly , Be prepared for the unexpected .

Cache penetration

When a request arrives at the server , Under normal circumstances, the following process is followed .

Follow the steps below ：

1. The query cache , Return... If hit
2. Cache miss , Then query the database
3. Write the data queried from the database into the cache and return

If you do this step by step every time , It's all right . however , I'm afraid of everything, but . But there are always exceptions , If the requestor is interested in a （ In the database ） Access to data that does not exist at all , So follow the above process , The cache is useless . Because it doesn't exist , So it will not be written to the cache , In this way, every request will be sent to the database , This phenomenon is called 「 Cache penetration 」 了 .

If you only query nonexistent data because of individual requests , That's no big deal . But cache penetration is usually accompanied by some 「 Malicious request 」 And come , It is usually an influx of requests in a short time . If you let it go , Just wait for the database to go down .

How to solve

Understand the causes of cache penetration , Then the solution is clear . We can start from two aspects ：

• Cache nonexistent records
• Filter non-existent requests

what ？ How to cache nonexistent records ？ It's very simple , If you can't find it in the database , Then cache the value Set to null that will do （ Pay attention to setting reasonable expiration time according to business characteristics ）.

Filter non-existent requests , When a request arrives at the server , such as ：

GET /api/user/1

The filter will first determine whether the resource exists , Release if present , Return directly if it does not exist , So as to protect the system .

There are also mature schemes for this method . Such as Bloom filter and cuckoo filter （ Upgraded bronbronbron filter ）.

Double reinforcement

Whether the request for a nonexistent resource is intentional or unintentional , It's not what we want . therefore , We can set an access frequency , Frequently within a certain period of time （ Beyond the limit of normal users ） visit , The requesting party may be restricted （ Such as IP Limit ）. in addition , Some interfaces can be authenticated , You have to log in to access .

Cache breakdown

General situation , We will set an expiration time for the cache . If the cache of a resource expires （ Or you haven't had time to cache ）, An instant influx of requests to query this resource , Then these requests will rush to the database , At this time , Our database is miserable , Maybe I will die every second . This situation is called cache breakdown .

How to solve

There are two ways to solve cache breakdown ：

• Never expire
• Lock

First look at the first one , Hot resources are often accessed in large numbers in a short time , For such resources, we can not set the expiration time （ Never expire ）, Update the cache through the program when the resources change .

Let's look at the second one , We can use a lock （ commonly JVM Level lock ） To avoid breakdown . When the cache expires , The request to come in , First get a lock （ That is, the qualification to query the database ）, Then go to query the database , Finally, add the data to the cache . This will ensure the same time （ A service instance ） There will only be one request to check the database , Other threads wait until the cache has a value , Then go to cache to fetch .

Lock pseudo code example ：

 public String getData() throws InterruptedException {
    
    //  Fetch from cache 
    String result = getFromCache();
    //  Take it and return to 
    if (Objects.nonNull(result)) {
    
        return result;
    }
    
    //  Attempt to acquire lock 
    if (!lock.tryLock()) {
    
        //  If locking fails, take a break 
        Thread.sleep(10);
        return getData();
    }

    //  If the lock is successful, go to the database to get the value 
    result = getFromDB();
    //  Retrieve and put it into the cache 
    setFromCache();
    return result;
}

Cache avalanche

Cache avalanche means , A lot of... In the cache key Collective expiration at the same time , Result in a large number of requests pouring into the database .

Some people call cache service unavailable for some reasons as cache avalanche , I don't think it's appropriate to call it that .

Imagine what an avalanche is , A large number of snowflakes jumping down from the mountain is an avalanche . Then the scene corresponding to the cache , We can Redis As a mountain , and Redis Inside key It's snowflakes .Redis In large quantities key Simultaneous failure , It's like a lot of snowflakes falling down on the mountain at the same time . So avalanches are used to describe a large number of key Centralized failure is obviously more appropriate . The cache service failure should be attributed to the cache service failure , You can use a cache cluster to improve availability .

How to solve

To solve the problem of cache avalanche , There are two ways of thinking ：

• Scatter expiration time
• Never expire

Scattered expiration times are easy to think of , Since the avalanche is caused by key Collective expiration , Then the problem can be avoided by dispersing their expiration time .

Another way to think about it , It is the same as solving cache breakdown , Set the cache to never expire .

The never - expired scheme has certain limitations , It depends on the specific business , You can't brutally set all caches to not expire .

summary

Each technical solution has its applicable business scenario , They all have their limitations . No one solution can deal with all the problems , Appropriate is good . But we can still see some general ideas from the above scheme , such as ： Return as soon as possible . How to understand ？ Is to make the call chain as short as possible , Never release those that can be stopped before the application service （ Bloon filtration ）; Never look up the database if you can get it from the cache .

More exclusive highlights are in my new book 《Spring Boot Interesting practical class 》 in .