Redis new features: 100% mastering the multi-threaded model

Redis officially launched version 6.0 in May 2020, providing many exciting new features, so it has attracted much attention.

The code is old and wet, what features does it provide? Can I get a raise after knowing it?

The main features are as follows:

1. Multi-threaded processing network IO;
2. Client-side cache;
3. Fine-grained access control (ACL);
4. The use of the RESP3
5. The RDB file used for copying is no longer useful and will be deleted immediately;
6. RDB file loading speed is faster;

One of the most concerned is " multi-threaded model + client-side cache ". Only when we have mastered the principles of new features can we judge when to use version 6.0, how to use it better and faster, without stepping on pits.

This article starts with Redis multi-threaded model . As for client-side caching, wait and listen to the next decomposition.

Finally, click on the card below to pay attention to "Megabytes" to get a salary increase.

The code is old and wet, why not use multi-threading before Redis 6.0?

Official reply:

• When using Redis, there is almost no CPU becoming a bottleneck. Redis is mainly limited by memory and network.
• On an ordinary Linux system, Redis pipelining , so if the application mainly uses O(N) or O(log(N)) commands, it will hardly take up too much CPU .
• After using single thread, maintainability is high. Although the multi-threaded model performs well in some aspects, it introduces the uncertainty of program execution order, brings a series of problems of concurrent reading and writing, increases the complexity of the system, and may have thread switching or even locking. Performance loss caused by unlocking and deadlock.

Redis through the AE event model and IO multiplexing and other technologies, the processing performance is very high, so there is no need to use multi-threading.

single-threaded mechanism of 161306955a142f greatly reduces the complexity of Redis's internal implementation. Hash's lazy Rehash, Lpush, and other "thread-unsafe" commands can all be performed without locks .

in " Redis Why is it so fast? " Code brother has a detailed introduction to the principle of fast .

Before Redis 6.0, single thread means that Redis has only one thread to work?

No, Redis processes client requests, including acquisition (socket reading), parsing, execution, content return (socket writing), etc., all are processed by a sequential serial main thread, which is the so-called "single thread" .

In the command execution stage, since Redis is a single thread to process commands, all commands that arrive at the server will not be executed immediately. All commands will enter a Socket queue. When the socket is readable, it will be handed over to the single-threaded event dispatcher one by one. Be executed.

In addition, some command operations can be executed by background threads or sub-processes (such as data deletion, snapshot generation, AOF rewriting).

The code is too wet, so why does Redis 6.0 introduce multi-threading?

With the improvement of hardware performance, the performance bottleneck of Redis may appear network IO read and write, that is: The speed of single thread processing network read and write cannot keep up with the speed of the underlying network hardware .

read/write system call that reads and writes the network occupies most of the CPU time during Redis execution. The bottleneck is mainly the IO consumption of the network. There are two main directions for optimization:

• To improve network IO performance, typical implementations such as using DPDK to replace the kernel network stack.
• Use multi-threading to make full use of multi-core and improve the parallelism of network request read and write. A typical implementation is Memcached .

To add support for the user-mode network protocol stack, you need to modify the network-related parts of the Redis source code (for example, modify all network sending and receiving request functions), which will bring a lot of development workload.

Moreover, the new code may also introduce new bugs, leading to system instability.

Therefore, Redis uses multiple IO threads to process network requests to improve the parallelism of network request processing.

should be noted that the Redis multi-IO thread model is only used to process network read and write requests. For Redis read and write commands, it is still single-threaded processing .

This is because network processing is often a bottleneck, and multi-threaded parallel processing can improve performance.

However, if you continue to use a single thread to execute read and write commands, there is no need to develop a multi-threaded safety mechanism to ensure Lua scripts, transactions, etc., and the implementation is simpler.

architecture diagram of as follows: 161306955a168b:

How do the main thread and IO multithreading cooperate?

As shown below:

main process :

1. The main thread is responsible for receiving the connection establishment request, obtaining socket placing it in the global waiting read processing queue;
2. The main thread socket to the IO thread through polling;
3. The main thread blocks and waits for the IO thread to read socket complete;
4. The main thread executes the Redis request command read and parsed by the IO thread;
5. The main thread blocks and waits for the IO thread to write back the instruction execution result back to socket ;
6. The main thread empties the global queue and waits for subsequent requests from the client.

Idea: the main thread IO read and write tasks into a group of independent threads for processing, so that multiple socket reads and writes can be parallelized, but Redis commands are still executed in the main thread serially.

How to enable multithreading?

Redis 6.0's multi-threading is disabled by default, and only the main thread is used. If you need to open it, you need to modify the redis.conf configuration file: io-threads-do-reads yes .

The code is old and wet, is the number of threads the better?

Of course not. Regarding the setting of the number of threads, there is an official recommendation: 4 cores are recommended to be set to 2 or 3 threads, and 8 cores are recommended to be set to 6 threads. The number of threads must be less than the number of machine cores.

The number of threads is not as large as possible. Officials believe that more than 8 is basically meaningless.

In addition, after enabling multi-threading, you also need to set the number of threads, otherwise will not take effect.

io-threads 4

Summary and reflection

With the rapid development of the Internet, the online traffic that the Internet business system has to deal with is increasing. Redis's single-threaded mode will cause the system to consume a lot of CPU time on network I/O, thereby reducing throughput. It is necessary to improve the performance of Redis. Two directions:

• Optimize network I/O modules
• Improve the speed of machine memory read and write

The latter depends on the development of hardware and has no solution for the time being. Therefore, we can only start with the former, and the optimization of network I/O can be divided into two directions:

• Zero copy technology or DPDK technology
• Take advantage of multi-core

model defect

Redis's multi-threaded network model is actually not a standard Multi-Reactors/Master-Workers model.

In Redis's multi-threaded solution, the I/O thread task only reads and parses the client request command through the socket, but does not actually execute the command.

All client commands need to return to the main thread for execution at the end, so the utilization of multi-core is not high, and each time the main thread must be busy polling after all the I/O threads have completed the task after the task is assigned. Continue to execute other logic.

In my opinion, Redis's current multi-threading solution is more like a compromise: it not only maintains the compatibility of the original system, but also uses multi-core to improve I/O performance.