preface
Original public account: Bigsai
Cache penetrations, cache avalanches, and cache penetrations are frequently used in interviews.
Redis cache penetration
understand
- Focusing on
through
That is, access via Redis directly through mysql, which is usually a nonexistent onekey
, is queried in the databasenull
. Each request falls into the database and is highly concurrent. The database will fail.
The solution
- Null can be set to the cache object for this key.
- Of course, it can also be based on the obvious error key at the logical level
validation
. - At the same time, you can also analyze the user’s behavior, whether it is a deliberate request or crawler or attacker. Restrict user access.
- Other things, such as using a Bloom filter (very large HashMap) first filter.
Redis cache avalanche
understand
- An avalanche is a
Things came pouring in
It’s like an avalanche. In this case, the Redis cache collectiveMass failure
In the case of high concurrency, the key suddenly accesses mysql on a large scale, causing the database to crash. Imagine a countryAging of population
. After that day, people are concentrated in their 70s and 80s, so no one works. The national workforce is a source of stress.
The solution
- The usual solution is to add one after the expiration time of the key
The random number
, and let the key fail uniformly. - Consider using queues or locks to keep the program within pressure, although this approach may affect the amount of concurrency.
- Hotspot data can be considered not invalid
Redis cache breakdown
understand
Cache penetration is when a key is very hot and is constantly carrying a large number of concurrent accesses to this point. When the key is in the moment of failure, the continuous large number of concurrent accesses to the cache and directly requests the database, as if brute force penetration is the same.
- Penetrations are different from penetrations. Penetrations mean ideas
bypass
Redis went and caused the database to crash. And the breakdown you can interpret asPositive just
A breakdown, usually a large number of concurrent reads and writes to a key. This key makes a lot of requests to the database during cache invalidation, putting too much pressure on the database and causing the database to crash. itSuch as
In the seckill scenario, 10,000 RMB MAC and 100 RMB MAC, the 100 RMB order will definitely be rushed to the top, and the request will be repeated (of course, the specific seckill has its own processing method here is just an example). So a cache breakdown is a database crash caused by a large number of requests for a common key.
The solution
- Mutex can be used to prevent a large number of requests from falling into DB at the same time.
- Bloom filter to determine whether a container is in a collection
- You can set the cache to never expire (for some cases)
- Do a good job of circuit breaker, downgrade, prevent system collapse.
Original public account: Bigsai
Welcome to dig friends to follow, like support!