Understanding Redis: Is It Truly Single-Threaded?
This article clarifies the common misconception that Redis is purely single‑threaded by detailing its single‑threaded network I/O model, the evolution of multithreading support across versions, the client‑server request flow, and the underlying Reactor patterns that enable efficient concurrency.
1. Is Redis Really Single‑Threaded?
Redis server uses a single‑threaded, single‑process model for handling command requests and network communication, but only the network I/O and command execution modules run on that single thread; other modules such as persistence and clustering may use additional threads.
From version 4.0 Redis introduced multithreaded AOF handling, and from version 6.0 it added I/O multithreading, while the core reactor remains single‑threaded.
Versions before 4.0: truly single‑threaded.
v4.0: multithreaded AOF, core network still single‑threaded.
v6.0: I/O multithreading in the network model.
2. Redis Single‑Threaded Model
Redis consists of modules such as network request, indexing, storage, high‑availability, and data operation. The “single‑threaded” claim refers to the network I/O and key‑value read/write modules; persistence and cluster support modules are multithreaded.
Each client request passes through send‑command, execute‑command, and reply phases; commands are queued and processed one by one, guaranteeing no two commands execute concurrently.
3. Client‑to‑Server Request Process
Establish socket connection.
Client generates read/write events and sends request data.
Server processes the data.
Server returns the result.
Example timing: connection 15 s, data transfer 5 s, processing 0.1 s, reply 5 s → total ≈25.1 s for the first request; subsequent requests wait for the previous one to finish.
4. Simple Understanding of Redis Single‑Threaded Execution
After sockets are established, Redis’s single thread detects which connection has received complete request data, then processes that request and returns the response before moving to the next ready connection; the whole cycle runs in a single thread.
5. Reactor Model
The Reactor model combines I/O multiplexing ( I/O multiplexing ) and non‑blocking I/O. It defines three events (connection, read, write), three roles (Reactor, Acceptor, Handler), and three deployment modes (single‑reactor single‑thread, single‑reactor multi‑thread, multi‑reactor multi‑thread/process).
5.1 Single‑Reactor Single‑Thread
All connection handling, event listening, and business logic run in one thread; suitable for Redis ≤ 6.0.
5.2 Single‑Reactor Multi‑Thread
One Reactor thread handles I/O events, while a worker thread pool processes business logic.
5.3 Multi‑Reactor Multi‑Thread/Process
MainReactor accepts connections and distributes them to SubReactors, each with its own thread pool; handlers then delegate work to a separate worker pool.
References
Why Redis claims high single‑thread performance yet adopts multithreading.
Understanding Redis single‑threading.
Redis network module source analysis.
Comprehensive reveal of Redis multithreaded network model.
Redis communication protocol and event handling.
Redis single‑thread event loop.
Redis event‑driven framework (Geek Time).
Netty Reactor pattern summary.
Java NIO series: Reactor pattern analysis.
Selected Java Interview Questions
A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.