When using Redis in a project, there are two main considerations: performance and concurrency. If it is just for other functions such as distributed locks, there are other middlewares such as Zookpeer instead, and it is not necessary to use Redis.
As shown in the figure below, it is particularly suitable when we encounter SQL that needs to be executed for a particularly long time and the results do not change frequently. Put the running results into the cache. In this way, subsequent requests will be read from the cache, so that requests can be responded to quickly.
Especially in the flash sale system, at the same time, almost everyone is clicking and placing orders. . . The same operation is performed - querying the database for data.
Depending on the interaction effect, there is no fixed standard for response time. In an ideal world, our page jumps need to be resolved in an instant, and in-page operations need to be resolved in an instant.
As shown in the figure below, in the case of large concurrency, all requests directly access the database, and a connection exception will occur in the database. At this time, you need to use Redis to perform a buffering operation so that the request can access Redis first instead of directly accessing the database.
This question is an investigation of the internal mechanism of Redis. Many people don't know that Redis has a single-threaded working model.
Let’s talk about the I/O multiplexing mechanism in detail, using an analogy: Xiao Ming opened a fast food in City A DianDian is responsible for fast food service in the city. Due to financial constraints, Xiao Ming hired a group of delivery people. Then Xiao Qu found that the funds were not enough and he could only buy a car to deliver express delivery.
Every time a customer places an order, Xiao Ming will have a delivery person keep an eye on it and then have someone drive to deliver it. Slowly Xiaoqu discovered the following problems with this mode of operation:
Time was spent on grabbing cars, and most of the delivery people were idle. A car can be used to deliver it.
Xiao Ming only hires one delivery person. When a customer places an order, Xiao Ming marks the delivery location and places it in one place. Finally, let the delivery person drive the car to deliver the items one by one, and come back to pick up the next one after delivery. Comparing the above two business methods, it is obvious that the second one is more efficient.
The following is an analogy to the real Redis thread model, as shown in the figure:
Redis-client will have different characteristics when operating Socket of event type. On the server side, there is an I/O multiplexer that puts it into a queue. Then, the file event dispatcher takes it from the queue in turn and forwards it to different event processors.
A qualified programmer will use these five types.
The most common set/get operation, Value can be a String or a number. Generally, some complex counting functions are cached. The Value here stores a structured object, and it is more convenient to operate a certain field in it. When I was doing single sign-on, I used this data structure to store user information, using CookieId as the Key, and setting 30 minutes as the cache expiration time, which can simulate a Session-like effect very well. Using the List data structure, you can perform simple message queue functions. In addition, you canuse the lrange command to implement Redis-based paging function, which has excellent performance and good user experience. Because Set stacks a collection of unique values. Therefore, the global deduplication function can be implemented. Our systems are generally deployed in clusters, and it is troublesome to use the Set that comes with the JVM. In addition, uses intersection, union, difference and other operations to calculate common preferences, all preferences, your own unique preferences and other functions. Sorted Set has an additional weight parameter Score, and the elements in the set can be arranged according to Score. You can do ranking application and take TOP N operations. Sorted Set can be used to do delayed tasks. Whether Redis is used at home can be seen from this. For example, your Redis can only store 5G data, but if you write 10G, 5G of data will be deleted. How did you delete it? Have you thought about this issue? Correct answer: Redis adopts a regular deletion and lazy deletion strategy. Delete regularly, use a timer to monitor the Key, and delete it automatically when it expires. Although the memory is released in time, it consumes a lot of CPU resources. Under large concurrent requests, the CPU needs to use time to process the request instead of deleting the Key, so this strategy is not adopted. Regular deletion, Redis checks every 100ms by default, and deletes expired keys. It should be noted that Redis does not check all Keys every 100ms, but randomly selects them for checking. If you only adopt a regular deletion strategy, many keys will not be deleted by the time. So lazy deletion comes in handy. No, if regular deletion does not delete the Key. And you did not request the Key in time, which means that lazy deletion did not take effect. In this way, the memory of Redis will become higher and higher. Then the memory elimination mechanism should be adopted. There is a line of configuration in redis.conf: # maxmemory-policy volatile-lru Consistency issues can also be further divided intoeventual consistency and strong consistency. If the database and cache are double-written, there will inevitably be inconsistencies. The premise is that if there are strong consistency requirements for the data, it cannot be cached. Everything we do can only guarantee eventual consistency. In addition, the solution we have made can only reduce the probability of inconsistency. Therefore, data with strong consistency requirements cannot be cached. First, 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, just provide a compensation measure, such as using message queues. These two problems are generally difficult for small and medium-sized traditional software companies to encounter. If you have a large concurrent project with a traffic of millions, these two issues must be considered deeply. Cache penetration means that hackers deliberately request data that does not exist in the cache, causing all requests to be sent to the database, causing the database connection to be abnormal. Cache avalanche, that is, the cache fails in a large area at the same time. At this time, another wave of requests comes. As a result, the requests are all sent to the database, resulting in an abnormal database connection. This problem is roughly,There are multiple subsystems to Set a Key at the same time. What should we pay attention to at this time? Everyone basically recommends using Redis transaction mechanism. But it is not recommended to use the Redis transaction mechanism. Because our production environment is basically a Redis cluster environment, and data sharding operations are performed. When a transaction involves multiple Key operations, these multiple Keys are not necessarily stored on the same redis-server. Therefore, the transaction mechanism of Redis is very useless. If you operate on this Key, does not require the order In this case, prepare a distribution Type lock, everyone goes to grab the lock, and just do the set operation after grabbing the lock, which is relatively simple. If you operate on this Key, requires the order Assuming 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 valueC. It is expected that the value of key1 will change in the order of valueA > valueB > valueC. At this time, when data is written to the database, we need to save a timestamp . Assume 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, assuming that System B grabs the lock first, set 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. Other methods, such as using queues and turning the set method into serial access, can also . For more Redis-related technical articles, please visit the Redis Tutorial## column to learn! Hash
List
Set
Sorted Set
Four Redis expiration strategy and memory elimination mechanism
Why not use a scheduled deletion strategy
Regular deletion How lazy deletion works
If regular deletion is used, there will be no other problems with lazy deletion.
This configuration is equipped with the memory elimination strategy:
Five Redis and database double-write consistency issues
6 How to deal with cache penetration and cache avalanche problems
Cache penetration solution:
Cache avalanche solution:
8 How to solve the concurrency competition Key problem of Redis
The above is the detailed content of How to make redis distributed. For more information, please follow other related articles on the PHP Chinese website!