Why Redis Uses a Single Thread and How Multithreading Boosts Performance

1. Redis Single Thread

Usually Redis is said to be single‑threaded, meaning its network I/O and key‑value read/write are handled by one thread; other functions such as persistence, asynchronous deletion, and cluster synchronization run in additional threads, so Redis is not strictly single‑threaded.

Multithreaded development inevitably brings concurrency control and resource overhead; without good design it can be counterproductive, so Redis adopts a single‑threaded model to avoid these issues.

The single‑threaded model can achieve hundreds of thousands of operations per second because most operations are in‑memory using efficient data structures (hash tables, skip lists) and because it uses I/O multiplexing to handle many client connections concurrently, achieving high throughput.

Before understanding multiplexing, one must know the basic I/O model and potential blocking points. If the single thread blocks, multiplexing cannot work. In a GET request, bind/listen, accept, recv, parse, and send are network I/O; get is the key‑value operation.

In the network I/O, the blocking points are accept() and recv(). When Redis listens for a client connection but cannot establish it, it blocks at accept(), preventing other clients from connecting. Similarly, if recv() waits for data that never arrives, the thread blocks, halting all processing. Using non‑blocking sockets enables Linux’s I/O multiplexing mechanism.

2. I/O Multiplexing Mechanism

Linux I/O multiplexing (select/epoll) allows one thread to handle multiple I/O streams. In Redis’s single‑threaded mode, the kernel can monitor many listening and connected sockets simultaneously; when a request arrives, the kernel notifies the Redis thread, achieving one‑thread‑multiple‑IO handling.

Redis’s network framework uses epoll to watch multiple file descriptors, so the thread does not block on any particular socket and can serve many clients concurrently, improving concurrency.

Select/epoll provides an event‑driven callback mechanism: when an event occurs on a file descriptor, it is placed in an event queue, which the Redis thread continuously processes. This avoids constant polling, saves CPU resources, and enables timely response to client requests.

3. Redis 6.0 Multithreaded Feature

Before Redis 6.0, only some commands (e.g., background deletion, snapshot, AOF rewrite) used background threads; network I/O and command execution were handled by a single thread, becoming a performance bottleneck. Starting with Redis 6.0, multiple I/O threads handle network requests, increasing parallelism, while command execution remains single‑threaded.

Typical workflow:

The main thread accepts a client connection, creates the socket, and places it in a global queue for I/O threads.

The main thread blocks waiting for I/O threads to read and parse the request; multiple I/O threads work in parallel.

After parsing, the main thread executes the command in single‑threaded mode.

When the command finishes, the main thread writes the result to the buffer and waits for I/O threads to write the response back to the socket.

I/O threads also write responses concurrently, so the write speed is fast. After the I/O thread finishes, the main thread clears the global queue and waits for the next client request.

4. Configuring I/O Threads

If CPU usage is low but throughput does not improve, enable the I/O thread mechanism in redis.conf: io-threads-do-reads yes Set the number of I/O threads to less than the number of CPU cores, e.g., for an 8‑core machine, Redis recommends 6 I/O threads:

io-threads 6