Redis officially launched version 6.0 in May 2020, offering a lot of exciting new features, so it’s getting a lot of attention.

What features does the code provide? Can I get a raise if I know?

The main features are as follows:

  1. Multithreading Network IO;
  2. Client-side cache;
  3. Fine-grained Access Control (ACL);
  4. RESP3Use of the protocol;
  5. The RDB file used for copying is no longer useful and will be deleted immediately.
  6. RDB files load faster;

One of the most concerned is the “multi-threading model + client caching”, we only master the principle of the new features, in order to judge when to use the 6.0 version, how to use better and faster, do not step into the pit.

This article starts with the Redis multithreading model, and the client cache, etc., will be broken down next time.

Finally, click on the card in the bottom to pay attention to the bytecode that gets you a raise.

Why not use multithreading before Redis 6.0?

Official reply:

  • There is almost no CPU bottleneck when using Redis, and Redis is mostly limited by memory and network.
  • On a normal Linux system, Redis uses thepipeliningIt can handle a million requests per second, so if the application is primarily using O(N) or O(log(N)) commands, it won’t take much CPU.
  • With single thread, maintainability is high. Although the multi-threading model performs well in some aspects, it introduces the uncertainty of program execution sequence, brings a series of problems of concurrent reading and writing, increases the system complexity, and may have performance loss caused by thread switching, even locking, unlocking and deadlock.

Redis uses AE event model and IO multiplexing and other technologies to achieve very high processing performance, so there is no need to use multithreading.

The single-threaded mechanism greatly reduces the complexity of Redis internal implementation. The lazy Rehash of Hash, Lpush and other “thread-unsafe” commands can be carried out without locks.

In Redis Why So Soon? Code elder brother has detailed introduction fast principle.

Redis has only one thread to work with.

No, when Redis processes client requests, including fetch (socket read), parsing, execution, content return (socket write), etc., it is processed by a sequential main thread, which is called “single thread”.

In the command execution stage, since Redis is single-threaded to process the commands, all the commands arriving at the server will not be executed immediately. All the commands will enter a Socket queue. When the Socket is readable, the single-threaded event dispatcher will execute them one by one.

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

Why did Redis 6.0 introduce multithreading?

As hardware performance increases, Redis’s performance bottleneck may be network IO reads and writes, that is, a single thread can’t handle network reads and writes as fast as the underlying network hardware.

The read/write system calls on the read/write network occupy most of the CPU time during the execution of Redis. The bottleneck is mainly due to the IO consumption of the network. There are two main directions for optimization:

  • Improve network IO performance, typical implementation such as usingDPDK To replace the kernel network stack.
  • The use of multi-threading to make full use of multi-core, improve the parallelism of network request read and write, typical implementation such asMemcached.

Adding support for the user-mode network protocol stack would require modifying the network-specific parts of the Redis source code (such as modifying all the network send and receive request functions), which would be a lot of development work.

Moreover, the new code may introduce new bugs and make the system unstable.

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

Note that the Redis multi-IO thread model is only used to handle network read and write requests. For Redis read and write commands, it is still single-threaded.

This is because network processing is often a bottleneck and performance can be improved by parallel processing with multiple threads.

Continuing to use a single thread to execute read and write commands does not require the development of multithread safety mechanisms to guarantee Lua scripts, transactions, and so on.

The architecture diagram is as follows:

How does the main thread and IO multithreading work together?

The diagram below:

Main process:

  1. The main thread is responsible for receiving the request to establish a connectionsocketPlace in the global wait read queue;
  2. The main thread will be readable by pollingsocketAssign to IO threads;
  3. The main thread blocks waiting for the IO thread to readsocketComplete;
  4. The main thread executes the Redis request commands read and parsed by the IO thread.
  5. The main thread blocks waiting for the IO thread to write back the result of the instruction executionsocketTo complete;
  6. The main thread empties the global queue and waits for further requests from the client.

The main IO read-write task is split into a group of independent threads, so that multiple socket read-write tasks can be parallelized, but the main thread is still executed serially.

How do you 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 the redis.conf configuration file: IO -threads-do-reads yes.

Code old wet, the number of threads is not the more the better?

Of course not. As for the number of threads, it is recommended to set it to 2 or 3 threads for a 4-core machine, and 6 threads for an 8-core machine. The number of threads must be smaller than the number of cores.

Bigger is not always better, and officials consider more than eight to be meaningless.

In addition, after enabling multithreading, you also need to set the number of threads, otherwise it will not be effective.

io-threads 4

Summary and Thinking

With the rapid development of the Internet, the Internet business system has to deal with more and more online traffic. The single thread mode of Redis will cause the system to consume a lot of CPU time on the network I/O, thus reducing the throughput. There are two directions to improve the performance of Redis:

  • Optimize the network I/O module
  • Improve the speed of machine memory reading and writing

The latter depends on the development of hardware and has no solution for the time being. Therefore, we can only start from 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 defects

In fact, the multi-threaded network model of Redis is not a standard multi-reactor/master-workers model. In the multi-threaded scheme of Redis, the I/O thread task only reads the client request command through socket and resoles it, but does not execute the command.

All client commands also need to be executed back to the main thread, so the utilization of multiple cores is not high, and each time the main thread has to poll for all I/O threads to complete the task before proceeding with other logic.

In my opinion, Redis’ current multithreading solution is more of a compromise: keeping the compatibility of the original system, while improving I/O performance with multiple cores.