Github Star: github.com/yehongzhi
preface
Redis as the most widely used cache, I believe we are familiar with. However, using cache is not so simple, there are also cache avalanche, cache breakdown, cache penetration problems, what is cache avalanche, cache breakdown, cache penetration, and how to solve these problems, next to learn.
Cache avalanche
What is cache avalanche?
When a large-scale cache failure occurs at a certain time, it will lead to a large number of requests directly hitting the database, resulting in a huge pressure on the database. In the case of high concurrency, the database may be down in an instant. At this time, if the operation and maintenance immediately restart the database, immediately there will be new traffic to the database. This is cache avalanche.
Analysis:
The key to causing cache avalanches is massive key failures at the same time. There are several possibilities. The first possibility is that Redis is down, and the second possibility is that the same expiration time is adopted. Now that we know why, what’s the solution?
Solution:
1. Add a random value to the original failure time, such as 1-5 minutes random. This avoids the cache avalanche caused by adopting the same expiration time.
If a cache avalanche does occur, is there a backstop?
2. Use the circuit breaker mechanism. When the traffic reaches a certain threshold, the system directly returns a message such as “system congestion” to prevent too many requests from hitting the database. At least some users can use it normally, and other users can get results after refreshing several times.
3. To improve the disaster recovery capability of the database, you can use the strategy of separate libraries, separate tables, and separate read and write.
4. In order to prevent the cache avalanche caused by Redis downtime, a Redis cluster can be built to improve the disaster recovery of Redis.
Cache breakdown
What is cache breakdown?
In fact, it is similar to the cache avalanche. The cache avalanche is a large-scale key failure, while the cache breakdown is a hot key that is accessed by a large number of concurrent requests. All of a sudden, the key fails, resulting in a large number of concurrent requests hitting the database, resulting in a sharp increase in database pressure. This phenomenon is called cache breakdown.
Analysis:
The key of a hot spot fails, causing a large number of concurrent calls to the database. Therefore, we need to solve the problem from two aspects: first, we can consider whether the hot key does not set expiration time; second, we can consider reducing the number of requests made on the database.
Solution:
1. As mentioned above, you can set keys that never expire for hot spots if the service allows.
2. Use mutex. If the cache is invalid, only get the lock can query the database, reduce the request to hit the database at the same time, prevent database killing. Of course, this will lead to poor system performance.
The cache to penetrate
What is cache penetration?
In most cases, we use Redis to query the corresponding value through Key. If the Key in the sent request does not exist in Redis, it will not be found in the cache. If it is not found in the cache, we will go to the database for query. If a large number of such requests hit the database as if they had “penetrated” the cache, this phenomenon is called cache penetration.
Analysis:
The key value cannot be found in Redis, which is fundamentally different from cache breakdown. The difference is that cache penetration is that the key passed in does not exist in Redis. If a hacker passes a large number of non-existent keys, then a large number of requests hit the database is a very fatal problem, so in daily development to do a good check of parameters, some illegal parameters, impossible to exist key directly return error prompt, to maintain this “distrust” mentality to the caller.
Solution:
1. Save invalid keys into Redis. If Redis does not find the data and the database does not find the data, we save the Key to Redis, set value=”null”, the next query through this Key does not need to query the database. There is definitely a problem with this approach. If the nonexistent Key is passed in randomly every time, there is no point in saving it in Redis.
2, use bloom filter. If a key does not exist, then it must not exist. If a key does exist, then it is likely to exist (there is a certain misjudgment rate). So we can add a layer of Bloom filter before the cache, in the query to the bloom filter to check whether the key exists, if not, directly return.
conclusion
These three problems in the use of Redis is certain to encounter, and is very fatal problems, so in daily development must pay attention to, every time the use of Redis, to maintain a rigorous attitude towards it. Another important thing to remember is to have a circuit breaker in place, at least to protect the database from being killed in the event of a cache avalanche, breakdown, or penetration.
So that’s all for this article, thank you for reading, I hope you can learn something after reading.
Please give me a thumbs-up if you think it is useful. Your thumbs-up is the biggest motivation for my creation
I’m a programmer who tries to be remembered. See you next time!!
Ability is limited, if there is any mistake or improper place, please criticize and correct, study together!