Why Is Redis So Fast? Deep Dive into Its Core Architecture and Performance

Why Is Redis So Fast?

Many people only know that Redis is a key‑value NoSQL in‑memory database with a single thread, but that is not a complete understanding of why it is fast.

This article reviews the fundamental reasons behind Redis' speed, covering data structures, memory‑only design, I/O multiplexing, threading, persistence, replication, Sentinel and Cluster.

How Fast Is It?

According to official data, Redis can reach about 100,000 queries per second (QPS). The benchmark program "How fast is Redis?" is available at https://redis.io/topics/benchmarks.

The chart shows connections on the horizontal axis and QPS on the vertical axis.

This graph reflects an order of magnitude; quoting it in an interview shows that you have read the official documentation and are rigorous.

Memory‑Based Implementation

Redis stores all data in memory, which makes it dramatically faster than disk‑based databases.

Both read and write operations are performed directly in memory. Compared with disk operations, memory access latency is far lower.

Disk access

Memory access

Memory is controlled directly by the CPU via an integrated memory controller, providing the optimal bandwidth between CPU and memory.

Efficient Data Structures

Redis supports five core data types: String, List, Hash, Set, and SortedSet. Each type is backed by one or more specialized data structures designed for speed.

Explaining the underlying data structure of each type can impress interviewers.

SDS – Simple Dynamic String

SDS stores the length of the string in a len field, allowing O(1) length queries. It also pre‑allocates extra space and uses a free field to keep unused bytes for future appends, reducing memory allocations.

ziplist – Compressed List

Used as the underlying implementation for List, Hash and SortedSet when the number of elements is small and each element is a short string or small integer. It stores data compactly to save memory.

quicklist

In newer Redis versions, quicklist replaces ziplist and linked list. It is a hybrid structure where each segment is a ziplist linked together by doubly‑linked pointers.

skiplist – Skip List

SortedSet uses a skiplist to provide ordered access. A skiplist maintains multiple forward pointers per node, enabling fast search comparable to balanced trees.

intset – Integer Set

When a Set contains only a few integer elements, Redis uses an integer set to store them compactly.

Single‑Threaded Model

Redis's "single thread" refers to the fact that command execution for key‑value operations runs in a single thread. Persistence, replication and background tasks run in separate threads.

Because Redis is memory‑bound, the CPU is not the bottleneck; the limiting factors are usually memory size or network bandwidth.

Using a single thread avoids context‑switch overhead, lock contention, and simplifies the code.

I/O Multiplexing Model

Redis uses epoll and a custom event loop to handle many client connections concurrently without blocking on I/O.

This design allows Redis to serve multiple clients simultaneously, improving concurrency.

Global Hash Table

All keys are stored in a single hash table. Each bucket holds a pointer to a redisObject that represents the actual key or value.

typedef struct redisObject{
    unsigned type:4;      // object type
    unsigned encoding:4;  // internal encoding
    void *ptr;             // pointer to the actual data structure
    // ...
} robj;

The hash table provides O(1) lookup time, contributing to Redis' speed.

Hash Collision Resolution

Redis uses chaining to resolve hash collisions: each bucket stores a linked list of entries. To reduce collisions during rehashing, Redis maintains two hash tables and gradually migrates entries from the old to the new table (progressive rehash).

Persistence: RDB and AOF

Redis offers two persistence mechanisms:

RDB – point‑in‑time snapshots saved to disk. Generation of an RDB file can be expensive because it forks a child process (Copy‑On‑Write) and writes the entire dataset.

AOF – an append‑only log that records every write command. It can be configured with appendfsync policies always, everysec, or no to balance durability and performance.

Redis 4.0 introduced hybrid persistence, combining an RDB snapshot with the incremental AOF generated during the snapshot period, achieving fast restarts with minimal data loss.

Master‑Slave Replication

Replication provides redundancy and read‑write separation. The master processes writes and streams them to slaves. Replication can be full (initial RDB transfer) or incremental (using the replication buffer).

During a network outage, Redis 2.8+ uses incremental replication based on the repl_backlog_buffer ring buffer, avoiding a costly full resynchronization.

Sentinel

Sentinel monitors master and slave instances, detects failures, performs automatic failover, and notifies clients of the new master.

Cluster

Redis Cluster provides horizontal scalability by sharding data into 16,384 slots. Each node is responsible for a subset of slots.

Key to slot mapping uses CRC16 and modulo 16384. Nodes exchange slot information via the Gossip protocol.

Redirection

If a client contacts a node that does not own the requested slot, the node returns a MOVED error with the address of the correct node. During slot migration, a ASK error may be returned, indicating the client should temporarily query the target node.

Conclusion

This article covered Redis core concepts: data structures, memory model, I/O model, persistence (RDB and AOF), master‑slave replication, Sentinel, and Cluster. The "面霸" series will continue with deeper dives into high availability, practical deployment, and common pitfalls.

Feel free to like, share, bookmark, or comment, and join the author’s WeChat group for further discussion.