Why Can Redis Sustain Over 100k QPS? A Deep Technical Dive

QPS Benchmarks

Official benchmark on a laptop shows:

GET : 103,504 QPS

SET : 100,894 QPS

INCR : 99,662 QPS

Enabling pipeline raises INCR throughput to 1,061,301 QPS, crossing the million‑QPS threshold.

1. Memory Is King

All Redis data resides in RAM. A memory access costs ~0.1 µs, while a random disk I/O costs ~10 ms – a 100,000× speed gap.

Example comparison : Retrieving a user ID from 10 million records.

MySQL with indexes requires 2–3 disk I/Os (20–30 ms).

Redis hashes the key directly in memory, taking ~0.1 ms.

2. Extreme Data Structures

Redis provides five core structures—string, hash, list, set, sorted set—each tuned for specific workloads.

2.1 Simple Dynamic String (SDS)

Traditional C strings need O(N) to obtain length and risk buffer overflow. SDS stores the length and free space explicitly, enabling O(1) length access and automatic expansion.

struct sdshdr { int len; int free; char buf[]; };

O(1) length : read len directly.

Overflow protection : checks free before modification.

Space pre‑allocation : allocates extra free space to reduce reallocations.

2.2 Ziplist

For small hashes or lists (elements < 512 and value < 64 bytes), Redis stores data in a contiguous memory block called a ziplist, eliminating pointer overhead and improving cache locality.

Pros : compact memory layout, fast access.

Condition : automatically used when element count < 512 and value length < 64 bytes.

2.3 Skip List

Sorted sets (ZSET) use a skip list—a multi‑level linked list with O(log N) search time, simpler to implement than balanced trees.

2.4 Incremental Rehash

When a hash table expands, Redis migrates entries gradually instead of moving all keys at once, spreading the cost across subsequent operations and avoiding service pauses.

3. Single‑Threaded Event Loop + I/O Multiplexing

Redis processes network requests with a single core thread.

CPU is not the bottleneck : memory operations are extremely fast, leaving little idle CPU time.

No lock contention : single thread eliminates synchronization overhead.

I/O multiplexing : the thread uses epoll to monitor thousands of connections and handles events only when they occur.

4. Multi‑Core Utilization via I/O Multithreading (Redis 6.0+)

Before Redis 6.0, both network read and write were single‑threaded, which could become a bottleneck under heavy traffic. Redis 6.0 introduced I/O multithreading while keeping command execution single‑threaded for atomicity.

I/O read : multiple threads parse client requests in parallel.

Command execution : the main thread runs commands sequentially to guarantee atomicity.

I/O write : multiple threads write responses back to clients concurrently.

5. Additional Performance Boosters

5.1 Pipeline Batch Operations

Jedis jedis = new Jedis("localhost");
Pipeline p = jedis.pipelined();
for (int i = 0; i < 1000; i++) {
    p.incr("counter");
}
p.sync();

Avoid large keys : keys larger than 10 KB can block the service; detect them with redis-cli --bigkeys.

Persistence during benchmarks : disabling RDB/AOF removes persistence overhead.

6. Pros, Cons, and Typical Use Cases

Pros : extremely high throughput (>100k QPS), rich data structures, persistence guarantees, high‑availability clustering.

Cons : high RAM cost, single‑threaded command execution can block under heavy load, single‑node memory capacity limits, risk of large keys.

Suitable scenarios : cache acceleration, real‑time counters, distributed locks, leaderboards / social feeds.

7. Summary

Memory storage : eliminates disk I/O.

Optimized data structures : SDS, ziplist, skip list, incremental rehash, etc.

Single thread + I/O multiplexing : avoids lock contention and handles massive concurrency efficiently.

Multi‑threaded I/O (Redis 6.0+) : boosts network throughput while keeping core command logic single‑threaded.