Cache avalanche

Imagine such a scenario, when the cache in our Redis server fails a lot in a certain period of time or the Redis server breaks down, the user’s request without the interception of the cache directly falls on the database server, causing the database server directly to break down. This is the cache avalanche we will introduce today.

There are several common solutions to cache avalanche:

  • The key expiration time is randomly set. Since cache avalanches are caused by a large number of key failures in a short period of time, we can randomly set the expiration time of keys to prevent this from happening.

  • If the Redis cluster deployment is used, the MySQL server may break down due to the failure of a Redis server.

  • Adopt service downgrading. A service downgrade is a sudden increase in server pressure and the selective shutdown of some functions. For example, taobao forbids cancellations of orders on Singles’ Day due to a large number of orders. Orders can only be cancelled the next day, which is a common service downgrade.

The cache to penetrate

The most common scenario for cache penetration is a hack attack. For example, when we visit a website with the URL XXXXX? Id =1, this is the normal page. However, some hackers frequently access the server by using some non-existent ids, and our Redis does not store these non-existent key values, so these requests will directly hit the database server and cause the server to break down, which is called cache penetration.

There are some common workarounds for cache penetration:

  • Verify the request parameters. In this case, we can directly intercept invalid id values, such as nonexistence if id is less than 0.

  • Write a null value to Redis when no data is found in the database. For example, if the request id is -1, the database can not get the data, you can directly write a null value into redis, and then you can use Redis to find the data in the future.

  • Mask the same IP address that frequently accesses nonexistent data.

  • Use a Bloom filter.

The following details the principle of bloom filter. Bloom filters take an array of bits, similar to the following, the initial state of the Bloom filter bit array is 0.


We also have hash functions that map a string to different bits, as shown below.


When a string is mapped to different bits using different hash functions, the zeros in those bits are changed to ones. When the same string is mapped to the corresponding bits using these hash functions, you can see if they are all ones.

Bloom filters are convenient but have some disadvantages.

The data that cannot be found cannot be guaranteed to exist, but the data that can be found cannot be guaranteed to exist. To put it simply, if a string has 0 bits mapped to it by multiple hash functions, it must not exist. However, some bits mapped to it may be set to 1 by other data, so it is likely to be judged to exist even if the data does not exist.

Another disadvantage is that it is difficult to support deleting an element, because deleting an element (setting a bit from 1 to 0) may set the same bit of other data to 0.

For a Bloom filter, the larger the storage space (the bit array), the lower the misjudgment rate, and the more data, the higher the misjudgment rate.

Cache breakdown

A cache breakdown is very similar to, but not quite the same as, a cache avalanche. A cache breakdown is when some hot data key suddenly expires, causing these requests to hit the database server and the server to crash again. In general, both cases are caused by database crashes due to expired keys.

The solutions to cache breakdown mainly include the following:

  • Hotspot data is set to never expire.

  • Use ZooKeeper or Redis to implement a mutex and wait for the first request to create a cache before allowing subsequent requests to continue.

This article is formatted using MDNICE