Redis officially launched version 6.0 in May 2020, providing many exciting new features, so it has attracted much attention.
What features does yard old wet provide? I see. Can I get a raise?
The main features are as follows:
- Multithreaded processing network IO;
- Client cache;
- Fine grained permission control (ACL);
RESP3Use of the agreement;
- The RDB file used for copying is no longer useful and will be deleted immediately;
- RDB files load faster;
One of the most concerned is “Multithreading model + client cache“Only when we master the principle of new features can we judge when to use version 6.0 and how to use it better and faster without stepping on the pit.
This article starts withRedis multithreading modelAt first, as for client caching, and so on, listen to the next chapter.
Finally, click the card below and pay attention to “code byte” to get a raise.
Why didn’t you use multithreading before redis 6.0?
- When using redis, there is almost no CPU bottleneck. Redis is mainly limited by memory and network.
- On an ordinary Linux system, redis uses
pipeliningOne million requests can be processed per second, so if the application mainly uses o (n) or O (log (n)) commands, it will hardly consume too much CPU.
- After using single thread, the maintainability is high. Although the multithreading model has excellent performance in some aspects, it introduces the uncertainty of program execution order, brings a series of problems of concurrent reading and writing, increases the system complexity, and may have performance loss caused by thread switching, lock unlocking and deadlock.
Redis has very high processing performance through AE event model, IO multiplexing and other technologies, so it is not necessary to use multithreading.
The single thread mechanism greatly reduces the complexity of redis’s internal implementation. Hash’s inert rehash, lpush and other “thread unsafe” commands can be carried out without locks。
In《Why is redis so fast?》Code brother introduces the principle of fast in detail。
Before redis 6.0, does single thread mean that there is only one thread working in redis?
No,Redis processes the client’s requests, including acquisition (socket read), parsing, execution, content return (socket write), etc. by a sequential serial main thread, which is the so-called “single thread”。
In the command execution phase, because redis processes commands in a single thread, all commands arriving at the server will not be executed immediately. All commands will enter a socket queue. When the socket is readable, they will be handed over to the single thread event distributor for execution one by one.
In addition, some command operations can be performed by background threads or child processes (such as data deletion, snapshot generation, AOF rewriting).
Why does redis 6.0 introduce multithreading?
With the improvement of hardware performance, the performance bottleneck of redis may be the reading and writing of network IO, that is:The speed of a single thread processing network read and write can not keep up with the speed of the underlying network hardware。
Read write network
read/writeThe system call takes up most of the CPU time during redis execution. The bottleneck mainly lies in the IO consumption of the network. There are two main directions for optimization:
- To improve network IO performance, typical implementations, such as using
DPDKTo replace the kernel network stack.
- Use multithreading, make full use of multi-core, and improve the parallelism of network request reading and writing. Typical implementations, such as
To add support for user mode network protocol stack, you need to modify the network related parts of redis source code (for example, modify all network transceiver request functions), which will bring a lot of development workload.
Moreover, the new code may also introduce new bugs, resulting in system instability.
Therefore, redis uses multiple IO threads to process network requests to improve the parallelism of network request processing.
It should be noted that redis multi IO threading model is only used to process network read-write requests, and redis read-write commands are still processed by single thread。
This is because network processing is often the bottleneck, and multi-threaded parallel processing can improve performance.
If you continue to use a single thread to execute read-write commands, you do not need to develop multi-threaded security mechanisms to ensure Lua scripts, transactions, etc., and the implementation is simpler.
The architecture is shown below：
How do main threads and IO multithreads cooperate?
As shown below:
- The main thread is responsible for receiving the connection establishment request and obtaining
socketPut it into the global read waiting queue;
- The main thread will be readable by polling
socketAllocated to IO threads;
- The main thread is blocked waiting for the IO thread to read
- The main thread executes the redis request command read and parsed by the IO thread;
- The main thread blocks waiting for the IO thread to write back the instruction execution result
- The main thread empties the global queue and waits for subsequent requests from the client.
Idea:The IO read / write task of the main thread is split and processed by a group of independent threads, so that the read / write of multiple sockets can be parallelized, but the redis command is still executed serially by the main thread.
How to turn on Multithreading?
Multithreading in redis 6.0 is disabled by default and only the main thread is used. If you need to open it, you need to modify it
Code is old and wet. Is the number of threads the better?
Of course not. There is an official suggestion on the number of threads: 2 or 3 threads for 4-core machines and 6 threads for 8-core machines. The number of threads must be less than the number of machine cores.
The larger the number of threads, the better. Officials believe that more than 8 threads are basically meaningless.
In addition, after multithreading is enabled, you also need to set the number of threads, otherwise it will not take effect。
Summary and thinking
With the rapid development of the Internet, the Internet business system needs to handle more and more online traffic. Redis’s single thread mode will cause the system to consume a lot of CPU time on network I / O, thus reducing throughput. There are two directions to improve redis’s performance:
- Optimize network I / O modules
- Improve the speed of reading and writing machine memory
The latter depends on the development of hardware and has no solution for the time being. Therefore, we can only start from the former. The optimization of network I / O can be divided into two directions:
- Zero copy technology or dpdk Technology
- Take advantage of multi-core
In fact, redis’s multi-threaded network model is not a standard multi reactors / master workers model. In redis’s multi-threaded scheme, I / O threads only read and parse client request commands through sockets, but do not really execute commands.
Finally, all client commands need to return to the main thread for execution, so the utilization of multi-core is not high. Moreover, each time the main thread must be busy polling after allocating tasks, and wait for all I / O threads to complete tasks before continuing to execute other logic.
In my opinion, redis’s current multithreading scheme is more like a compromise choice: it not only maintains the compatibility of the original system, but also uses multi-core to improve I / O performance.