Understanding Redis Core: Event‑Driven Model, Event Loop and Command Processing

Author : A senior operations engineer responsible for the game‑department Redis service platform.

Overview : The article introduces Redis’s core principles and architecture, focusing on its event‑driven model (Reactor pattern) that powers all Redis functionalities.

1. Redis Event‑Driven Model

Redis operates on an event‑driven model where the program only acts when specific events occur. This model is equivalent to the Reactor pattern, providing passive response and modular decoupling.

2. Event Loop Implementation

Redis creates an event loop during startup (in server.c) and registers readable events for incoming client connections. The main loop is implemented in aeMain():

void aeMain(aeEventLoop *eventLoop) {
    while (!eventLoop->stop) {
        aeProcessEvents(eventLoop, AE_ALL_EVENTS);
    }
}

The loop monitors two lists: events (registered) and fired (ready). It uses IO multiplexing (select/epoll/kqueue) to wait for events, then dispatches them to their handlers.

3. Event Handlers

Each event is associated with a handler function, e.g.: acceptTcpHandler() – handles new client connections. readQueryFromClient() – reads and parses client commands. sendReplyToClient() – writes replies back to the client.

These handlers are defined in networking.c and are invoked when the corresponding file event becomes ready.

4. Processing Events

The function aeProcessEvents() performs three steps:

Call the OS multiplexing API to obtain ready events.

Iterate over the ready events and invoke their read/write handlers.

Process any pending time events (e.g., periodic tasks governed by the hz parameter).

numevents = aeApiPoll(eventLoop, tvp);
for (j = 0; j < numevents; j++) {
    aeFileEvent *fe = &eventLoop->events[eventLoop->fired[j].fd];
    fe->rfileProc(); // read handler
    fe->wfileProc(); // write handler
}
processTimeEvents(eventLoop);

5. Complete Command Flow (example: SET)

When a client connects (e.g., via telnet) Redis registers a readable event for the socket. Upon receiving a SET command, the flow is: readQueryFromClient() parses the RESP request and looks up the setCommand function. setCommand() updates the key/value in the database. addReply() stores the response (+OK) in the client’s output buffer.

The event loop later sends the buffered reply, creating a writable event only if the reply cannot be sent in one go.

set a 1
+OK

6. Additional Notes

The article also mentions time events used for periodic tasks such as key expiration, driven by the hz configuration (default 100 ms). It references the SEDA paper that motivated the Reactor design.

Overall, the Redis event loop cleanly separates event detection from business logic, enabling high‑performance, single‑threaded handling of massive concurrent connections.