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

Today, what the editor shares with you is what you should pay attention to when using redis. I believe many people don't know much about it. In order to make you know more about the use of redis, I summarized the following for you. Without saying much, let's go on.

Double write consistency between redis and Database

Analysis: consistency problem is a common distributed problem, which can be subdivided into final consistency and strong consistency. Database and cache double write, there are bound to be inconsistencies. To answer this question, first understand a premise. That is, if there are strong consistency requirements for data, you can't slow down the storage. What we do can only ensure the ultimate consistency. In addition, fundamentally speaking, the plan we have made can only be said to reduce the probability of inconsistency and cannot be completely avoided. Therefore, data with strong consistency requirements cannot be slowed down. -

Analysis: consistency problem is a common distributed problem, which can be subdivided into final consistency and strong consistency. Database and cache double write, there are bound to be inconsistencies. To answer this question, first understand a premise. That is, if there are strong consistency requirements for data, you can't slow down the storage. What we do can only ensure the ultimate consistency. In addition, fundamentally speaking, the plan we have made can only be said to reduce the probability of inconsistency and cannot be completely avoided. Therefore, data with strong consistency requirements cannot be slowed down.

First of all, adopt the correct update strategy, update the database first, and then delete the cache. Second, because there may be a failure to delete the cache, you can provide a compensatory measure, such as using message queuing.

How to deal with cache penetration and cache avalanche

Analysis: these two problems, to tell you the truth, the general small and medium-sized traditional software enterprises, it is difficult to encounter this problem. If there are large concurrent projects, the traffic is about millions. These two issues must be considered deeply.

Answer: as follows

Cache traversal, that is, hackers deliberately request data that does not exist in the cache, resulting in all requests to the database, resulting in abnormal database connection.

Solution:

(1) using mutexes, when the cache expires, first get the lock, get the lock, and then request the database. If you don't get the lock, go dormant for a while and try again.

(2) the asynchronous update strategy is adopted, which is returned directly regardless of whether the key gets a value or not. A cache expiration time is maintained in the value value. If the cache expires, a thread is asynchronously set up to read the database and update the cache. Need to do cache warm-up (load the cache before the project starts).

(3) provide an interception mechanism that can quickly judge whether the request is valid, for example, using Bloom filter to maintain a series of legal and valid key internally. Quickly determine whether the Key carried by the request is legal or valid. If it is illegal, return directly.

Cache avalanche, that is, a large area of cache failure at the same time, when there is another wave of requests, resulting in requests to the database, resulting in abnormal database connection.

Solution:

(1) add a random value to the cache expiration time to avoid collective failure.

(2) mutexes are used, but the throughput of the scheme is significantly reduced.

(3) double cache. We have two caches, cache An and cache B. The expiration time of cache An is 20 minutes, and cache B has no expiration time. Do your own cache warm-up operation. Then subdivide the following dots

I read the database from cache A, and return it directly.

II A has no data, reads the data directly from B, returns directly, and starts an update thread asynchronously.

The III update thread updates both cache An and cache B.

How to solve the problem of concurrent competitive key in redis

Analysis: the problem is roughly that multiple subsystems go to set a key at the same time. What should we pay attention to at this time? Have you thought about it. Need to explain, the blogger ahead of Baidu, found that the answer is basically recommended to use the redis transaction mechanism. Bloggers do not recommend using redis's transaction mechanism. Because our production environment is basically a redis cluster environment, we have done data slicing operation. When you have multiple key operations involved in a transaction, the multiple key may not be stored on the same redis-server. Therefore, the transaction mechanism of redis is very chicken.

Answer: as follows

(1) if the key operation is performed, no order is required.

In this case, prepare a distributed lock, everyone to grab the lock, grab the lock to do set operation, it is relatively simple.

(2) if the key operation is required, order is required.

Suppose you have a key1, system A needs to set key1 to valueA, system B needs to set key1 to valueB, and system C needs to set key1 to valueC.

The value of key1 is expected to change in the order of valueA- > valueB- > valueC. In this case, we need to save a timestamp when the data is written to the database. Suppose the timestamp is as follows

System A key 1 {valueA 3:00} system B key 1 {valueB 3:05} system C key 1 {valueC 3:10}

So, suppose system B grabs the lock first and sets key1 to {valueB 3:05}. Then system A grabs the lock and finds that the timestamp of its valueA is earlier than the timestamp in the cache, so it does not do the set operation. and so on.

These are the details of what you should pay attention to when using redis, and do you have anything to gain after reading it? If you want to know more about it, you are welcome to follow the industry information!

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.