Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to understand cache penetration, cache avalanche, cache breakdown and cache consistency in Redis". In daily operations, it is believed that many people have doubts about how to understand cache penetration, cache avalanche, cache breakdown and cache consistency in Redis. The editor consulted all kinds of materials and sorted out simple and useful methods of operation. I hope it will be helpful for you to answer the doubts about cache penetration, cache avalanche, cache breakdown and cache consistency in Redis! Next, please follow the editor to study!

Cache avalanche

If the cache fails in a large area at the same time, the subsequent requests will fall on the database, causing the database to crash because it cannot withstand a large number of requests in a short period of time.

For example, in the home page of e-commerce, the key failure time of all the home page is 12 hours, and it is refreshed at 12:00 at noon. If there is an influx of flash sale activity users at zero, but the cache is invalid at that time, all requests will fall into the database, and the database can not bear it, so it will directly be gg, or redis downtime, and it will also let a large number of requests fall into mysql, resulting in hanging up. [related recommendation: Redis video tutorial]

Solution

So in this case, we should add a random value to the failure time of each key to avoid a large number of key failures at the same time. In the case of redis cluster deployment, hot spot data can be distributed to different libraries.

Beforehand: try to ensure the high availability of the redis cluster, make up for the machine downtime as soon as possible, and choose the appropriate memory elimination strategy.

In the event: local ehcache cache + hystrix current limit plus downgrade to avoid mysql collapse

Afterwards: the data saved by the redis persistence mechanism is restored to cache as soon as possible.

Cache penetration

A large number of requested key does not exist in the cache, for example, a hacker makes a large number of requests from a key that does not exist in the cache, resulting in a large number of requests falling into the database.

Solution.

First of all, we should do basic input parameter verification, directly intercept illegal parameters, such as querying database id not less than 0, checking mailbox format, and so on.

If neither the cache nor the database can find the data for a key, write the key to redis,value as null, and set the expiration time to prevent the next request from falling on the database.

Through the Bloom filter, the Bloom filter can easily determine whether a given data exists in a large amount of data. You can store the values of all possible requests in the Bloom filter, and when the request comes, you can first determine whether the request sent by the user exists in the Bloom filter, and intercept directly if it does not exist.

Cache breakdown

Cache breakdown refers to a very hot Key that accesses this point while constantly carrying large concurrency and large concurrency. When the key fails, persistent large concurrency breaks through the cache and requests directly to the database.

Cache consistency

If strong consistency is required, caching cannot be used because strong consistency cannot be guaranteed, only final consistency can be guaranteed.

Delete the cache before updating the database

If the database update fails, then the database is still the old data, redis is empty, the data will not be inconsistent, read empty will go to the database to query, and then update to the cache.

Join the queue for serialization

Delete the cache first, and then update the database. Problems also occur in high concurrency scenarios. For example, when the cache is deleted and the database is not updated, another thread comes in and finds that redis is empty, reads the database, and then updates it to redis. At this time, the thread that deletes the cache and then updates the database will cause inconsistency between the database and redis data. At this time, you can put the operation of updating the data into the queue. Serialization does not occur, but it is generally not recommended because it reduces efficiency.

At this point, the study on "how to understand cache penetration, cache avalanche, cache breakdown and cache consistency in Redis" is over. I hope I can 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.