Why Is Single‑Threaded Redis So Fast? Uncover the Secrets

Why Does Redis Use a Single Thread?

Redis’s core service—network I/O and key‑value read/write—is handled by a single thread, which is why it is often called “single‑threaded”. Other features such as persistence, asynchronous deletion, and cluster synchronization run on additional background threads, so Redis is not strictly single‑threaded, but the main request path remains single‑threaded for performance reasons.

Cost of Multithreading

Multithreading can increase throughput, but it introduces contention for shared resources. When multiple threads modify the same data structure, locks or other synchronization mechanisms are required, which add latency and can turn parallel work into serialized execution. For example, if Redis used multiple threads to push (LPUSH) and pop (LPOP) from a list, the operations would need to be serialized to keep the list length correct, negating the benefits of additional threads.

Why Is Single‑Threaded Redis So Fast?

Redis achieves tens of thousands of operations per second with a single thread because most operations are performed entirely in memory using highly optimized data structures such as hash tables and skip lists. In addition, Redis employs a multiplexed I/O model that allows the single thread to handle many client connections concurrently.

Basic I/O Models and Blocking Points

Traditional blocking I/O (BIO) makes a thread wait indefinitely for data, which would stall Redis’s single thread. To avoid this, Redis uses non‑blocking sockets. The key system calls are socket() (creates a descriptor), listen() (creates a listening socket), accept() (accepts a new connection), and recv() (receives data). When a socket is set to non‑blocking mode, the thread can return to other work if no data is available.

Multiplexed I/O Model

Linux’s I/O multiplexing mechanisms (select, epoll, kqueue, evport) let a single thread monitor many file descriptors. Redis registers its listening and connected sockets with epoll; when the kernel detects an event (e.g., a new connection or incoming data), it places the event in an event queue. The Redis thread continuously processes this queue, invoking the appropriate callback functions (e.g., accept for new connections, read for incoming data). This event‑driven loop eliminates the need for the thread to block on any single socket.

For example, an Accept event triggers Redis’s accept handler, while a Read event triggers the get handler. This design is analogous to a hospital triage desk that filters patients before the doctor (the single thread) sees them, allowing the doctor to stay productive.

Summary

We clarified three key questions: Redis is not purely single‑threaded but uses a single thread for the critical request path; it adopts this model to avoid the complexity and overhead of multithreaded concurrency control; and its high performance stems from in‑memory data structures combined with an event‑driven, non‑blocking I/O multiplexing architecture.