Understanding Redis’s Reactor Pattern and I/O Multiplexing

After reading the book "Redis Design and Implementation", the author highlights Redis as an open‑source, high‑performance in‑memory cache database with a relatively small codebase (around 60,000 lines) compared to larger systems like MySQL.

The article focuses on the Reactor pattern used inside Redis. It begins by describing Redis's working mode: multiple clients connect to a single Redis server, sending commands (e.g., GET, SET), and the server processes these requests in a single process and single thread, forking only for background tasks such as RDB persistence or AOF rewriting.

The discussion then introduces the C10K problem—how to handle ten thousand concurrent TCP connections—and explains why a one‑thread‑per‑connection model is impractical. The solution lies in I/O multiplexing, which allows a single thread to monitor many sockets for readable or writable events.

Common I/O multiplexing system calls are presented:

select(int nfds, fd_set *r, fd_set *w, fd_set *e, struct timeval *timeout)

poll(struct pollfd *fds, int nfds, int timeout)

and the associated struct pollfd { int fd; short events; short revents; }. The article also outlines the limitations of select and how poll improves on them, then introduces stateful mechanisms like epoll_create(int size),

epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

,

epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)

on Linux, and kqueue(void),

kevent(int kq, const struct kevent *changelist, int nchanges, struct kevent *eventlist, int nevents, const struct timespec *timeout)

on BSD.

The Reactor pattern is then defined with its core components: Handles (file descriptors), Synchronous Event Demultiplexer (waits for events), Initiation Dispatcher (registers and dispatches handlers), Event Handler interface, and Concrete Event Handler (actual implementation). The six-step event‑handling flow is described, from registering handlers to invoking handle_event when events occur.

A brief note on Java mentions Doug Lea’s "Scalable I/O in Java", the Java NIO API, and the Netty framework, which abstracts many low‑level details of the Reactor pattern.

Finally, the article maps the Reactor model back to Redis. Redis distinguishes file events (client socket operations) and time events (periodic tasks). The file‑event handling loop is illustrated with snippets from Redis.c showing

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

, where aeMain() runs the event loop that processes file events sequentially.

The article concludes that understanding Redis’s architecture, the C10K problem, I/O multiplexing, and the Reactor pattern provides a clear picture of how Redis achieves high concurrency with a simple, single‑threaded design.