Shulou(Shulou.com)06/02 Report--

This article mainly introduces "analyzing Redis cache avalanche, breakdown, penetration". In daily operation, I believe many people have doubts in analyzing Redis cache avalanche, breakdown, and penetration problems. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the questions of "analyzing Redis cache avalanche, breakdown, penetration". Next, please follow the editor to study!

The interview begins.

Young man, I see your resume says Redis, so let's get to the point and get to the point with some common big questions, Redis avalanche?

Hello, handsome and charming interviewer, as far as I know, at present, the e-commerce home page and hot data will be cached. Generally, the cache is refreshed by fixed-time tasks, or updated after it can not be found. There is a problem with scheduled task refreshing.

To take a simple example: if the Key expiration time of all the home pages is 12 hours, and it is refreshed at 12:00, I have a large influx of flash sale activity users at zero. Suppose there were 6000 requests per second at that time, the cache could have held up to 5000 requests per second, but the cache would have invalidated all Key at that time. At this time, all the 6000 requests in 1 second fall into the database, and the database must not be able to bear it. It will report to the police, and the real situation may be hung up without even responding to the DBA. At this time, if there is no special solution to deal with this failure, DBA is in a hurry to restart the database, but the database is immediately killed by new traffic. This is what I understand as a cache avalanche.

I deliberately looked at the project I have done and feel that no matter how big the QPS is, it is not allowed to hit DB directly, but without slow SQL plus sub-database, the large score table may be OK, but there is still a big gap between using Redis and using it.

Large areas of failure at the same time, Redis is the same as none at that moment, then this number of requests directly to the database is almost catastrophic. Think about it. If you hit and hang a library of user services, then almost all the interfaces of other libraries that rely on it will report an error. If you do not do a circuit breaker and other strategies are basically instantly linked to the rhythm, how do you restart the user will hang you up, when you can restart? Users have long gone to bed and lost confidence in your products, what junk products.

The interviewer touched his hair, well, it was not bad, so what about this situation? How do you deal with it?

It is easy to deal with cache avalanche. When storing data in Redis in batches, just add a random value to the expiration time of each Key, so as to ensure that the data will not fail in a large area at the same time. I believe that Redis can withstand this traffic.

SetRedis (Key,value,time + Math.random () * 10000)

If the Redis is deployed in a cluster, distributing the hot spot data evenly in different Redis libraries can also avoid all failures. However, when I operate a cluster in a production environment, a single service is a corresponding single Redis shard to facilitate data management, but it also has the disadvantage that it may fail. Random expiration time is a good strategy.

Or set the hotspot data to never expire, and update the cache as long as there is an update operation (for example, if the operation and maintenance update the home page, then you can brush the cache and do not set the expiration time). This operation can also be used for the data of the home page of e-commerce. Insurance.

Do you know anything about cache penetration and breakdown? can you tell me the difference between them and avalanches?

Well, yes, let me talk about cache traversal first. Cache traversal refers to data that is not available in the cache and database, and users keep making requests, and the id of our database is increased since 1, such as data with an id value of-1 or id for data that does not exist. At this time, the user is likely to be an attacker, and the attack will lead to excessive pressure on the database and seriously destroy the database.

A smaller stand-alone system can basically be killed with postman, such as the Aliyun service I bought myself.

Like this, if you do not check the parameters, the database id is greater than 0. I have been using parameters less than 0 to request you. Every time I can bypass Redis and directly hit the database, the database can not be found, every time it is like this, and the high point is easy to collapse.

As for cache breakdown, this is a bit like cache avalanche, but it is a little different. Cache avalanche is due to a large area of cache invalidation, which avalanche DB. The difference is that cache breakdown refers to a Key very hot spot, constantly carrying large concurrency, large concurrency focus on accessing this point. When this Key fails, persistent large concurrency will break through the cache and directly request the database. It's like cutting a hole in an intact bucket.

The interviewer showed gratified eyes, so how do they solve the problem respectively?

Cache traversal I will add verification in the interface layer, such as user authentication verification, parameter verification, illegal parameters directly code Return, such as: id for basic verification, id

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.