One of the most common questions about Redis is: "Redis is single-threaded, so how can it handle thousands of concurrent connections?". But the more interesting question is: “Why would we need thousands of threads to handle thousands of connections in the first place?”
The answer lies in understanding the difference between doing work and waiting for work. A connection spends most of its lifetime waiting for data to arrive from the network. Waiting is not computation. If a server creates one thread for every connection, many of those threads spend most of their time blocked on I/O operations. Although blocked threads consume little CPU time, they still require memory for their stacks and introduce scheduling overhead.
Redis avoids this problem by using an event-driven architecture built on I/O multiplexing. Instead of dedicating one thread to each connection, a single thread asks the operating system: “Which connections are actually ready for work right now?”. The thread then processes only those connections.
Blocking I/O - The traditional model
The simplest server implementation uses blocking I/O:
while (1) {
int fd = accept(server_fd, ...); // wait for new connection
handle_client(fd); // read, process, reply
close(fd); // only then accept the next client
}
This design has an obvious limitation. While handle_client() is waiting for a client to send data, the entire server is blocked. No other connections can be accepted or processed. A traditional solution is to create one thread per connection:
while (1) {
int fd = accept(server_fd, ...);
pthread_create(&tid, NULL, handle_client, (void*)fd);
}
This model can work well at small scales. However, with thousands of concurrent connections, the overhead becomes significant. On many Linux systems, each thread reserves several megabytes of stack space by default. In addition, the OS must continually schedule and switch between threads, causing context-switch overhead.
Non-blocking I/O
Instead of allowing read() to block until data becomes available, a file descriptor can be configured non-blocking mode:
fcntl(fd, F_SETFL, O_NONBLOCK);
ssize_t n = read(fd, buf, sizeof(buf));
if (n == -1 && errno == EAGAIN) {
// No data available yet
}
The problem now becomes determining when to try again. Continuously checking every connection would waste CPU resources. This approach, known as busy waiting, keeps the CPU fully occupied even when no useful work is being performed. What is needed is a mechanism that allows the operating system to notify the application only when a file descriptor becomes ready.
I/O multiplexing
I/O multiplexing enables a single thread to monitor many file descriptors simultaneously.
select(): The first generation
fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(fd1, &read_fds);
FD_SET(fd2, &read_fds);
FD_SET(fd3, &read_fds);
// Block until at least one fd is ready
select(max_fd + 1, &read_fds, NULL, NULL, NULL);
// Then scan everything to find which ones are ready
for (int i = 0; i <= max_fd; i++) {
if (FD_ISSET(i, &read_fds)) {
read(i, buf, ...);
}
}
select() has two major limitations
- It is typically limited to FD_SETSIZE file descriptors (often 1024).
- Each invocation requires scanning the entire set of descriptors, resulting in O(n) complexity.
pool() removes the fixed descriptor limit, but it still requires scanning all registered descriptors after each call.
epoll (in Linux) or kqueue (on maxos/bsd with an equivalent design) solves both problems by inverting the design: instead of handing the kernel a list to check on every call, you register once, and the kernel only notifies you about fds that actually have events.
int epfd = epoll_create1(0);
struct epoll_event ev;
ev.events = EPOLLIN;
ev.data.fd = client_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);
struct epoll_event events[MAX_EVENTS];
while (1) {
int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
for (int i = 0; i < n; i++) {
handle(events[i].data.fd);
}
}
The key advantage is that epoll_wait() returns only the file descriptors that are ready. If 10,000 connections are registered but only three receive data, Redis processes only those three connections instead of scanning all 10,000.
The ae event library
Redis does not use libraries such as libevent or libuv. Instead, Redis implements its own lightweight event library called ae (A simple Event Library, https://github.com/redis/redis/blob/unstable/src/ae.c). The central data structure is aeEventLoop:
typedef struct aeEventLoop {
int maxfd;
int setsize;
aeFileEvent *events;
aeFiredEvent *fired;
aeTimeEvent *timeEventHead;
aeApiState *apidata;
} aeEventLoop;
Conceptually, the event loop consists of three parts:
aeEventLoop
├── File events
│ ├── acceptTcpHandler
│ ├── readQueryFromClient
│ └── sendReplyToClient
│
├── Time events
│ └── serverCron
│
└── Backend API
└── epoll / kqueue / select
File events handle socket activity. Time events execute periodic tasks that Redis must perform regardless of network activity. The backend API abstracts platform-specific multiplexing mechanisms.
The main event loop
Redis spends most of its lifetime executing the following loop:
void aeMain(aeEventLoop *eventLoop) {
eventLoop->stop = 0;
while (!eventLoop->stop) {
aeProcessEvents(eventLoop,
AE_ALL_EVENTS |
AE_CALL_BEFORE_SLEEP |
AE_CALL_AFTER_SLEEP);
}
}
Conceptually, each iteration follows this sequence:
aeMain()
↓
aeProcessEvents()
↓
epoll_wait() / kqueue()
↓
Process file events
↓
Process time events
↓
Repeat forever
This design allows Redis to react efficiently to both incoming network requests and scheduled maintenance tasks.
File events and time events
Redis supports two categories of events.
File events
File events are triggered by socket activity. Examples include: acceptTcpHandler, readQueryFromClient, sendReplyToClient. These handlers manage client connections and network communication.
Time events
Time events execute periodically. The most important example is serverCron(). By default, Redis executes serverCron() approximately every 100 milliseconds (determined by the hz configuration parameter). serverCron() performs tasks such as:
- Running the active expiration cycle
- Collecting statistics
- Managing client timeouts
- Maintaining replication state,
- Performing persistence-related housekeeping,
- Executing cluster maintenance tasks.
Without time events, Redis would respond only to network activity and could not perform background maintenance.
Full lifecycle of a request inside ae event loop
To make it concrete, trace a SET key value from start to finish:
- Step 1 (server start): During initialization, Redis registers the listening socket: server socket → acceptTcpHandler. Whenever a new connection arrives, the event loop invokes acceptTcpHandler().
- Step 2 (client connects): When epoll_wait() reports that the server socket is ready: accept() → new client fd → aeCreateFileEvent(..., readQueryFromClient). Redis registers a readable file event for the client socket.
- Step 3 (receive the command): The client sends 3\r\n$3\r\nSET\r\n.... The event loop detects that the client socket is readable and invokes: readQueryFromClient(). The command is copied into: client→querybuf.
- Step 4 (parse and execute): Redis parses the RESP protocol, identifies the SET command, locates the appropriate command implementation, and executes it. The reply is generated in memory and appended to the client's output buffer. No I/O happens at this step, it is purely a memory operation.
- Step 5 (send the reply): In the same loop iteration (after processing all read events), Redis calls the write handler to write() the reply buffer to the socket. If the reply buffer is large and cannot be flushed in one call, Redis registers a write event handler to continue flushing on the next iteration.
Why Single-Threaded Execution Works Well
A common misconception is that more threads always improve performance. Additional threads are beneficial primarily when the workload is limited by available CPU resources. Many Redis operations, such as GET and SET, perform relatively little computation: lookup key → retrieve value from memory → generate response. For these workloads, using multiple execution threads can increase overhead due to:
- synchronization mechanisms protecting shared data,
- context switching performed by the operating system,
- cache coherence traffic between CPU cores.
By executing commands in a single thread, Redis avoids these costs entirely. This design simplifies the implementation and enables very high throughput for typical in-memory workloads.
The limits of this model
Single-threading has one clear weakness: one blocking command blocks the entire server.
KEYS * on a database with 10 million keys → O(n) scan → every other client waits for the entire duration. This is why KEYS is banned in production and replaced by SCAN (cursor-based, scanning a small portion per call).
Similarly: LRANGE mylist 0 -1 on a list with a million elements, SORT without LIMIT, SMEMBERS on a huge set — all commands that can stall the event loop.
Redis 6.0 partially addressed this with threaded I/O: still single-threaded for command execution, but uses multiple threads for reading and writing sockets. The reason: at high connection rates, read() and write() syscalls start consuming a meaningful share of time relative to command execution. Threaded I/O lets Redis exploit multiple cores without breaking the data model.
Redis 7.0 goes further with Redis Cluster sharding, distributing both data and load across multiple processes — each process still single-threaded — scaling out rather than up.
