Why Redis Keeps Core Commands Single‑Threaded and How Redis 6 Adds Multi‑Threaded I/O

Redis Development Timeline

Redis has developed quickly; the following are key versions and their main changes:

Thread Model Evolution

Whether Redis is multi‑threaded or single‑threaded depends on its version. Versions up to 5.x, including 5.x, handle core business functions (CRUD commands) in a single thread. With hardware advances and changing application needs, Redis 6.0 introduced multi‑threaded network I/O to better utilize multi‑core processors, improve throughput and response speed, while core command processing remains single‑threaded.

Redis 5.x and Earlier

Assume two clients connect to Redis and issue commands. For example, client A executes SET name longxia and client B executes SET age 10 . If client A’s request arrives first, Redis reads the command’s I/O stream, a worker thread executes the command, and the result is written back to the client. The same single‑threaded flow applies to client B’s request.

Redis 6.0

From Redis 6.0 onward, network I/O read/write is performed by multiple threads, while the worker thread that executes core commands remains single‑threaded. When a client request is received, Redis spawns (or reuses) an I/O sub‑thread; the core command is still handed to the worker thread, which returns the result to the I/O thread for sending back to the client. Subsequent client requests follow the same pattern.

Why Core Commands Remain Single‑Threaded

Redis’s single‑threaded model for core commands means only one worker thread processes CRUD operations. Reasons include:

Most operations are in‑memory and extremely fast; the bottleneck is network latency, so multithreading offers little performance gain while adding context‑switch overhead.

Multithreading introduces shared‑resource concurrency control, requiring locks that can cause deadlocks and performance penalties; a single thread avoids these issues.

The single‑threaded model, combined with asynchronous and non‑blocking I/O, handles high‑concurrency read/write workloads efficiently, often outperforming a multithreaded approach.

Redis may still launch additional processes or threads for non‑core tasks such as persistence; for example, the BGSAVE command forks a child process to create a snapshot.