Why Redis Added Multithreading in 6.0: Design Rationale and Trade‑offs

Why Redis Was Originally Designed as Single‑Threaded

Redis is a mature distributed cache framework composed of modules such as network, 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 paths, which run in a single thread; other modules like persistence and clustering are already multithreaded.

Since Redis 4.0, some commands have been partially multithreaded, but the core network and data modules remained single‑threaded because there was no need: Redis operations are memory‑bound, so CPU is not the performance bottleneck.

When Is Multithreading Needed?

Programs perform I/O operations (network and disk) and CPU‑intensive calculations. Multithreading aims to increase the utilization of both I/O and CPU resources.

For Redis, CPU utilization is irrelevant because most work is in‑memory; therefore, using multithreading to boost CPU usage is unnecessary.

Improving I/O utilization is desirable, but multithreading is not the only way. Redis already employs I/O multiplexing (e.g., epoll/select) to handle many connections with a single thread.

Drawbacks of Multithreading

Multithreading introduces concurrency control complexity, thread‑switching overhead, and potential performance penalties, especially in languages that require explicit synchronization mechanisms.

Consequently, Redis prefers a single‑threaded model for maintainability, lower debugging cost, and avoidance of context‑switch overhead, while still achieving high I/O efficiency through multiplexing.

Summary of Reasons Redis Keeps a Single‑Threaded Core

Operations are memory‑bound; CPU is not the bottleneck.

Single‑threaded design improves maintainability and reduces development cost.

Avoids performance loss from thread context switches.

Multiplexed I/O already maximizes I/O utilization.

Note: Redis is not completely single‑threaded; only the critical network I/O and key‑value paths run in one thread.

Redis I/O Multiplexing

I/O multiplexing allows a single thread to monitor multiple I/O streams via a kernel‑managed pipe. When an event is ready, the kernel notifies the thread, which then processes the data.

This mechanism enables one thread to handle many connections.

Linux provides three multiplexing APIs: select, poll, and epoll. Redis wraps the appropriate system call in dedicated source files.

When a socket is ready for accept, write, read, or close, Redis creates a file event; multiple events may occur concurrently.

Thus Redis uses multiplexed I/O to improve I/O utilization without multithreading.

Why Redis 6.0 Introduced Multithreading

Redis 6.0 (released May 2020) added a multithreaded network layer to handle the parsing of network requests in parallel, while the actual data read/write remains single‑threaded.

Although single‑threaded Redis can already achieve 80,000–100,000 QPS for many workloads, some large‑scale scenarios demand higher throughput. The network I/O processing becomes the bottleneck because the multiplexed model is fundamentally synchronous and blocking.

By offloading request parsing to multiple I/O threads, Redis reduces the time the main thread spends waiting on network I/O, leverages multi‑core CPUs, and increases overall QPS.

Only the network request handling is multithreaded; data commands continue to execute in the original single thread, avoiding concurrency issues.