A brief analysis of single-threaded and multi-threaded models in Redis6

This article will take you to understand the thread model in Redis6, and introduce the single-thread model and multi-thread model. I hope it will be helpful to you!

1. Evolution History of Redis

If we simply say that redis is single-threaded or multi-threaded, this answer is definitely not rigorous. The threading models used by different versions are different. [Related recommendations: Redis Video Tutorial]

• ## Version 3.x, the earliest version, is what everyone spreads by word of mouth redis is single threaded.

• Version 4.x, strictly speaking, is not single-threaded, but the thread responsible for processing client requests is single-threaded, but it has started to add some

  multi-threading Stuff (Asynchronous Deletion).

• After the latest version of 6.0.

2. Redis single-threaded model

2.1 The true meaning of single-thread

Mainly means that Redis's network IO and key-value pair reading and writing are completed by one thread. When Redis processes the client's request, it includes acquisition (socket reading), parsing, execution, content return (socket writing), etc. Processed by a sequential main thread, this is called "single threaded". This is also the main process for Redis to provide external key-value storage services.

But other functions of Redis, such as

persistence, asynchronous deletion, cluster data synchronization, etc., are actually executed by
extra threads.​ It can be said that the Redis worker thread is single-threaded. However, the entire Redis is multi-threaded;2.2 Reasons for fast single-thread performance

Redis 3 .x Single-threaded era but The main reason for fast performance:

Based on memory operations: all data is stored in memory, so all operations are at the memory levelSimple data structure: Redis's data structure is specially designed, and most of the time complexity of searching and operating these simple data structures is

o(1)

• Multiplexing and blocking IO: Use the IO multiplexing function to monitor multiple socket connections to the client, so that one thread connection can be used to process multiple requests, reducing the overhead caused by thread switching, and avoiding IO blocking operations.
• Avoid context switching: Because it is a single-threaded model, unnecessary context switching and multi-thread competition can be avoided. This can save the time and performance consumption caused by multi-thread switching, and single-thread switching can be avoided. Threads will not cause deadlock problems
• 2.3 Reasons for using single thread

Redis is based on memory operations, so it The bottleneck may be the machine's memory or network bandwidth rather than the CPU. Since the CPU is not the bottleneck, it is natural to use a single-threaded solution. Moreover, using multi-threading is more troublesome. However, Redis 4.0 began to support multi-threading, such as background deletion and other functions

.

Simply put, there are three main reasons why single-threading has been used before Redis 4.0: Using a single-threaded model makes the development and maintenance of Redis simpler, because single-threading The model facilitates development and debugging; although the multi-threaded model performs well in some aspects, it introduces uncertainty in the order of program execution, brings about a series of problems with concurrent reading and writing, increases system complexity, and may Performance loss caused by thread switching, even locking and unlocking, and deadlock. Redis has very high processing performance through AE event model and IO multiplexing and other technologies, so there is no need to use multi-threading. The single-thread mechanism greatly reduces the complexity of Redis's internal implementation. Hash's inertia, Rehash, Lpush and other "thread-unsafe" commands can be executed without locks.

• Even if the single-threaded model is used, multiple client requests can be processed concurrently, mainly using multiplexing and non-blocking IO;

• For the Redis system, the main

  performance bottleneck is memory or network bandwidth rather than CPU

  .

• 3. Redis multi-threading model

##3.1 Reasons for introducing multi-threading

Since single thread is so good, why introduce multi-threading? Single thread also has its own troubles, such as Large key deletion problem: Under normal circumstances, the del instruction can be used to delete data quickly. However, when the deleted key is a very large object, such as a hash set containing thousands of elements, the del instruction will cause the Redis main The thread is stuck.

Therefore, a new multi-threading module was added in Redis 4.0. Of course, the multi-threading in this version is mainly to solve the problem of relatively low data deletion efficiency. You can effectively avoid Redis lag problems (large key deletion, etc.) through lazy deletion. The steps are as follows:

• unlink key: with DEL It is a lazy free implementation of the same key deletion function. The only difference is that when UNLINK deletes a set type key, if the number of elements in the set key is greater than 64, the main thread only removes the key to be deleted from the database dictionary, and the real The memory release operation is performed by a separate bio. If the number of elements is small (less than 64) or of type String, they will also be deleted directly in the main thread.

• flushall/flushdb async: For the flush database command flushall/flushdb, the async asynchronous cleanup option is added, so that redis operates asynchronously when clearing the database. The implementation logic is to create a new empty dictionary for the database, and give the original old database dictionary to the background thread to delete the data one by one and release the memory.

• Handle the deletion work to the background child process to delete data asynchronously

