Let us together into a giant — the cache of the high-frequency interview questions through the breakdown and caching, caching, avalanche | Redis combat (11)

This is the 25th day of my participation in the More text Challenge. For more details, see more text Challenge

Related articles

Redis combat summary: Redis combat

First, Redis cache penetration

1. Concept:

The user needs to query a data, but redis does not have it (for example, in mysql, id=-1), directly request mysql, when many users request at the same time, there is no hit! So all requests to the persistence layer database, so this will put the persistence layer database to bring very big pressure. Generally such cases are not normal users, basically are malicious users!

2. Solutions

① Bloom filter:

Bloom filter is a data structure that stores all possible query parameters in the form of hash, verifies them at the control layer first, and displaces them if they do not meet the requirements, thus avoiding the query pressure on the underlying storage system.

Because of space reasons, I will not expand here, and a separate article will be published to explain bloom filter in detail!

(2) Cache empty objects:

When the data is not found in the storage layer, even if it is null, we will store it and set an expiration time in Redis. After accessing the data, it will be accessed from Redis, protecting the database in the persistence layer!

③ Existing problems:

1) If nulls can be cached, this means that the cache needs more space to store more keys, because there may be many nulls in the cache;

2) Even if the expiration time is set for the null value, the data in the cache layer and the storage layer will be inconsistent for a period of time, which will have an impact on the business that needs to maintain consistency.

Note: Cache penetration is not available in Either Redis or MySQL, and then requests to MySQL directly.

2. Redis cache breakdown

1. Concept:

This is when a very hot key is constantly carrying a lot of concurrency, and when the key fails, all of a sudden a lot of requests rush into the persistence layer database, like a hole in the wall somewhere!

2. Solution:

① Set the hotspot key to never expire:

From the cache level, the expiration time is not set, so there will be no problems after the hot key expires.

② Add mutex:

When querying the persistence layer database, only one thread can query the persistence layer data, other threads let it sleep for several hundred milliseconds, waiting for the first thread to query the data will write back to the Redis cache, the rest of the threads can query the Redis cache normally, there is no large number of requests to impact the persistence layer database!

3. Disadvantages:

In fact, it is not reasonable to set never expire!

3. Redis cache avalanche

1. Concept:

In a certain period of time, a large number of cached keys expire at the same time, and all requests rush to the persistence layer database, causing the persistence layer database to fail! Example: Double eleven zero point panic buying, this wave of goods are concentrated on the cache, set the expiration time for 1 hour, then at zero point, this batch of cache all invalid, and a large number of requests come, all rushed through the cache, rushed to the persistent layer database!

2. Solution:

①Redis high Availability:

Set up a Redis cluster. Since Redis may fail, I will add several more Redis, so that after one fails, others can continue to work. In fact, it is the set up cluster. (Live in different places!)

② Current limiting degradation:

The number of threads that can read from or write to the database cache is controlled by locking or queuing after cache invalidation. For example, only one thread is allowed to query the data and write to the cache for a key, while other threads wait.

③ Data preheating:

By data heating, I mean that before I deploy, I access all possible data in advance, so that some of the data that may be heavily accessed will be loaded into the cache. Manually trigger the loading of different cache keys before large concurrent access and set different expiration times to make the cache invalidation time as even as possible.

I see no ending, but I will search high and low

If you think I blogger writes good! Writing is not easy, please like, follow, comment to encourage the blogger ~hahah