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

This article mainly introduces "how to understand the use and principle of Redis". In daily operation, I believe many people have doubts about how to understand the use and principle of Redis. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand the use and principle of Redis"! Next, please follow the editor to study!

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 the 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.

Technical summary:

In general, to avoid the above situation, let's analyze it from three time periods:

Beforehand: Redis highly available, master-slave + Sentinel, Redis cluster, avoid complete collapse.

In the event: local ehcache cache + Hystrix current limit + downgrade to avoid * * MySQL** being killed.

Afterwards: Redis persists RDB+AOF. Once restarted, it automatically loads data from disk and quickly recovers cached data.

I will talk about all the above points in the Redis section of the hanging series. This month, we should be able to finish Redis, current-limiting components, you can set requests per second, how many requests can pass through components, and what about the rest of the failed requests? Let's go! downgrade! You can return some default values, or friendly tips, or blank values.

Benefits:

The database will never die, and the current limiting component ensures that only how many requests can be passed per second. As long as the database is not dead, that is to say, for the user, the request of 3DB 5 can be processed. As long as there is a request for 3can5 that can be processed, it means that your system is not dead. For users, it may be that a few clicks can't bring up the page, but a few more times, you can brush it out once.

This is the most common in the current mainstream Internet companies. Are you curious about what happened to a star? you found that how you went to Weibo had a blank interface, but some people went directly in, and you also came out a few more times. Now you know, it's a downgrade, sacrificing the experience of some users for the security of the server, but it's okay?

At this point, the study on "how to understand the use and principle of Redis" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.