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

The content of this article mainly focuses on how to analyze the single-threaded and multithreaded models in Redis6. The content of the article is clear and clear. It is very suitable for beginners to learn and is worth reading. Interested friends can follow the editor to read together. I hope you can get something through this article!

1. The evolutionary history of Redis

If you simply say that redis is single-threaded or multithreaded, this answer is certainly not rigorous, and different versions use different threading models. [related recommendation: Redis video tutorial]

Version 3.x, the earliest version, that is, 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 begins to add something multi-threaded (asynchronous deletion).

After the latest version of 6.0.x, we bid farewell to the impression of single-threading and use a new kind of multithreading to solve the problem.

2. Redis single thread model

2.1 True meaning of single thread

It mainly means that the network IO of Redis and the read and write of key-value pair are completed by a thread. When Redis deals with client requests, including acquisition (socket read), parsing, execution, content return (socket write), and so on, it is handled by a sequential main thread, which is called "single thread". This is also the main process for Redis to provide key storage services.

But other functions of Redis, such as persistence, asynchronous deletion, cluster data synchronization, and so on, are actually performed by additional threads. It can be said that Redis worker threads are single-threaded. However, for the whole Redis, it is multithreaded

2.2 reasons for fast performance of single thread

Redis 3.x single-threaded era, but the main reasons for fast performance:

Memory-based operations: all data is stored in memory, so all operations are memory-level

The data structure is simple: the data structure of Redis is specially designed, and the search and operation time of these simple data structures is mostly o (1).

Multiplexing and fee blocking IO: use IO multiplexing to monitor multiple socket connection clients, so that multiple requests can be processed using a single thread connection, reducing the overhead of thread switching and avoiding IO blocking operations

Avoid context switching: because it is a single-threaded model, unnecessary previous switching and multithreaded competition can be avoided, thus saving time and performance consumption caused by multithreaded switching, and single-threading will not cause deadlock problems.

2.3 reasons for using single thread

Redis is based on memory operation, so its bottleneck may be machine memory or network bandwidth rather than CPU. Since CPU is not a bottleneck, it is natural to adopt a single-threaded solution, and it is troublesome to use multithreading. However, multi-threading, such as background deletion, has been supported in Redis 4.0.

In a nutshell, there are three main reasons why Redis used to be single-threaded until 4. 0:

Using the single-thread model makes the development and maintenance of Redis easier, because the single-thread model is convenient for development and debugging; although the multi-thread model performs well in some aspects, it introduces the uncertainty of program execution order, brings a series of problems of concurrent reading and writing, and increases the complexity of the system, and may cause performance loss caused by thread switching, even locking and unlocking, and deadlock. Redis has very high processing performance through technologies such as AE event model and IO multiplexing, so there is no need to use multithreading. The single-thread mechanism greatly reduces the complexity of the internal implementation of Redis, and Hash's lazy Rehash, Lpush and other "thread-unsafe" commands can be carried out without locks.

Multi-client requests are processed concurrently even using a single-threaded model, mainly using multiplexed and non-blocking IO

For Redis systems, the main performance bottleneck is memory or network bandwidth rather than CPU.

3. Redis multithreading model

3.1 reasons for introducing multithreading

If single threading is so good, why introduce multithreading? Single threading also has its own troubles, such as large key deletion problems: normally, using the del instruction can quickly delete data, but when the deleted key is a very large object, for example, when the hash collection contains thousands of elements, then the del instruction will cause stutters in the Redis main thread.

Therefore, the multithreading module has been added in Redis 4.0. of course, the multithreading in this version is mainly to solve the problem of low efficiency of deleting data. The Redi stutter problem (such as big key deletion) can be effectively avoided by lazy deletion. The steps are as follows:

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

Flushall/flushdb async: for the empty database command flushall/flushdb, added the async asynchronous cleanup option so that redis operates asynchronously when emptying 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 free memory.

The deletion work is left to the backstage child process to delete data asynchronously.

Because Redis is 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 some cost (main time complex system, occupy the cpu time slice of the main thread) higher, peel off the redis main thread and let the bio child thread to deal with it, which greatly reduces the main line blocking time. This reduces the performance and stability problems caused by deletions.

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

