With the increase of system accesses and complexity, response performance has become a key concern. The use of caching has become a focus. Redis, as a leader in caching middleware, has become a must-ask item for interviews.
This article shares some of Redis’s common interview questions:
1.1 What is caching avalanche?
If our cache hangs, it means that all our requests go to the database.
We all know that Redis can’t cache all data (memory is expensive and limited), so Redis needs to set expiration time for data and adopt two strategies of lazy deletion + periodic deletion to delete expiration keys.
If the expiration time of the cache data setting is the same, and Redis just deletes all the data. This will cause these caches to fail at the same time and all requests to the database during this period of time.
This is the cache avalanche: Redis hangs up and all requests go to the database.
Cache avalanche, if it happens, is likely to crash our database, resulting in the paralysis of the entire service!
1.2 How to resolve cache avalanche?
Add a random value to the expiration time when caching, which greatly reduces the cache expiration at the same time.
For the case of “Redis hangs up and requests all go to the database”, we can have the following ideas:
Prior to the event: Implement high availability of Redis (master-slave architecture + Sentinel or Redis Cluster) and try to avoid Redis hanging.
Incident: In case Redis really hangs, we can set up ehcache + hystrix to avoid our database being destroyed (at least to ensure that our service works properly)
After the incident: redis persistence, automatically load data from disk after reboot, and quickly restore cached data.
2.1 What is Cache Penetration
Cache penetration refers to querying a data that must not exist. Because the cache is not hit, and for fault-tolerant consideration, if the data can not be found from the database, it will not be written to the cache, which will lead to the non-existent data every request to the database to query, losing the meaning of the cache.
This is cache penetration:
The requested data is missed in a large number of caches, causing the request to go to the database.
Cache penetration, if it happens, may also crash our database, resulting in paralysis of the entire service!
2.1 How to solve cache penetration?
There are also two solutions to cache penetration:
Since the parameters of the request are illegal (parameters that do not exist are requested every time), we can use Bloom Filter or compressed filter to intercept the request ahead of time, unlawful will not let the request to the database layer!
When we can’t find it from the database, we also set the empty object into the cache. Next time you request it, you can get it from the cache.
In this case, we usually set a short expiration time for empty objects.
Cache and database double-write consistency
3.1 For read operations, the process is as follows
If our data is in the cache, the cached data is fetched directly.
If we don’t have the data we want in the cache, we will first query the database and then write the data found in the database into the cache. Finally, the data is returned to the request.
3.2 What is the consistency between cache and database double-write?
If only queries are made, cached data and database data are not a problem. But what about when we want to update? Various situations are likely to result in inconsistencies between the database and the cached data.
This inconsistency refers to the inconsistency between database data and cached data.
In theory, as long as we set the key expiration time, we can ensure that the cache and database data are eventually consistent. Because as long as the cache data expires, it will be deleted. Later when reading, because there is no data in the cache, you can look up the data in the database, and then write the data found in the database into the cache.
In addition to setting expiration times, we need to do more to avoid inconsistencies between databases and caches.