Redis Server Startup and Event‑Loop Mechanics: A Detailed Walkthrough

Redis starts when the user runs ./redis-server , which loads the program into memory and calls its main function. The main routine performs three essential steps: creating a TCP listening socket, registering the socket in the event‑loop list, and entering the I/O multiplexing loop.

Step 1 – Listening socket : the function listenToPort() (essentially a socket → bind → listen sequence) creates a TCP socket and returns a file descriptor fd .

Step 2 – Registering the descriptor : aeCreateFileEvent(fd, acceptHandler, ...) adds the descriptor to the aeFileEvent linked list and binds the acceptHandler callback that will be invoked when a client connects.

Step 3 – Event loop : aeMain() repeatedly calls aeProcessEvents(eventLoop, AE_ALL_EVENTS) , which uses select (or another multiplexing API) to monitor all registered descriptors – the classic reactor pattern.

When a client runs redis-cli -h host -p port , the server’s listening descriptor detects the new connection and triggers acceptHandler . This creates a dedicated client object via createClient(cfd) , which again registers the client’s descriptor with aeCreateFileEvent for read events.

The read callback readQueryFromClient parses the incoming command, looks it up in the redisCommand cmdTable[] (a command‑pattern dispatch table), and calls the corresponding implementation such as setCommand .

setCommand stores the key/value pair and finally calls addReply(c, shared.ok) . Rather than writing directly, addReply registers the write callback sendReplyToClient with aeCreateFileEvent , so the reply is sent when the descriptor becomes writable.

The whole process demonstrates why Redis is single‑threaded: all I/O and command handling occur sequentially inside the reactor loop, eliminating the need for locks while still achieving high performance through non‑blocking multiplexed I/O.

In summary, Redis’s startup consists of establishing a listening socket, registering it in a reactor‑style event loop, and then repeatedly accepting connections, reading commands, dispatching them via a command table, and replying—all driven by the same single‑threaded event loop.