“This is the third day of my participation in the First Challenge 2022. For details: First Challenge 2022”

The cache to penetrate

Problem description

The data corresponding to the key does not exist in the data source, and every time a request for the key is not retrieved from the cache, the request will overwhelm the data source, which may overwhelm the data source. For example, using a non-existent user ID to obtain user information, neither cache nor database, if hackers use this vulnerability to attack may overwhelm the database.

Note: there is no data in the database or redis cache that the user wants to request

Illustration:

The characteristics of

1. Application server pressure increases

2. Redis hit ratio decreases

3, have been querying the database, but always can not be queried

The solution

A certain data does not exist in the cache and cannot be queried, because the cache is passive when the hit, and for fault tolerance consideration, if the data cannot be found from the storage layer will not be written into the cache, which will result in the non-existence of the data every request to the storage layer to query, lost the significance of the cache.

Solution:

(1) ** Null cache: ** If a query returns null data (whether or not the data does not exist), we still cache the null result, and set the expiration time of the null result to be very short, no more than five minutes

(2) Set the accessible list (whitelist) :

Use the Bitmaps type to define a list of accessible ids. The list id is used as the offset of the Bitmaps. Each access is compared to the ID in the Bitmap.

(3) Bloom Filter: Bloom Filter was proposed by Bloom in 1970. It’s actually a long binary vector (bitmap) and a series of random mapping functions (hash functions).

Bloom filters can be used to retrieve whether an element is in a collection. Its advantage is that its space efficiency and query time are far more than the general algorithm, but its disadvantage is that it has certain false recognition rate and deletion difficulty.

Hash all possible data into a bitmap large enough that a non-existent data will be intercepted by the bitmaps, thus avoiding query stress on the underlying storage system.

(4) real-time monitoring by ** : ** When it is found that the hit rate of Redis begins to decrease rapidly, it is necessary to check the access objects and data, and cooperate with operation and maintenance personnel to set blacklist to restrict services

Cache breakdown

Problem description

The data corresponding to key exists, but expires in Redis. At this time, if a large number of concurrent requests come in and find that the cache has expired, they will generally load data from the back-end DB and set it back to the cache. At this time, a large number of concurrent requests may overwhelm the back-end DB instantly.

Note: there is data in the database, but there is no data in the cache

Illustration:

The characteristics of

1. Database access pressure increases instantly

2. There are no large number of expired keys in Redis

3. Redis runs normally

4. Users access a key that has expired in large numbers

The solution

A key may be accessed at very high concurrency at certain points in time and is a very “hot” type of data. At this point, there is a problem to consider: cache breakdown.

Solve a problem:

** (1) Pre-set hot data: ** Before the peak access of Redis, some hot data is stored in Redis in advance to increase the duration of these hot data keys

** (2) Real-time adjustment: ** On-site monitoring of popular data, real-time adjustment of key expiration duration

(3) Use lock:

  • When the cache fails, it does not load db immediately.

  • Set a mutex key using some operation of the cache tool that returns a successful operation (such as Redis’s SETNX)

  • When the operation returns a success, load the DB, set the cache, and delete the mutex key.

  • If the operation fails, the current thread will sleep for a while and retry the whole GET cache.

  • Disadvantages: Every time you use it, you have to get the lock, which slows down efficiency

Cache avalanche

Problem description

The data corresponding to key exists, but expires in Redis. At this time, if a large number of concurrent requests come in and find that the cache has expired, they will generally load data from the back-end DB and set it back to the cache. At this time, a large number of concurrent requests may overwhelm the back-end DB instantly.

** Note: ** cache avalanche differs from cache breakdown in that it is for many key caches, while the former is for a single key

The characteristics of

1. The database pressure increases and the server crashes

2. Query the centralized expiration of a large number of keys in a very small period

The solution

The avalanche effect of cache failure on the underlying system is terrible!

(1) Build multi-level cache architecture:

Nginx cache + Redis cache + other caches (ehCache etc.)

(2) Use locks or queues:

Locks or queues are used to ensure that there will not be a large number of threads to read and write the database at one time, so as to avoid a large number of concurrent requests falling on the underlying storage system in the event of failure. Does not apply to high concurrency

(3) Set expiration mark update cache:

Log whether the cache data is expired (set the advance amount), which triggers notification to another thread in the background to update the cache of the actual key.

(4) Disperse the cache invalidation time:

For example, we can add a random value on the basis of the original expiration time, such as 1-5 minutes random, so that the repetition rate of expiration time of each cache will be reduced, and it is difficult to trigger the event of collective failure.