Why does Redis introduce multi-threading?

1. Overview of the problem

The versions after Redis 6.0 abandoned the design of single-threaded model. Redis, which originally used single-threaded operation, also began to selectively use multi-threaded model. At first glance, Redis The author is so awesome, but he can't escape the "law of true fragrance".

If you think about it carefully, this question can actually be split into two main questions:

(1) Why did Redis choose a single-threaded model at the beginning (the benefits of single-threading)?

(2) Why did Redis add multi-threading after 6.0 (in some cases, single-threading has shortcomings, which can be solved by multi-threading)?

In fact, it’s not that the author has not escaped the True Fragrance Theorem, but as time goes by, more and more problems arise. The original design must be somewhat out of date, and changes should be made. OK, with two questions, let’s analyze them carefully.

2. Why did Redis use single thread at the beginning?

Whether it is single thread or multi-thread, it is all to improve the development efficiency of Redis, because Redis is a memory-based database and needs to be processed. A large number of external network requests inevitably require multiple IOs. Fortunately, Redis uses many excellent mechanisms to ensure its high efficiency. So why is Redis designed in single-threaded mode? It can be summarized as follows:

(1) IO multiplexing

Let’s take a look at the top-level design of Redis.

FD is a file descriptor, which means whether the current file is readable, writable or abnormal. Use the I/O multiplexing mechanism to monitor the readable and writable status of multiple file descriptors simultaneously. You can understand it as having the characteristics of multi-threading.

Once a network request is received, it will be processed quickly in memory. Since most operations are purely memory-based, the processing speed will be very fast. That is to say, in single-threaded mode, even if there is a lot of connected network processing, it can still be ignored in high-speed memory processing because of IO multiplexing.

(2) High maintainability

Although the multi-threading model performs well, it will introduce uncertainty in the order of program execution, thus causing problems related to concurrent reading and writing. . Single-threaded mode allows for easy debugging and testing.

(3) Based on memory, the efficiency is still high in single-threaded state

Multi-threading can make full use of CPU resources, but for Redis, because the memory-based speed is quite high, It can handle 100,000 user requests in one second. If 100,000 in one second is not enough, then we can use Redis sharding technology to deliver it to different Redis servers. This cooking method avoids introducing a lot of multi-threaded operations in the same Redis service.

Unless AOF backup is required, this operation basically does not involve any I/O operations because it is memory-based. Since the reading and writing of these data only occur in memory, the processing speed is very fast; using a multi-threading model to handle all external requests may not be a good solution.

Now we know that it can be basically summed up in two sentences. It is based on memory and uses multiplexing technology. The single-thread speed is very fast and the characteristics of multi-threading are guaranteed. Because there is no need to use multithreading.

3. Why introduce multi-threading?

We just mentioned the advantages of single-threading, but now I want to talk about why we need to introduce multi-threading and overcome the discomfort with it. The introduction of multi-threading shows that in some aspects of Redis, single-threading no longer has advantages.

Because the read/write system calls for reading and writing the network take up most of the CPU time during Redis execution, if the network reading and writing is made multi-threaded, the performance will be greatly improved.

Redis's multi-threading is only used for network data reading and writing and protocol parsing, while command execution is still single-threaded. The reason for this design is that we do not want Redis to become complicated due to multi-threading, and we need to control concurrency issues such as keys, lua, transactions, LPUSH/LPOP, etc.

Redis has added some deletion operations that can be processed asynchronously by other threads in the latest versions, which are the UNLINK and FLUSHALL ASYNC## we mentioned above. # and FLUSHDB ASYNC, why do we need these deletion operations, and why do they need to be processed asynchronously through multi-threading?

We know that Redis can use the del command to delete an element. If the element is very large, which may occupy dozens of megabytes or hundreds of megabytes, it cannot be completed in a short time. In this way, it is necessary Multi-threaded asynchronous support.

Deletion work can now be done in the background.

The above is the detailed content of Why does Redis introduce multi-threading?. For more information, please follow other related articles on the PHP Chinese website!