What are redis avalanche, penetration and breakdown?

Redis How to learn ？ What is an avalanche 、 Penetration and breakdown ？Redis What happens after the crash ？ How should the system deal with this situation ？ How to handle master-slave replication , What's wrong with sentinel mode ？？？...

Is it a little dizzy ？ Don't worry. , Let's take a look at the core concepts ！

 

Psychological analysis of interviewers

In fact, when it comes to caching, you have to ask , Because of cache avalanches and penetrations , The two biggest problems in caching , Or it doesn't show up , When it does, it's fatal , So the interviewer will ask you .

Analysis of interview questions

Cache avalanche

For the system A, Assume peak hours per second per day 5000 A request , Originally, the cache can hold every second in peak period 4000 A request , But the cache machine went down unexpectedly . The cache is down , here 1 second 5000 Requests all drop to database , Database can't bear it , It will call the police , And then I hung up . here , If there is no special solution to deal with this problem ,DBA Very anxious , Restart the database , But the database was immediately killed by new traffic .

This is the cache avalanche .

redis-caching-avalanche

Around the 3 Years ago , A well-known Internet company in China , There was a cache crash , Cause avalanches , Background system crash , The accident lasted from the afternoon to the early morning 3~4 spot , The company lost tens of millions .

The solution of the avalanche is as follows ：

• In advance ：redis High availability , Master-slave + sentry ,redis cluster, Avoid total collapse .

• In the matter ： Local ehcache cache + hystrix Current limiting & Downgrade , avoid MySQL Killed .

• After the event ：redis Persistence , Once the restart , Automatically load data from disk , Quick recovery of cached data .

redis-caching-avalanche-solution

User sends a request , System A Upon receipt of the request , Check the local area first ehcache cache , If you don't find it, check it again redis. If ehcache and redis None , Check the database again , Results in database , write in ehcache and redis in .

Current limiting components , Can set requests per second , How many can pass through the components , Remaining failed requests , What do I do ？ Take the demotion ！ You can return some default values , Or friendship tips , Or a blank value .

benefits ：

• Database will never die , The current limiting component ensures how many requests can pass each second .

• As long as the database doesn't die , That is to say , For users ,2/5 All requests of can be processed .

• As long as there is 2/5 Can be processed , That means your system is not dead , For users , Maybe it's just that you can't swipe the page after clicking several times , But a few more times , You can brush it out once .

Cache penetration

For the system A, Suppose one second 5000 A request , It turns out that 4000 Requests are malicious attacks by hackers .

From the hacker 4000 An attack , Not found in cache , Every time you go to the database , I can't find out .

Take a chestnut . database id It's from 1 At the beginning , As a result, the request from the hacker id All negative numbers . In this case , Not in cache , Request every time “ View cache in nothing ”, Direct query database . The cache penetration in this malicious attack scenario will directly kill the database .

redis-caching-penetration

 

The solution is simple , Every time the system A As long as it's not found in the database , Just write a null value to the cache , such as  set -999 UNKNOWN. Then set an expiration time , In this case , Same next time key When I came to visit , Before cache expires , You can get data directly from the cache .

 

Cache breakdown

Cache breakdown , That is to say, some key Very hot , Very frequent visits , Centralized high concurrent access , When this key At the moment of failure , A large number of requests break down the cache , Direct request database , It's like making a hole in a barrier .

The solutions in different scenarios can be as follows ：

• If the cached data is basically not updated , You can try to set the hotspot data to never expire .

• If the cached data is not updated frequently , And the whole process of cache refresh takes less time , Based on redis、zookeeper Distributed mutex of distributed middleware , Or local mutexes to ensure that only a small number of requests can request the database and rebuild the cache , Other threads can access the new cache after the lock is released .

• If the cached data update frequently or the cache refresh process takes a long time , The timing thread can be used to actively rebuild the cache before the cache expires or delay the cache expiration time , To ensure that all requests can access to the corresponding cache .