Why Redis 6.0 Introduced Multithreading and How to Enable It

Redis officially released version 6.0 in May 2020, bringing many exciting new features such as multithreaded network I/O, client‑side caching, fine‑grained ACL, RESP3 protocol support, and faster RDB loading.

Main Features

Multithreaded network I/O handling

Client caching

Fine‑grained ACL

RESP3 protocol

Immediate deletion of obsolete RDB files

Faster RDB loading

The most discussed feature is the multithreaded model combined with client caching . Understanding its principles helps decide when to adopt Redis 6.0 and avoid pitfalls.

Why Redis Was Single‑Threaded Before 6.0

CPU rarely became the bottleneck; performance was limited by memory and network.

With pipelining, Redis can process about 1 million requests per second, so most commands (O(N) or O(log N)) do not saturate the CPU.

A single thread simplifies maintenance and avoids concurrency issues such as nondeterministic execution order, thread‑switch overhead, lock contention, and potential deadlocks.

Redis uses an AE event model and I/O multiplexing, delivering high throughput without needing multiple threads for command execution.

When Multithreading Became Necessary

As hardware improves, network read/write speed can outpace a single thread’s ability to handle socket I/O, making the read/write system calls dominate CPU time.

Improve network I/O performance, e.g., replace the kernel stack with DPDK.

Leverage multiple cores to parallelize network request handling, similar to Memcached ’s approach.

Adding a user‑space network stack requires substantial changes to Redis’s networking code and may introduce new bugs, so Redis opted for a simpler solution: multiple I/O threads for network operations while keeping command execution single‑threaded.

Multithreaded I/O Model

The I/O threads only handle socket reads/writes; all commands are still executed by the main thread.

Cooperation between the main thread and I/O threads follows these steps:

The main thread accepts connections and enqueues sockets into a global queue.

The main thread polls the queue and assigns readable sockets to I/O threads.

The main thread blocks until an I/O thread finishes reading from a socket.

The main thread parses the received request and executes the command.

The main thread blocks until the I/O thread writes the response back to the socket.

The main thread clears the global queue and waits for the next client request.

This design splits network read/write work across multiple threads, while command execution remains sequential in the main thread, preserving compatibility and simplicity.

Enabling Multithreading

Multithreading is disabled by default in Redis 6.0. To enable it, edit redis.conf: io-threads-do-reads yes Then specify the number of I/O threads (must be less than the number of CPU cores): io-threads 4 Official recommendations suggest 2–3 threads on a 4‑core machine and about 6 threads on an 8‑core machine; using more than 8 threads usually yields no additional benefit.

Pros, Cons, and Practical Thoughts

The multithreaded network model is not a classic Multi‑Reactor/Master‑Worker architecture; I/O threads only read and parse client requests, never execute commands. Consequently, CPU utilization of multiple cores is limited, and the main thread must wait for all I/O threads to finish before proceeding.

In practice, this approach offers a compromise: it retains Redis’s single‑threaded command semantics while improving network I/O throughput on modern hardware.