Why Redis Is So Fast: Single‑Threaded Design, Multi‑Threaded I/O, and Performance Characteristics

Official benchmark results show that a single Redis instance running on an average Linux machine can handle simple O(N) or O(log N) commands at more than 800 k QPS, and with pipelining the throughput can reach 1 M QPS.

From a performance standpoint, Redis is regarded as a high‑performance caching solution.

Typical interview answers for why Redis is fast include: it is written in C, operates entirely in memory, uses I/O multiplexing technologies such as epoll / select / kqueue , follows a single‑threaded event‑loop model that avoids costly context switches and lock contention, and embraces a simple, maintainable codebase created by its author Antirez.

CPU is rarely the bottleneck for Redis; memory or network I/O usually dominate. Using pipelining, Redis on an average Linux system can process up to one million requests per second for O(N) or O(log N) commands, consuming very little CPU.

The traditional single‑threaded network model (reactor) processes all client events in one loop. Key functions include acceptTcpHandler (accepts new connections), readQueryFromClient (reads client commands into querybuf ), processInputBuffer (parses commands via processInlineBuffer or processMultibulkBuffer ), processCommand (executes the command), and reply handling functions such as addReply , beforeSleep , handleClientsWithPendingWrites , and writeToClient . The client structure contains fields like -- *conn , --*db , --querybuf , --buf , and --reply .

Since Redis 4.0, asynchronous commands (e.g., UNLINK , FLUSHALL ASYNC , FLUSHDB ASYNC ) run in background threads, preventing the main event loop from blocking. Redis 6.0 introduced true I/O multithreading, where read and write operations are offloaded to I/O threads while command execution remains on the main thread.

The multithreaded design evolves into a multi‑reactor (master‑workers) model: a main reactor accepts connections and distributes them to sub‑reactors (I/O threads). Each sub‑reactor maintains its own event loop, similar to architectures used by Nginx and Memcached.

In summary, Redis balances the simplicity of a single‑threaded event loop with optional multithreaded I/O to achieve high throughput and low latency, and understanding these mechanisms is essential for leveraging Redis as a high‑performance data store and cache.