Why Redis Added Multithreading in 6.0: Myths, Benefits, and Design Choices

Background

Redis is a widely used in‑memory database that historically handled network I/O and key‑value reads/writes with a single thread. Version 6.0 introduced a multithreaded model, prompting many questions about the reasons, differences from earlier releases, and the impact on performance.

1. Why Redis Was Initially Designed as Single‑Threaded

Redis consists of several modules such as network I/O, indexing, storage, high‑availability clustering, and data operations. The statement that “Redis is single‑threaded” actually refers only to the network I/O and key‑value read/write modules; other modules (e.g., persistence, cluster support) already use multiple threads.

Since most operations are memory‑bound, CPU is rarely the bottleneck, so a single thread for the critical path simplifies development, debugging, and maintenance while avoiding context‑switch overhead.

2. When Multithreading Is Useful

Multithreading helps when a program performs both I/O‑bound and CPU‑bound work. By running I/O operations concurrently, it can increase the utilization of both I/O devices and CPU cores.

Redis, however, does not need extra CPU for its memory‑centric workload, so multithreading for CPU utilization offers no benefit.

3. Drawbacks of Multithreading

Introducing threads brings concurrency control challenges (locks, CAS, memory models) and adds overhead from thread scheduling and context switches. These complexities can outweigh the gains for a system whose primary bottleneck is not CPU.

4. Summary of Reasons Redis Keeps a Single‑Threaded Core

Operations are memory‑bound; CPU is not the performance limiter.

Single‑threaded design improves maintainability and reduces development cost.

Avoids performance penalties from thread context switches.

I/O multiplexing already boosts I/O utilization without threads.

Thus, Redis is not completely single‑threaded, but its critical network I/O and data path remain single‑threaded.

5. Redis’s I/O Multiplexing

I/O multiplexing allows one thread to monitor many sockets and handle events when they become ready. Linux provides three main mechanisms: select, poll, and epoll. Redis wraps these system calls in separate source files.

When a socket is ready for accept, read, write, or close, Redis creates a file event. Multiple sockets can generate concurrent events, which the single thread processes using the multiplexing API.

Illustration of the multiplexing concept:

When a request arrives, Redis assigns it to the thread handling I/O, achieving one‑thread‑multiple‑I/O‑stream processing.

6. Why Redis 6.0 Introduced Multithreading

Redis 6.0, released in May 2020, added multithreading only for the network request processing stage; the actual data read/write commands remain single‑threaded.

Typical workloads achieve 80 000–100 000 QPS with a single thread, which suffices for most companies. However, ultra‑high‑traffic scenarios (hundreds of millions of operations) expose the network I/O path as the main bottleneck. Although multiplexing improves I/O utilization, the underlying select / poll / epoll calls are still blocking, limiting scalability under massive concurrency.

By delegating network request parsing to a pool of I/O threads, Redis can parallelize the blocking part of the network stack, reduce wait time, and better exploit multi‑core CPUs while keeping the data path single‑threaded to avoid concurrency bugs.

Therefore, Redis 6.0 uses multiple I/O threads for network handling, then hands the parsed request to the main thread for memory operations, preserving correctness and avoiding thread‑safety issues.

References

https://www.cnblogs.com/Zzbj/p/13531622.html

https://xie.infoq.cn/article/b3816e9fe3ac77684b4f29348

https://jishuin.proginn.com/p/763bfbd2a1c2

《极客时间：Redis核心技术与实战》