Redis cache penetration, avalanche, breakdown interpretation

When we request to query a record, we first query in redis and then query in mysql and find that the record cannot be found , but the request will hit the database every time, causing the pressure on the background database to increase dramatically. These requests are like "penetration" "It hits the database directly as if it were cached. This phenomenon is called cache penetration. This phenomenon is called cache penetration, and this redis becomes a decoration.

When maliciously attacking a website, using a non-existent ID to query data will generate a large number of requests to the database. It may cause your database to crash due to excessive pressure.

solution

Option 1: Empty object cache or default value

Once cache penetration occurs, we can cache a null value or a default value negotiated with the business layer in Redis for the queried data (for example, the default value of inventory can be set to 0). Immediately afterwards, when subsequent requests sent by the application are queried, the null value or default value can be read directly from Redis and returned to the business application, avoiding the need to send a large number of requests to the database for processing, and maintaining the normal operation of the database. .

If Redis cannot find the data and the database cannot find it either, we save the Key value into Redis and set value="null". When we query through this Key next time, we do not need to query the database again. There is definitely a problem with this method of processing. If the non-existent Key value passed in is random every time, then there is no point in storing it in Redis. And with more and more cached summer vacations, the pressure on Redis is increasing, and the cached Key can have an expiration time to share the pressure.

Option 2: Bloom filter

Storing the key of existing data in the bloom filter is equivalent to blocking a bloom filter in front of redis.
When there is a new request, first check whether it exists in the Bloom filter:
If the data does not exist in the Bloom filter, it will be returned directly;
If the Bloom filter already exists, query the cached redis. If it is not found in redis, query the Mysql database again.

Bloom Filter was proposed by Bloom in 1970. It's actually a long binary vector and a series of random mapping functions. Bloom filters can be used to retrieve whether an element is in a collection.

In a word: it consists of a bit array with an initial value of zero and multiple hash functions, used to quickly determine whether an element exists in the set.

Cache breakdown

definition

When a large number of requests query a key at the same time, and the key happens to be invalid at this time, a large number of requests will be hit to the database (simply put, the hotspot key suddenly becomes invalid and mysql will be hit violently).

The main reason for cache breakdown is that we set an expiration time for the data in the cache. If a large amount of data is obtained from the database at a certain time and the same expiration time is set, the cached data will expire at the same time, causing cache breakdown.

It was cleared naturally when the time came, but it was still visited.

When deleting the key, it was suddenly accessed.

solution

Solution 1: Hotspot data never expires

For hotspot data, if the business allows it, a key that will never expire can be set for the hotspot key.

Solution 2: Mutually exclusive exclusive lock to prevent breakdown

Using the idea of distributed lock, it is ensured that for each Key, only one thread queries the back-end service at the same time. While a certain thread is querying the back-end service, other threads do not have permission to obtain the distributed lock and need to wait. After querying, they will return Write to Redis, and other request threads will query in Redis. Of course, this will cause the performance of the system to deteriorate.

The sample java code is as follows:

public User findUserById2(Integer id) {
    User user = null;
    String key = CACHE_KEY_USER+id;

    //1 先从redis里面查询,如果有直接返回结果,如果没有再去查询mysql
    user = (User) redisTemplate.opsForValue().get(key);
    if(user == null) {
        //2 大厂用,对于高QPS的优化,进来就先加锁,保证一个请求操作,让外面的redis等待一下,避免击穿mysql
        synchronized (UserService.class){
            user = (User) redisTemplate.opsForValue().get(key);
            //3 二次查redis还是null,可以去查mysql了(mysql默认有数据)
            if (user == null) {
                //4 查询mysql拿数据
                user = userMapper.selectByPrimaryKey(id);//mysql有数据默认
                if (user == null) {
                    return null;
                }else{
                    //5 mysql里面有数据的,需要回写redis,完成数据一致性的同步工作
                    //setnx 不存在才创建
                    redisTemplate.opsForValue().setIfAbsent(key,user,7L,TimeUnit.DAYS);
                }
            }
        }
    }
    return user;
}

cache avalanche

definition

Cache avalanche refers to the expiration time of large batches of cached data, and the huge amount of query data, causing excessive pressure on the database and even downtime. Different from cache breakdown, cache breakdown refers to the concurrent query of the same data. Cache avalanche means that different data have expired, and a lot of data cannot be found, so the database is checked. Another situation is that the Redis host hangs and Redis completely crashes.

At a certain moment, the cache fails centrally, or the cache system fails, and all concurrent traffic will reach the database directly. The number of calls to the data storage layer will increase dramatically, and it won’t take long for the database to be overwhelmed by the heavy traffic.

solution

Option 1: Set the expiration time randomly

Add a random value to the original failure time, such as 1-5 minutes randomly. This avoids cache avalanches caused by using the same expiration time.

Option 2: Cache warm-up

Cache preheating is to add data to the cache in advance. When the data changes, the latest data is updated to the cache.

Option 3: Redis cluster

In order to prevent cache avalanche caused by Redis downtime, you can build a Redis cluster to improve the disaster tolerance of Redis.