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

This article mainly introduces the relevant knowledge of "what are the technical points of Redis". The editor shows you the operation process through actual cases, and the operation method is simple, fast and practical. I hope this article "what are the technical points of Redis" can help you solve the problem.

First, why use Redis

The author believes that the use of Redis in a project is mainly considered from two perspectives: performance and concurrency. Of course, Redis also has other functions such as distributed locks, but if it is only for distributed locks and other functions, there are other middleware (such as Zookpeer, etc.) that can be replaced, and it is not necessary to use Redis.

Therefore, this question is mainly answered from the perspective of performance and concurrency:

1. Performance

As shown in the following figure, we are particularly suitable for caching run results when we encounter SQL that takes a long time to execute and the results do not change frequently. In this way, the subsequent request is read in the cache so that the request can respond quickly.

Digression: I suddenly want to talk about this standard of rapid response-in fact, there is no fixed standard of response time depending on the effect of the interaction. However, someone once told me: "ideally, our page jump needs to be solved in an instant, and the operation on the page needs to be solved in an instant." in addition, time-consuming operations with more than one finger should be prompted and can be terminated or cancelled at any time, so as to give the user the best experience. "

So how much time is the moment, the moment, the flick of a finger?

According to the Maha Monk Law, there are one thought in an instant, twenty thoughts in a moment, twenty flicks in a finger, twenty fingers in advance, twenty in advance for a moment, and thirty moments in a day and a night.

So, after careful calculation, it is 0.36s in a moment, 0.018 seconds in a moment, and 7.2s in a finger.

2. Concurrency

As shown in the following figure, in the case of large concurrency, all requests directly access the database, and the database will have a connection exception. At this point, you need to use Redis to do a buffering operation so that the request accesses the Redis first instead of directly accessing the database.

What are the disadvantages of using Redis

You must understand this problem when you have been using Redis for so long. Basically, you will encounter some problems when using Redis. The common problems are mainly in four aspects:

1. Double write consistency between cache and database

2. Cache avalanche problem

3. Cache breakdown problem

4. Concurrency competition of cache

The author personally thinks that these four problems are more often encountered in the project, and the specific solutions will be given later.

Third, why single-threaded Redis is so fast

This question is actually an examination of the internal mechanism of Redis. In fact, according to the author's interview experience, many people do not know that Redis is a single-threaded work model. Therefore, this question should be reviewed. There are mainly the following three points:

1. Pure memory operation

2. Single-thread operation to avoid frequent context switching.

3. The non-blocking Istroke O multiplexing mechanism is adopted.

Now let's talk in detail about the Ishock O multiplexing mechanism, because this term is so popular that most people don't understand what it means. Let's take an example: Xiaoqu opened a delivery store in S City, which is responsible for the same city express service. Xiaoqu hired a group of couriers because of financial constraints, and then Xiaoqu found that there was not enough money to buy a car for express delivery.

Mode of operation 1:

Every time a customer sends a delivery, Xiaoqu lets a courier keep an eye on it, and then the courier drives to deliver the delivery. Slowly Xiaoqu found that there are many problems with this mode of operation. Dozens of couriers basically spend their time robbing cars, and most couriers are idle. Whoever grabs the car will be able to deliver the express delivery.

With the increase of express delivery, there are more and more couriers. Xiaoqu found that the express store is becoming more and more crowded, and there is no way to hire new couriers. The coordination between couriers takes a lot of time and spends most of their time robbing cars. Based on the above shortcomings, Xiaoqu learned from the bitter experience and put forward the following mode of operation ↓

Mode of operation 2:

Xiaoqu employs only one courier, and the courier sent by the customer is marked according to the place of delivery, and then placed in one place in turn. Finally, the courier went to pick up the delivery in turn, one at a time, drove the car to deliver the delivery, and came back to get the next delivery.

Comparing the above two modes of operation, do you obviously feel that the second mode of operation is more efficient and better? In the above analogy:

1. Each courier → each thread

2. Every courier →, every Socket (Icano stream)

3. Different states of → Socket at the delivery place of express delivery.

4. Customer request for express delivery → request from client

5. The mode of operation of Xiaoqu the code running on the → server

6. The audit of a car → CPU

So we have the following conclusion:

1. The first mode of operation is the traditional concurrency model, in which each Imax O stream (express) has a new thread (courier) management.

2. The second mode of operation is Ihammer O multiplexing. There is only a single thread (a courier) that manages multiple Ipicot O streams by tracking the status of each Ipicuro stream (the place of delivery of each delivery).

The following analogy to the real Redis threading model is shown in the figure:

Referring to the figure above, to put it simply, our Redis-client will produce Socket with different event types when operating. On the server side, there is an Imax O multiplexer program that places it in the queue. Then the file event dispatcher takes it from the queue in turn and forwards it to different event handlers.

It should be noted that the Redis O multiplexing mechanism, Redis also provides Select, Epoll, Evport, Kqueue and other multiplexing function libraries, you can understand.

Fourth, the data types of Redis and their respective usage scenarios

When you see this problem, do you think it is very basic? In fact, the author also thinks so. However, according to the interview experience, at least 80% of people can't answer this question. It is recommended that after using it in the project, then compare memory, experience more deeply, do not memorize it. Basically, a qualified programmer will use all five types:

1 、 String

In fact, there is nothing to say about this, the most conventional Set/Get operation, Value can be String or numbers, generally do some complex counting function of the cache.

2 、 Hash

Here Value stores structured objects, and it is convenient to manipulate one of the fields. When doing single sign-on, the author uses this data structure to store user information, uses CookieId as Key and sets 30 minutes as cache expiration time, which can well simulate the effect similar to Session.

