Why Redis Uses a Single Thread Model: File Event Handlers & I/O Multiplexing

Single‑Thread Model Design

Redis adopts a single‑threaded model for its core server loop. Although the server runs in a single thread, it achieves high performance by performing all operations in memory and by using a non‑blocking I/O multiplexing mechanism that avoids frequent context switches.

File Event Handler (FEH)

Redis implements its own file event handler (FEH) based on the Reactor pattern. The FEH monitors multiple sockets simultaneously and dispatches events to the appropriate handler functions.

Socket abstraction

A file event represents an abstract operation on a socket (accept, read, write, close). When a socket becomes ready for one of these operations, a corresponding file event is generated.

I/O Multiplexing Program

The I/O multiplexing program listens to many sockets. When events occur, it places the sockets into a queue and delivers them one by one to the file‑event dispatcher.

Redis wraps the common system calls select, epoll, evport, and kqueue in the source file ae.c. At compile time the highest‑performance library available on the host is selected automatically.

File Event Dispatcher

The dispatcher receives sockets from the I/O multiplexing program, examines the event type, and invokes the corresponding handler function.

Event Handlers

Redis registers different handlers for different socket activities:

Connection‑accept handler – maps a new socket to the accept routine.

Command‑request handler – reads client commands.

Command‑reply handler – writes responses back to the client.

Replication handler – used by master and replica during data sync.

Event Types

Two primary event flags are defined in ae.h: AE_READABLE – generated when a socket can be read or when a new connection is pending. AE_WRITABLE – generated when a socket is ready for writing.

If a socket is both readable and writable, the dispatcher processes the readable event first, ensuring the server reads before it writes.

Summary of the Communication Flow

During Redis startup, the connection‑accept handler is bound to AE_READABLE.

A client connection creates an AE_READABLE event, triggering the accept handler, which also binds the socket to the command‑request handler.

When a client sends a command, an AE_READABLE event fires, invoking the command‑request handler to read and forward the command.

After processing, the server binds AE_WRITABLE to the command‑reply handler; the client’s read readiness generates the writable event, causing the reply to be written.

Once the reply is fully written, the AE_WRITABLE mapping is removed.