Understanding Redis: Why It Is So Fast and How Its Single‑Threaded Architecture Works

Almost every Java interview includes caching questions, ranging from basic concepts like the Pareto principle and hot vs. cold data to advanced topics such as cache avalanche, penetration, warm‑up, update, and degradation; the most commonly used cache servers are Redis and Memcached, and the author primarily works with Redis.

If you have never been asked why Redis is single‑threaded or why it is so fast, this article is a fortunate read, and interviewers can also use these questions to test candidates.

First, we will explore what Redis is, why it is fast, and why it adopts a single‑threaded model.

Redis is an open‑source, in‑memory data‑structure store that can serve as a database, cache, and message broker. It supports various data structures such as Strings, Hashes, Lists, Sets, Sorted Sets (ZSets), Bitmaps, HyperLogLogs, and Geospatial indexes, with the five most common types being String, List, Set, Hash, and ZSet.

Redis includes built‑in replication, Lua scripting, LRU eviction, transactions, and multiple persistence levels, and provides high availability through Sentinel and Cluster.

Persistence can be configured to periodically snapshot data to disk (RDB) or append every write command to an AOF file; persistence can also be disabled to use Redis purely as a high‑performance cache.

Redis does not use tables and imposes no predefined schema on stored data.

Unlike disk‑based databases, Redis keeps all data in memory, eliminating disk I/O bottlenecks and delivering extremely low latency.

Redis achieves impressive performance: it is a single‑process, single‑threaded KV database written in C, capable of exceeding 100,000 QPS according to official benchmarks (see https://redis.io/topics/benchmarks).

The chart shows connection count on the horizontal axis and QPS on the vertical axis, illustrating the order‑of‑magnitude performance that interviewees should be able to describe accurately.

Reasons for Redis’s speed include: (1) pure in‑memory operations with O(1) access like a HashMap; (2) simple, purpose‑built data structures; (3) a single‑threaded model that avoids context switches, lock contention, and deadlock overhead; (4) non‑blocking multi‑I/O multiplexing; (5) a custom VM that reduces system‑call overhead.

Multi‑I/O multiplexing leverages select, poll, or epoll to monitor many sockets; the thread blocks when idle and wakes only when events occur, processing ready streams sequentially and thus avoiding unnecessary work.

In this context, “multi‑way” refers to multiple network connections, while “multiplexing” means reusing the same thread for all of them.

Redis is single‑threaded because its bottleneck is typically memory size or network bandwidth rather than CPU; a single thread is simpler to implement and avoids the complexities of multithreading.

The ps -T command shows Redis threads, indicating that while request handling uses one thread, other operations such as persistence may run in child processes or threads.

Warning: Starting with Redis 4.0, some operations can use multithreading, so future versions may not be strictly single‑threaded.

Additional models worth knowing include: (1) single‑process multi‑threaded systems like MySQL, Memcached, Oracle (Windows); (2) multi‑process systems like Oracle (Linux); (3) Nginx’s master‑worker architecture, with both single‑process and multi‑process startup modes.

(End)

PS: If you found this sharing useful, feel free to like and share.