How to make redis distributed

1 Why use Redis

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.

Performance:

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.

Concurrency:

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.

Frequently asked questions about using Redis

• Cache and database double-write consistency issues
• Cache Avalanche problem
• Cache breakdown problem
• Cache concurrency competition problem

Why is single-threaded Redis so fast

This question is an investigation of the internal mechanism of Redis. Many people don't know that Redis has a single-threaded working model.

The reasons are mainly due to the following three points:

• Pure memory operation
• Single-thread operation avoids frequent context switching
• Using a non-blocking I/O multiplexing mechanism

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.

Business Method 1

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.

• As the number of orders increased, so did the number of delivery people. Xiao Ming found that the express store was getting more and more crowded and there was no way to hire new delivery people.
• Coordination among delivery personnel takes time.
• Based on the above shortcomings, Xiao Ming learned from the experience and proposed the second management method.

Business method two

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.

In the above metaphor:

• Each delivery person→Each thread
• Each order→Each Socket (I/O stream)
• The delivery location of the order→The different states of the Socket
• Customer food delivery request→Request from the client
• Mingqu’s business method→The code running on the server
• The number of cores of a car→CPU

So we have the following conclusion:

• The first business method is the traditional concurrency model, each Each I/O stream (order) is managed by a new thread (delivery worker).
• The second management method is I/O multiplexing. There is only a single thread (one delivery person) that manages multiple I/O streams by tracking the status of each I/O stream (the delivery location of each delivery person).

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.

Three Redis data types and usage scenarios

A qualified programmer will use these five types.

String

The most common set/get operation, Value can be a String or a number. Generally, some complex counting functions are cached.

Hash

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.

List

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.

Set

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

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.

Four Redis expiration strategy and memory elimination mechanism

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.

Why not use a scheduled 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 How lazy deletion works

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.

If regular deletion is used, there will be no other problems with lazy deletion.

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

This configuration is equipped with the memory elimination strategy:

• noeviction: When the memory is insufficient to accommodate the newly written data, the new write operation will report an error.
• allkeys-lru: When the memory is insufficient to accommodate newly written data, in the key space, remove the least recently used Key. (Recommended, this is currently used in the project) (The most recently used algorithm)
• allkeys-random: When the memory is not enough to accommodate newly written data, a Key is randomly removed from the key space. . (No one should use it. If you don’t delete it, at least use the Key and delete it randomly)
• volatile-lru: When the memory is not enough to accommodate the newly written data, in the key space with the expiration time set, Remove the least recently used Key. This situation is generally used when Redis is used as both a cache and a persistent storage. (Not recommended)
• volatile-random: When the memory is not enough to accommodate newly written data, randomly remove a Key in the key space with an expiration time set. (Still not recommended)
• volatile-ttl: When the memory is not enough to accommodate newly written data, in the key space with an expiration time set, the Key with an earlier expiration time will be removed first. (Not recommended)

Five Redis and database double-write consistency issues

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.

6 How to deal with cache penetration and cache avalanche problems

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 penetration solution:

• Use mutex lock. When the cache fails, first get the lock and get the lock , and then request the database. If the lock is not obtained, it will sleep for a while and try again.
• Adopt Asynchronous update strategy, regardless of whether the Key gets the value, it will be returned directly. 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.
• Provide an interception mechanism that can quickly determine whether the request is valid. For example, using 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. As a result, the requests are all sent to the database, resulting in an abnormal database connection.

Cache avalanche solution:

• Add a random value to the cache expiration time to avoid collective failure.
• Use mutex lock, but the throughput of this solution drops significantly.
• Double cache. 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: read the database from cache A, and return directly if there is any; A has no data, read data directly from B, return directly, and start an update thread asynchronously, and the update thread updates at the same time Cache A and Cache B.

8 How to solve the concurrency competition Key problem of Redis

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!

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!