What should you pay attention to when using redis?

The main issues to pay attention to when using redis are as follows:

redis and database double-write consistency issues (recommended learning: Redis video Tutorial)

Analysis: Consistency issues are common distributed problems and can be further divided into final consistency and strong consistency. If the database and cache are double-written, there will inevitably be inconsistencies. To answer this question, first understand a premise. That is, if there are strong consistency requirements for the data, it cannot be cached. Everything we do can only guarantee eventual consistency. In addition, fundamentally speaking, the solution we have made can only reduce the probability of inconsistency, but cannot completely avoid it. Therefore, data with strong consistency requirements cannot be cached. ----------

Analysis: Consistency problem is a common distributed problem, which can be further divided into final consistency and strong consistency. If the database and cache are double-written, there will inevitably be inconsistencies. To answer this question, first understand a premise. That is, if there are strong consistency requirements for the data, it cannot be cached. Everything we do can only guarantee eventual consistency. In addition, fundamentally speaking, the solution we have made can only reduce the probability of inconsistency, but cannot completely avoid it. Therefore, data with strong consistency requirements cannot be cached.

First of all, adopt the correct update strategy, update the database first, and then delete the cache. Secondly, because there may be a problem of failure to delete the cache, a compensation measure can be provided, such as using a message queue.

How to deal with cache penetration and cache avalanche problems

Analysis: To be honest, these two problems are very difficult for small and medium-sized traditional software companies to encounter. this problem. If there are large concurrent projects, the traffic will be around millions. These two issues must be considered deeply.

Answer: As shown below

Cache penetration, that is, the hacker deliberately requests data that does not exist in the cache, causing all requests to be sent to the database on, causing the database connection to be abnormal.

Solution:

(1) Use mutex lock. When the cache fails, first obtain the lock, and then request the database . If the lock is not obtained, then sleep for a period of time and try again

(2) Use an asynchronous update strategy, and return directly regardless of whether the key has a value. A cache expiration time is maintained in the value value. If the cache expires, a thread will be started asynchronously to read the database and update the cache. Cache preheating (loading the cache before starting the project) operation is required.

(3) Provide an interception mechanism that can quickly determine whether the request is valid. For example, use Bloom filters to internally maintain a series of legal and valid keys. Quickly determine whether the Key carried in the request is legal and valid. If it is illegal, return directly.

Cache avalanche, that is, the cache fails in a large area at the same time. At this time, another wave of requests comes, and as a result, the requests are all sent to the database, resulting in an abnormal database connection.

Solution:

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

(2) Use a mutex lock, but the throughput of this solution drops significantly.

(3) Double buffering. We have two caches, cache A and cache B. The expiration time of cache A is 20 minutes, and there is no expiration time for cache B. Do the cache warm-up operation yourself. Then break down the following points

I Read the database from cache A, and return directly if there is any

II A has no data, read data directly from B, return directly, and asynchronously Start an update thread.

III The update thread updates cache A and cache B at the same time.

How to solve the problem of concurrent competition for keys in redis

Analysis: This problem is roughly that there are multiple subsystems setting a key at the same time. What should we pay attention to at this time? Have you ever thought about it? It needs to be explained that the blogger searched Baidu in advance and found that the answer basically recommended using the redis transaction mechanism. The blogger does not recommend using the redis transaction mechanism. Because our production environment is basically a redis cluster environment, data sharding operations are performed. When you have multiple key operations involved in a transaction, these multiple keys are not necessarily stored on the same redis-server. Therefore, the transaction mechanism of redis is very useless.

Answer: As shown below

(1) If you operate this key, the order is not required

In this case, prepare a distributed lock and everyone will grab the lock , just do the set operation after grabbing the lock, which is relatively simple.

(2) If you operate this key, the required sequence

Assume there is 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 valueB. key1 is set to valueC.

It is expected that the value of key1 will change in the order of valueA–>valueB–>valueC. At this time, we need to save a timestamp when writing data to the database. Assume that the timestamp is as follows

系统A key 1 {valueA  3:00}
系统B key 1 {valueB  3:05}
系统C key 1 {valueC  3:10}

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

For more Redis-related technical articles, please visit the Introduction Tutorial on Using Redis Database column to learn!

The above is the detailed content of What should you pay attention to when using redis?. For more information, please follow other related articles on the PHP Chinese website!