How Redis Executes Commands: Deep Dive into Its Architecture and Event Loop

Redis (Remote Dictionary Server) is an open‑source in‑memory key‑value store widely used for caching, message queues, session storage and more. This article explains how a Redis command is processed from client request to response.

Redis is an open‑source in‑memory database providing high‑performance key‑value storage, commonly used in caching, message queues, and session storage. Although many use simple GET/SET commands, the internal execution process is often overlooked; this article clarifies it.

Redis Deployment Architectures (Macro View)

Standalone mode : single node, no high‑availability, suitable for development or non‑critical scenarios.

Master‑Slave replication : data replicated from master to slaves, enabling read/write separation and redundancy.

Sentinel mode : adds monitoring nodes for automatic failover, providing high availability.

Cluster mode : distributed architecture with data sharding across multiple nodes, supporting automatic failover and horizontal scaling.

Redis Core Components (Micro View)

Event‑driven engine : uses I/O multiplexing (epoll/kqueue) in a single‑threaded reactor model to handle concurrent requests efficiently.

Command processing layer : parses client commands, validates them, and executes logic for operations such as GET, SET, HSET, supporting various data structures.

Memory management system : handles allocation and reclamation, offering eviction policies like LRU, LFU, etc.

Persistence module : RDB snapshots and AOF logs ensure data durability.

Monitoring & statistics : provides metrics such as memory usage, QPS, slow‑query analysis for operational tuning.

Key Terminology

Redis client – program or tool (e.g., Jedis, Lettuce, redis‑cli) that communicates with the server via TCP and the RESP protocol.

Event‑driven layer – single‑threaded reactor (multi‑threaded I/O from Redis 6.0) composed of file‑event and time‑event handlers.

Command layer – parses RESP, validates commands, and dispatches to the appropriate implementation.

Memory allocation – uses jemalloc/tcmalloc and eviction strategies (LRU/LFU/random/TTL).

Persistence – RDB snapshots and AOF logs.

Replication – master‑slave mechanism for redundancy and read/write separation.

Sentinel – monitors instances and performs automatic master election on failure.

Cluster – data sharding with hash slots and Gossip protocol for scaling.

Monitoring – exposes stats like used_memory, commandstats, etc.

Event‑Driven Execution Flow

The core data structure aeEventLoop holds file events, time events, and fired events. The loop repeatedly calls aeProcessEvents, which handles readable/writable file events and time events.

typedef struct aeEventLoop {
    int maxfd;                // maximum file descriptor
    aeFileEvent *events;      // registered file events
    aeTimeEvent *timeEventHead; // time event list
    aeFiredEvent *fired;      // fired events
} aeEventLoop;

Three steps compose event handling: registration → multiplexed listening → dispatch.

1. Event registration → 2. Multiplexed listening → 3. Event dispatch

Command Execution Pipeline

Connection establishment :

aeMain → aeProcessEvents → acceptTcpHandler → createClient → connSetReadHandler(..., readQueryFromClient)

Read & parse : readQueryFromClient may delegate to I/O threads (if enabled) or run in the main thread, filling client->argv and locating the command function in redisCommandTable.

Command execution : processPendingCommandsAndResetClient calls processCommand, call, then c->cmd->proc (e.g., setCommand), followed by replication/AOF propagation.

Reply preparation : addReply places the response into clients_pending_write.

Write back : before the next loop, handleClientsWithPendingWritesUsingThreads or the synchronous path writes the reply to the client.

Understanding this event‑driven architecture and the associated code paths clarifies how Redis achieves high performance and scalability.