From the previous summary, the main performance bottleneck of Redis is memory or network bandwidth rather than CPU. The memory problem is easy to solve, so the bottleneck of Redis is network IO. Next, the multithreading model is introduced.

3.2 how multithreading works

The read and write of socket O is blocked. For example, when there is data in socket, Redis will copy the data from kernel state space to user state space through call, and then give it to Redis to call. The process of copying is blocked, and the larger the amount of data, the more time it takes to copy, and these operations are all based on a single thread.

Multithreading is added to Redis 6.0to improve the read and write performance of socket. His main implementation idea is to split the IO read and write task of the main thread into a group of independent threads to execute, so that the read and write of multiple socket can be parallelized. Using multi-channel socket reuse technology can enable a single thread to process multiple connection requests efficiently (minimize the time consumption of network IO). The most time-consuming reading, request parsing and writing of Socket are outsourced separately, and the rest of the command execution is still executed serially by the main thread and interacts with the data in memory.

Combined with the above figure, we can see that reading and writing network data and parsing request protocols through multiple IO threads is still a good compromise for real command execution using main thread operations (thread safety). Therefore, it is multithreaded for the entire Redis, but still single-threaded for worker threads (command execution).

3.3 Workflow

The core process is roughly as follows:

The process is summarized as follows:

The main thread gets the socket and puts it on the waiting list

Assign socket to each IO thread (does not wait for the list to be full)

Main thread blocking waiting for IO thread (multi-thread) to read socket finished

Main thread executes commands-single thread (if the command is not received, it will wait for IO to continue next time)

The main thread blocks and waits for the IO thread (multithread) to write the data back to the socket (if it is not finished once, it will be written again next time)

Unbind and empty the waiting queue

The features are as follows:

IO threads are either reading socket 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, not for command processing (serial execution of commands by the main thread)

The number of IO threads can be configured by yourself (currently, the maximum code limit is 512, and the default is 1 (disable this feature))

After the pressure test of willing people, the current performance can be improved by more than 100%.

Question 1: has the waiting list been blocked and not dealt with?

Reply: when blocking, it detects whether the IO thread still has tasks. Don't move on until you're done with it. These tasks are added at execution time, and if the number of tasks is less than the number of threads, then some threads will not get the task, and its pending task is 0. For the thread that assigned the task, after handling the IO event, the pending will clear zero, and the thread that does not get the task pending is originally 0, so it will not block. There is still some doubt in this area, which boss can explain it (comments, ha)?

3.4 is multithreading enabled by default?

In Redis6.0, multithreading is off by default, and if you need to use multithreading, you need to complete two settings in redis.conf.

Set the io-thread-do-reads configuration item to yes, which means to start multithreading.

Sets the number of threads. With regard to the setting of the number of threads, the official recommendation is that if the number of threads is set to 2 or 3 for 4-core CPU, and 6 for 8-core CPU, the number of threads must be less than the number of machine cores. The larger the number of threads, the better.

4. Summary

Redis is excellent in its own debut. Based on the characteristics of memory operation, simple data structure, multiplexing and non-blocking Ipaw O, and avoiding unnecessary thread context switching, it is still fast in a single-threaded environment.

However, big data's key deletion is still stuttered, so commands such as multithreaded unlink key/flushall async are introduced in Redis 4.0.It is mainly used for asynchronous deletion of Redis data.

However, the multi-thread read and write of Redis is introduced in Redis 6.0.This way it can deal with more tasks more efficiently. Redis only changes the read and write of Redis into multi-thread, and the execution of the command is still executed by the main thread, so there is no thread safety problem in the operation of IMAGO under multi-thread.

Redis, whether it was a single-threaded design or a multithreaded design that is now contrary to the original design, has only one purpose: to make Redis faster and faster.

Thank you for your reading. I believe you have some understanding of "how to analyze the single-threaded and multithreaded models in Redis6". Go ahead and practice it. If you want to know more about it, you can follow the website! The editor will continue to bring you better articles!

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.