In our last post, we talked about Redis’ master-slave replication, persistence, and sentry mechanics, and I believe you got a lot out of them. They are essential for getting into a big factory. This time, we’ll talk more about avalanche, penetration, and penetration.
\
\
As qualified moving brick personnel, we know that the general will be the hot data, especially like some treasure some east what what the home page data, will be cached in advance down, so that the user opens the home page loading speed will be much faster, experience will be better, but also for the system storage layer MySQL is safe. Then use the scheduled task to refresh the data regularly.
Only when the cache system fails to obtain data, will it degrade directly to MySQL to request data.
For example, the recommended data on the home page of a product I have done before is designed in this way. The data is cached in Redis in advance and timed, so that the opening speed of the home page will be fast.
These are ideal situations, but the reality is always so thin that it catches you off guard.
\
An avalanche
\
Take a scenario like this: Suddenly when the cache server restart, or the failure of a large number of cached data Key time is concentrated in a certain time point, and this time, such as the company is doing at this time a seconds kill activity, caching system originally designed to withstand 10 w QPS, at this time due to buffer layer failure, can only request directly to MySQL, you think about it, If 10W+ QPS goes directly to the MySQL layer, MySQL will fail.
They are known in the industry as avalanches, and no snowflake is innocent in an avalanche.
So what to do? There are several solutions:
Solution 1: Use the Redis cluster high availability solution we talked about in the last post, namely sentinel deployment solution. If one machine is down, another machine can come up at any time.
Solution 2: Set different expiration time for different keys to ensure that the data will not become invalid at a certain point in time.
Solution 3: Set the cache to never expire.
Solution 4: Use mutex, but the implementation is more complicated, when the cache invalidates, by locking or queue to control the number of requests, the single can use synchronized or lock. Distributed environments can use the setnx command;
Solution 5: Use Netflix Hystrix Circuit breakers, a tool in the microservices architecture that provides isolation, circuit breakers, and degradation mechanisms for high availability of microservices, a powerful tool to prevent an avalanche of services.
\
The breakdown
\
Breakdown you can get some flavor out of that word.
What is breakdown? You can imagine if you take a pen and stab a piece of paper, he will Pierce a hole in the paper.
Similarly, Redis breakdown means that a large number of requests in a set keep requesting a certain point. When this Key fails at the moment, a large number of requests will directly penetrate the cache layer and direct to MySQL. MySQL will not be able to handle such a large request.
That’s not what you want, is it? Ha ha ha…
So what’s the solution?
Quite simply, you can go straight to Avalanche solutions three and four, which is to set the Key to never expire and add the mutex. \
\
through
\
Penetrations and penetrations seem to be the same, but there is a difference, in the literal sense, penetrations are noticeably softer, but still too violent, hahaha…
As we know, Redis is a key-value system, so we find the corresponding Value according to the Key. If we cannot find the corresponding Value, we will directly query from the MySQL layer. If a large number of requests come, the database will be under too much pressure, which will overwhelm the database.
It looks like it’s the same as penetrating… But you are fine.
So what’s the solution?
Plan one: Just don’t let that happen. The general veteran tile workers will be the user request data to do parameter check, because we believe that the user is unreliable, but the fear of the novice forget the parameter check, this is finished, so, must remember the parameter check, useless parameters must be timely empty or null, develop a good habit.
Solution two: Use the famous Bloom filter. Why say it is famous, I here sell a secret, you will know later, hahaha…
I will post an article about the Bloom filter in detail and its application scenarios. If you want to see it, please keep an eye on me.
\
conclusion
\
This is the famous avalanche, breakdown and penetration in Redis. If you want to move bricks in a large factory, you will be asked to use it or enter the door.
Although these problems may seem simple, in a production environment with dozens or hundreds of machines, if this happens, it is a project accident, and the impact on the company can be fatal, so it must be skillfully mastered.
OK, this article is really the essence, is also one of the necessary bricks to enter the big factory, at the end, I can not bear to send out, ha ha ha…
However za is slag and mature uncle, of course is to let everyone white prostitute of!
If you think uncle write good, ask attention, ask for like, ask to share, after all uncle boil liver code word is also very hard, of course, if you are a girl, also welcome direct small window to find me oh!
I am Shi Yuan jun, a wandering uncle in the Internet river’s lake.
See you next time!