Understanding Redis Core Network Module and Its High‑Performance Event Loop

1. Introduction

The author shares a personal story about moving from client‑side development to server‑side programming and being asked how to handle thousands of concurrent connections, leading to the motivation for exploring Redis's single‑threaded network design.

2. Understanding I/O Multiplexing (epoll)

Before diving into Redis, the article introduces the concept of I/O multiplexing using epoll. It explains that traditional blocking models waste CPU on context switches, while epoll acts like a shepherd dog that monitors many sockets with a single thread, allowing one process to handle thousands of connections efficiently.

3. Redis Server Startup Initialization

Redis’s entry point is in src/server.c. The main function calls initServer() and then enters the event loop via aeMain(server.el). The initialization performs three key steps:

Create an epoll object.

Bind and listen on the configured port(s).

Register the accept handler for the listening socket.

# git clone https://github.com/redis/redis
# cd redis
# git checkout -b 5.0.0 5.0.0

int main(int argc, char **argv) {
    initServer();
    aeMain(server.el);
}

The initServer function creates the event loop with aeCreateEventLoop, calls listenToPort to bind sockets, and registers the accept callback acceptTcpHandler for each listening fd.

3.1 Creating the epoll Object

aeCreateEventLoop

allocates an aeEventLoop structure and calls aeApiCreate, which ultimately invokes epoll_create(1024) to obtain the kernel epoll descriptor.

3.2 Binding the Listening Port

The function listenToPort loops over configured bind addresses and calls anetTcpServer, which eventually executes the bind and listen system calls.

3.3 Registering the Accept Event

For each listening socket, aeCreateFileEvent registers acceptTcpHandler as the readable callback. This stores the callback in the aeFileEvent array inside the event loop.

4. Redis Event‑Loop Processing (aeMain)

The core loop repeatedly:

Calls beforeSleep to flush any pending write buffers.

Invokes aeProcessEvents, which wraps epoll_wait to discover readable/writable events.

Handles new connections via acceptTcpHandler, creating a redisClient object and registering its read handler readQueryFromClient.

Processes client commands: parsing, command lookup, and execution (e.g., GET via getCommand).

Adds command results to the client’s reply buffer and enqueues the client in server.clients_pending_write.

4.1 Handling Readable Events

readQueryFromClient

reads the request, calls processCommand, which looks up the command in redisCommandTable and invokes the associated handler (e.g., getCommand). The result is placed into the reply buffer via addReplyBulk and addReply.

4.2 Write‑Back Mechanism

Before each epoll_wait, beforeSleep runs handleClientsWithPendingWrites. It iterates over server.clients_pending_write, attempts to write the reply using writeToClient, and if the socket’s send buffer is full, re‑registers a writable event ( sendReplyToClient) so the next epoll_wait will continue sending.

5. Summary

Redis achieves remarkable single‑threaded performance by:

Using epoll for scalable I/O multiplexing.

Keeping the entire request‑response pipeline inside a compact event loop.

Deferring write operations to a pending‑write queue and handling partial writes gracefully.

Understanding initServer and aeMain provides a solid foundation for backend developers interested in high‑performance network programming.