3 、 List

Using the data structure of List, you can do a simple message queue function. Another is that you can use the Lrange command to do Redis-based paging with excellent performance and a good user experience.

4 、 Set

Because Set stacks a collection of unduplicated values, it can do global de-duplication.

Why not use the Set that comes with JVM to remove the weight? Because our systems are generally deployed in clusters, it is more troublesome to use the Set that comes with JVM. Is it possible to set up a public service in order to do a global de-duplication? It's too much trouble.

In addition, the use of intersection, union, subtraction and other operations, you can calculate common preferences, all preferences, their own unique preferences and other functions.

5 、 Sorted Set

Sorted Set has an extra weight parameter Score, and the elements in the collection can be arranged by Score. Can do ranking application, take TOP N operation. In addition, Sorted Set can also be used to do deferred tasks. The last application is to do a range search.

Fifth, the expiration strategy and memory elimination mechanism of Redis

This question is actually very important, from which we can see whether Redis is useful or not. For example, you can only store 5 gigabytes of data in Redis, but if you write 10 gigabytes, you will delete 5 gigabytes of data. How did you delete it? Have you thought about this question? Also, your data has set the expiration time, but the time is up, the memory occupancy rate is still relatively high, have you thought about the reason?

Redis uses a periodic delete + lazy delete strategy.

Why not delete policies regularly?

Delete regularly, use a timer to monitor the Key, and delete automatically when it expires. Although memory is released in time, it consumes CPU resources. In the case of large concurrent requests, CPU applies time to processing requests rather than deleting Key, so it does not adopt this strategy.

How does regular deletion + lazy deletion work?

Delete it periodically. By default, Redis checks each 100ms to see if there is an expired Key, and if there is an expired Key, delete it. It is important to note that Redis does not check all the Key once for every 100ms, but is randomly selected for inspection (if every other 100ms, all Key are checked, the Redis will not be stuck). Therefore, if you only use the periodic deletion policy, it will result in a lot of Key not being deleted by the time.

As a result, lazy deletion comes in handy. In other words, when you get a Key, Redis will check whether the Key has expired if it is set to expire. If it expires, it will be deleted.

Is there no other problem with regular deletion + lazy deletion?

No, if you delete Key periodically, you don't delete it. Then you didn't request Key in time, which means that lazy deletion didn't work either. In this way, the memory of Redis will be higher and higher, so the memory elimination mechanism should be adopted.

There is a line of configuration in Redis.conf:

# maxmemory-policy volatile-lru

This configuration is equipped with memory elimination strategy:

Noeviction: when there is not enough memory to hold new write data, the new write operation reports an error. No one should use it.

Allkeys-lru: when there is not enough memory to hold newly written data, remove the least recently used Key in the key space. Recommended. This is currently used in the project.

Allkeys-random: when there is not enough memory to hold newly written data, a key is randomly removed from the key space, and no one should use it.

Volatile-lru: when there is not enough memory to hold newly written data, remove the least recently used Key from the key space where the expiration time is set. In this case, Redis is generally used as both caching and persistent storage. Not recommended

Volatile-random: when there is not enough memory to hold newly written data, a Key is randomly removed from the key space where the expiration time is set. Still not recommended.

Volatile-ttl: when there is not enough memory to hold newly written data, Key with an earlier expiration time is removed first in the key space where the expiration time is set. Not recommended.

PS: if the Key of Expire is not set, the prerequisites (Prerequisites) are not met; then the behavior of Volatile-lru, Volatile-random, and Volatile-ttl policies is basically the same as that of Noeviction (do not delete).

VI. Consistency of double writes between Redis and database

Consistency problem is a common distributed problem, which can be subdivided into final consistency and strong consistency. Database and cache double write, there is bound to be inconsistent, to answer this question, we must first understand a premise: if there is a strong consistency requirement for data, you can not slow down 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.

"solving the problem of double write consistency between distributed database and cache"

A detailed analysis is given, and it is briefly said here: first, adopt the correct update strategy, update the database first, and then delete the cache; second, because there may be a problem of cache deletion failure, provide a compensatory measure, such as using message queues.

VII. Dealing with cache penetration and cache avalanche

With regard to the two questions of "how to deal with cache penetration and cache avalanche", to tell you the truth, it is very difficult for small and medium-sized traditional software enterprises to encounter. If there are large concurrent projects with millions of traffic, these two issues must be deeply considered:

1. Deal with cache traversal

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:

Using mutexes, when the cache fails, first get the lock, get the lock, and then request the database. If you don't get the lock, sleep for a period of time and try again.

1. 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. Cache warm-up (load the cache before the project starts) is required.

2. Provide an interception mechanism that can quickly determine 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 valid or not, and return directly if it is not legal.

2. Deal with cache avalanche

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 this 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 does not set the expiration time, and does the cache preheating operation by itself.

Then subdivide the following dots:

a. Read the database from cache A, and return it directly.

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

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

8. How to solve the problem of Redis concurrent competitive Key

The problem is that there are multiple subsystems to Set a Key at the same time. What should we pay attention to at this time? I did Baidu in advance and found that the answers we think about are basically recommended to use the Redis transaction mechanism. However, I 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.

The solution is as follows:

If the order is not required for this Key operation

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

If the order of this Key operation 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. Expect the value of Key1 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:

1. System A Key 1 {ValueA 3:00}

2. System B Key 1 {ValueB 3:05}

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

This is the end of the content about "what are the technical points of Redis". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

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.