Why Redis 6.0 Introduced Threaded I/O and How to Enable It

Background

Redis 6.0 added many new features, most notably Threaded I/O and Client side caching . The table of new features (ACL, expiration optimization, module API, SSL/TLS, etc.) illustrates the breadth of improvements.

6.0 Before: Single‑Threaded Model

In the original Redis design, network I/O and key‑value command processing are performed by a single thread, while auxiliary tasks such as persistence, asynchronous deletion, and cluster synchronization run in separate background threads. This design avoids context switches and resource contention, keeping the core engine simple and fast.

Redis’s documentation explains why a single thread was sufficient: the workload is usually limited by memory and network bandwidth, not CPU; pipelining can handle millions of requests per second; and the AE event loop with I/O multiplexing already provides high throughput.

6.0 After: Why Multithreading?

Modern network hardware delivers far higher bandwidth, making network I/O the new bottleneck. A single thread cannot keep up with the read/write speed of the NIC, especially at tens of thousands of QPS. Two main approaches exist: replace the kernel network stack (e.g., DPDK) or add multithreading. Redis chose the latter because it is simpler and leverages existing multi‑core CPUs.

Utilize multiple CPU cores instead of a single core.

Distribute network read/write work across I/O threads, reducing latency.

The post‑6.0 execution flow separates I/O handling from command execution. The main thread accepts connections and queues socket data, I/O threads read and parse the data, then the main thread processes commands and finally the I/O threads write responses back.

Main thread establishes connections and queues socket data.

Socket data is dispatched to I/O threads.

Main thread blocks until I/O threads finish reading and parsing.

I/O threads return parsed commands; main thread executes them.

After execution, the main thread waits for I/O threads to write responses.

Main thread clears completed queues and waits for new requests.

Enabling Multithreading

Multithreading is disabled by default in Redis 6.0. To enable it, edit redis.conf:

# io-threads-do-reads no
io-threads-do-reads yes

After enabling, set the number of I/O threads (must be less than the CPU core count). The official recommendation is 2‑3 threads on a 4‑core machine, 5‑6 on an 8‑core machine; more than 8 threads rarely yields additional benefit.

# assume an 8‑core CPU, configure 5~6 threads
io-threads 5

Summary

Before 6.0, Redis used a single thread for network I/O and command execution, while auxiliary tasks ran in separate threads.

Increasing traffic and faster NICs made network I/O the performance bottleneck, prompting the move to multithreaded I/O.

Multithreading lets Redis fully exploit multi‑core CPUs and reduces read/write latency.

When configuring Threaded I/O, the thread count must stay below the number of CPU cores for optimal efficiency.