The cache to penetrate
A lot of access to nonexistent keys, so you have to access the database every time.
Solutions:
- Cache non-existent data in Redis, set key and value to null(whether data is not null or system bug), and set a short expiration period to avoid affecting normal users.
- Mask the IP address
- Verify the parameters and intercept invalid parameters
- The Bloom filter hashes all possible data into a bitmap(bitmap) large enough to intercept data that must not exist, thus avoiding query pressure on the underlying storage system.
An avalanche
When the cache fails, a large number of requests fall on the database, causing the database macro machine
Solution:
- Set the key expiration time randomly to prevent a large number of keys from failing collectively.
- In cluster deployment, hotspot data can be evenly distributed in different Redis libraries to avoid all key failures
- No expiration time is set
- Run timed tasks to flush new caches before they expire
\
Cache breakdown
A hot key is constantly carrying high concurrency. When the hot key fails, the continuous high concurrency will break the cache and directly access the database, causing the database to break down.
Solution:
- Set hotspot data to “never expire”
- Plus the mutex, the above phenomenon is the multiple threads to query the database of the data at the same time, so we can request on the first query data using a mutex locking it other threads can’t get this far the lock is wait, order of merit a thread query to the data, and then put the data in redis cached. The next thread comes in and finds that there is already a cache, so it goes directly to the cache
thinking
Be proactive: Build redis, MySQL, etc into highly available clusters to prevent single points. Better late than never: limit the flow in the service + downgrade, prevent MySQL from being crashed. Regroup: Redis persistent RDB+AOF, downtime and restart, automatically load data from disk, fast recovery of cached data.