Redis 6.0 new features: take you 100% to master 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. RESP3 protocol;
5. The RDB file used for copying is no longer useful and will be deleted immediately;
6. RDB file loading speed is faster;

The one that has attracted much attention is the " multi-threaded model + client-side cache ". Only when we master the principles of the new features can we judge when to use the 6.0 version, how to use it better and faster, without stepping on the pit.

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 greatly reduces the complexity of Redis's internal implementation. Hash's lazy Rehash, Lpush, and other "thread-unsafe" commands can be performed without lock .

in " Redis Why is 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 the client's request, including acquisition (socket reading), parsing, execution, content return (socket writing), etc., all 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 reach 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: single thread processing network read and write speed can not 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.

In addition, new code may introduce new bugs, causing 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, is still processed in a single thread.

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

While continuing to use 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 is as follows :

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 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. To enable 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 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 is only to read client request commands and parse them through sockets, but there is no real To execute the order.

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.