Because Redis is processed by a single main thread, antirez, the father of redis, has always emphasized "Lazy Redis is better Redis". The essence of

lazy free is to remove certain costs (main time replication, occupying the main thread cpu time slice) with higher deletion operations, from redis The main thread is stripped to let the bio sub-thread handle it, which greatly reduces the main thread blocking time. This reduces performance and stability issues caused by deletion.

Redis 4.0 introduced multiple threads to implement functions such as asynchronous lazy deletion of data, but it still only has one thread to process read and write requests, so it is still considered a single thread in a narrow sense.

Analysis from the previous summary: The main performance bottleneck of Redis is memory or network bandwidth rather than CPU. The memory problem is relatively easy to solve, so the bottleneck of Redis is network IO. Next, the multi-threading model is introduced.

3.2 Working principle of multi-threading

I/O reading and writing itself is blocked. For example, when there is data in the socket, Redis The data will be copied from the kernel space to the user space through the call, and then handed over to Redis for the call. This copy process is blocking. When the amount of data is larger, the copy will take more time, and these operations are It is done based on single thread.

In Redis 6.0, a new

multi-threading function is added to improve the I/O read and write performance. His main implementation idea is to combine the IO read and write tasks of the main thread. Split it into a group of independent threads for execution, so that the reading and writing of multiple sockets can be parallelized. The use of multi-channel I/O multiplexing technology can allow a single thread to efficiently handle multiple connection requests (minimize the network IO time consumption), the most time-consuming Socket reading, request parsing, and writing are outsourced separately. The remaining command execution is still executed serially by the main thread and interacts with the data in the memory. Combined with the above figure, we can see that
reading and writing network data and parsing the request protocol are processed through multiple IO threads. For real command execution, the main thread operation is still used (thread safety), is a good compromise. Therefore, is multi-threaded for the entire Redis, but it is still single-threaded for the worker thread (command execution) .

3.3 Workflow

The core process is roughly as follows:

The process is briefly described as follows:

The main thread obtains the socket and puts it in the waiting list
• Assign the socket to each IO thread (not wait for the list to be full)
• Main thread
• Block and wait for the IO thread (multi-thread)Reading the socket is completed
Main thread execution command -
• Single thread (If the command is not received, it will wait for IO to continue next time)
Main thread
• Blocked waiting for IO thread (multi-threaded) Completed writing the data back to the socket (if it is not finished once, it will be written again next time)
Unbind and clear the waiting queue

Features are as follows:

• The IO thread is either reading the socket at the same time, or writing at the same time, and will not read or write at the same time.
• The IO thread is only responsible for reading and writing socket parsing commands, and is not responsible for command processing (the main thread executes serially Command)
• The number of IO threads can be configured by yourself (The current code limit is 512, the default is 1 (turn off this function))

After careful consideration Stress test, The current performance can be improved by more than 1 times.

Question 1: Is the waiting list always blocked and not processed if it is not full?
Reply: What is detected when blocking is whether the IO thread still has tasks. Wait until the processing is completed before continuing. These tasks are added during execution. If the number of tasks I still have some doubts about this. Can anyone explain it (comment)?

3.4 Is multi-threading enabled by default?

In Redis6.0, The multi-threading mechanism is turned off by default. If you need to use the multi-threading function, you need to complete two settings in redis.conf.

• Set the io-thread-do-reads configuration item to yes to start multi-threading.
• Set the number of threads. Regarding the setting of the number of threads, the official recommendation is that if it is a 4-core CPU, it is recommended that the number of threads be set to 2 or 3. If it is an 8-core CPU, it is recommended that the number of threads be set to 6. The number of threads must be less than The number of machine cores and threads is not necessarily better.

4. Summary

Redis itself is excellent since its debut, based on memory operations, simple data structure, multiplexing and non-blocking I/O, avoiding It eliminates unnecessary thread context switching and other features, and is still very fast in a single-threaded environment;

But the key deletion of big data is still very slow, so multi-threaded unlink key/flushall was introduced in Redis 4.0 Commands such as async are mainly used for asynchronous deletion of Redis data;

I/O multi-threaded reading and writing was introduced in Redis 6.0, so that more tasks can be processed more efficiently. Redis just Turn I/O reading and writing into multi-threading , and command execution is still executed serially by the main thread , so operating Redis under multi-threading will not A thread safety issue occurs.

Redis Whether it is the original single-threaded design or the current multi-threaded design that is contrary to the original design, there is only one purpose: to make Redis faster and faster.

For more programming-related knowledge, please visit: Introduction to Programming! !

The above is the detailed content of A brief analysis of single-threaded and multi-threaded models in Redis6. For more information, please follow other related articles on the PHP Chinese website!