For students who have used Redis, have you heard of cache breakdown, cache penetration, or cache avalanche ? These are the most common problems of the cache system. But I believe that many students are vague about the concepts between these three. Today's article is to illustrate the differences between the three and how to solve these problems. I hope you can answer relevant questions accurately during the interview.
Cache penetration
The general cache system caches queries according to the key. If the corresponding value does not exist, it should go to the back-end system to find it (such as DB). If the value corresponding to the key does not exist, and the number of concurrent requests for the key is large, it will cause a lot of pressure on the back-end system.
In other words, high concurrent access to non-existent keys causes the database pressure to increase instantly, which is called [cache penetration].
Solution:
Cache the query result if it is empty. Set the cache time to a shorter time, or clear the cache after the data corresponding to the key is inserted.
Cache avalanche
When the cache server restarts or a large number of caches fail in a certain period of time, it will also put a lot of pressure on the back-end system (such as DB) when it fails.
Suddenly a large number of keys fail or redis restarts, and the problem of a surge in system pressure caused by a large number of database accesses is the cache avalanche.
solution:
- The expiration dates of the keys are scattered, and different keys have different expiration dates;
- Set up secondary cache;
- High-availability solutions, such as redis clusters, ensure that cache avalanches will not occur due to cache system crashes;
Cache breakdown
For some keys that have an expiration time set, if these keys may be accessed extremely concurrently at certain points in time, it is a very "hot" data. At this time, there is a problem that needs to be considered: the problem of cache "breakdown". The difference between this and cache avalanche is that the cache is for a certain key, and the former has many keys.
When the cache expires at a certain point in time, there are a large number of concurrent requests for this Key at this point in time. When these requests find that the cache expires, data will generally be loaded from the backend DB and reset to the cache. At this time, a large concurrent request It may overwhelm the back-end DB instantly.
solution:
- Use distributed locks to control access threads. For example, use redis' setnx mutex lock to make a judgment first, so that other threads are in a waiting state to ensure that there will be no large concurrent operations to operate the
database.
if(redis.sexnx()==1){ //先查询缓存 //查询数据库 //加入缓存 }
Cache double write consistency
This problem is a common problem in business development, that is, how to ensure data consistency when writing redis and database? If you still don’t know under what circumstances the double-write consistency problem will occur, then let me give you a few examples. Are you familiar with it? Do you usually use redis like this?
Update the database first and then update the cache (not recommended);
Operation steps (thread A and thread B both update the same data):
- Thread A updated the database
- Thread B updated the database
- Thread B updated the cache
- Thread A updated the cache
Obviously, the problem with this kind of operation is: dirty reads, waste of performance
Update the database before deleting the cache
Steps:
- Request A to perform a write operation and delete the cache. At this time, A's write operation has not been completed
- Request B to query and find that the cache does not exist
- Request B to query the database to get the old value
- Request B to write the old value to the cache
- Request A to write the new value to the database
In this scheme, you can see that in step 4, the old value will be written into the cache last, which will eventually cause dirty reads;
Delete the cache and then update the database
Steps:
- User A failed to delete the cache
- User A successfully updated the data
or:
- User A deleted the cache;
- User B reads the cache, and the cache does not exist;
- User B gets old data from the database;
- User B updated the cache;
- User A updated the data;
According to the above steps, this solution will also have a dirty read problem, resulting in inconsistent data double writing and causing business system exceptions.
Here are several solutions:
- Solution 1: Set the effective time of the cache (the simplest), and configure a reasonable expiration time in a scenario that accepts eventual consistency.
- Solution 2: Use message queues, such as rocketMq and other message queues to ensure the consistency of the data operation sequence and ensure that the data in the cache system is normal.
This is the difference between cache breakdown, cache avalanche, and cache breakdown that the Redis cache system often asks. Although these concepts sound very similar, there are still some subtle differences in the definition. Also it introduced in business systems using common data, two write cache coherency problem scenarios and recommended solutions, hoping to help you.
Recommended reading:
Redis advanced knowledge points you have to know-master-slave replication principle
Redis sentinel mechanism-knowledge points you have to know
Redis cluster-official recommended solution RedisCluster