Skip to main content

The Redis Threading Model

· 9 min read
tanzhuo

Redis is famous for its performance, and one core reason is its distinctive threading model. Many people have heard that Redis is "single-threaded," but the threading model has actually evolved across versions. Understanding it is essential for understanding both why Redis is fast and how to use it under high concurrency.

The reason this topic deserves its own post is that "Redis is single-threaded" comes up constantly in interviews and everyday discussion, yet most people's understanding stays at the literal level: either they think the entire Redis process has only one thread, or they think command execution went multi-threaded after Redis 6. Both are wrong. And this model directly shapes how we use Redis—which commands you shouldn't run casually, why big keys are dangerous, why pipelines work—all of it traces back to the threading model.

This post covers Redis's single-threaded design, the event-driven model, IO multiplexing, and the multi-threading improvements from Redis 6 onward.

Why Redis Chose a Single Thread​

In early versions (before Redis 6), the core execution model was single-threaded command processing.

That means:

  • All client requests
  • All command execution
  • All data reads and writes

are handled by one main thread.

This design yields a crucially important property: only one command executes at any given moment. Individual Redis commands are therefore naturally atomic—no locks needed, and no possibility of two commands interleaving on the same key. Commands like INCR and SETNX can be used directly as concurrency primitives; that's a byproduct of this model.

But note:

Redis's single-threadedness refers only to command execution—it doesn't mean the whole Redis process has a single thread. For example:

  • RDB persistence
  • AOF rewrite
  • Asynchronous deletion
  • BIO threads

are all background threads.

Take asynchronous deletion: in the main thread, the UNLINK command does just one thing—remove the key from the dictionary. The actual memory reclamation is handed to a background thread to do at its own pace. Even deleting a very large object won't stall the main thread. RDB persistence goes further: it forks a child process to write the snapshot, using the OS's copy-on-write to avoid blocking the main thread.

The core Redis thread is responsible only for:

  • Network IO
  • Command parsing
  • Command execution
  • Returning results

Why a Single Thread Is Still Fast​

A common puzzle: how can a single thread sustain hundreds of thousands of QPS?

Redis's performance comes from a few main sources.

In-memory database: all Redis data lives in memory, avoiding disk IO. Memory and disk speeds aren't even in the same order of magnitude. For an ordinary GET, the actual execution is just one hash table lookup—microseconds or even nanoseconds. The bottleneck simply isn't CPU computation.

No thread-switching overhead: single-threaded execution means no locks, no contention, no complex concurrency control. In a multi-threaded model, context switches, lock contention, and cache invalidation aren't cheap; when each request needs only a tiny amount of processing, the cost of that concurrency machinery can exceed the benefit. Choosing a single thread is essentially Redis making a judgment call: command execution isn't the bottleneck, network IO is—so solve concurrency at the IO layer and keep the execution layer as simple as possible.

On top of that, Redis's internal data structures serve this model: SDS strings, skip lists, ziplists, and so on are all optimized for memory access, keeping individual operation paths very short.

IO Multiplexing​

Redis doesn't handle one connection at a time—it uses an IO multiplexing model.

IO multiplexing means one thread monitors many sockets at once, with the operating system telling you "these connections have data ready to read/write," so the thread handles only the ready ones. Compared with the traditional one-thread-per-connection model, it avoids paying each connection's thread memory and scheduling cost, letting a single thread support a massive number of connections.

The IO models Redis uses include:

  • epoll (Linux)
  • kqueue (macOS / BSD)
  • select
  • evport

At compile time Redis automatically picks the best implementation for the platform—on Linux that's epoll. In the source this abstraction layer is called ae (A simple Event driven programming library), which exposes a unified event interface to the layers above.

Redis listens on all client connections through its event loop:

             ┌───────────────┐
Client 1 ───▶│               │
Client 2 ───▶│               │
Client 3 ───▶│  IO Multiplex │
Client N ───▶│               │
             └───────┬───────┘
                     │
                     ▼
               Redis EventLoop
                     │
                     ▼
               Command Execute

The processing flow:

  1. Monitor many client sockets
  2. Detect which socket has data ready
  3. Read the request
  4. Execute the command
  5. Return the result

Each turn of the event loop pulls the ready events from the multiplexing interface and processes them one by one: for read events, parse and execute the command; for write events, send results back to the client. Because each event is handled quickly, the loop spins fast enough that clients never notice they're "waiting in line."

That's how Redis can handle a huge number of connections on a single thread.

Redis 6's Multi-Threading Improvements​

As hardware advanced and CPU core counts grew, the single-threaded model hit a ceiling in certain scenarios—and that ceiling is mainly network IO.

For example:

  • Very large numbers of client connections
  • Massive volumes of network traffic

Command execution itself is pure in-memory work and blindingly fast; but reading requests out of kernel buffers and writing responses back—those read/write system calls have real cost. Past a certain traffic level, the main thread spends most of its time moving data, and actual command execution becomes a small fraction—that is the ceiling of the single-threaded model.

So Redis 6 introduced IO threads.

The execution flow becomes:

Client Request
       │
       ▼
IO Threads (read)
       │
       ▼
Main Thread Execute Command
       │
       ▼
IO Threads (write)

The idea is clean: hand the "porter" work—reading/parsing requests and writing back responses—to multiple IO threads in parallel, while command execution still converges on the main thread and runs serially. This exploits multiple cores to boost network throughput while fully preserving the atomicity semantics of single-threaded execution—application code doesn't need to change at all.

Therefore:

  • Command execution remains single-threaded
  • IO operations can run in parallel

Note that IO threads are disabled by default and enabled via configuration:

# redis.conf
# Number of IO threads; keep it below the CPU core count
io-threads 4
# By default only writes use IO threads; enable this to parallelize reads/parsing too
io-threads-do-reads yes

It only makes sense to enable this on instances where network traffic is genuinely the bottleneck; in low-traffic scenarios it just adds a layer of thread coordination overhead.

Practical Advice for the Single-Threaded Model​

Because command execution is single-threaded, keep the following in mind. One slow command blocks every client's requests—this is the part of the single-threaded model that deserves the most respect.

Avoid Slow Commands​

For example:

# Scans the entire keyspace, O(N), blocking all requests while it runs
KEYS *

Commands like this block Redis.

Instead, use:

# Cursor-based batched iteration—processes a small chunk each time, no long blocking
SCAN

Similar offenders include full-read commands on large collections such as SMEMBERS, HGETALL, and LRANGE 0 -1—all of them essentially stuff O(N) work into the single thread.

Keep Big Keys Under Control​

Big keys cause:

  • Network congestion
  • Longer CPU execution time

Moreover, deleting and expiring big keys also happens on the main thread (unless you use UNLINK or enable lazy freeing)—when a key of several hundred MB expires, it can produce a visible latency spike.

Recommendations:

  • Split the data up
  • Use hashes / sets

Use Pipelines​

Pipelines reduce network round trips:

client -> redis -> client

Without a pipeline, each command waits for the previous response before the next one is sent, so throughput is capped by network RTT. A pipeline batches a group of commands, sends them in one go, and collects all responses at once, compressing N round trips into one.

This improves overall throughput.

Pitfalls and Caveats​

A few points that are easy to overlook in practice, given the threading model:

  1. Lua scripts also block the main thread. While a script runs, Redis processes no other commands; a script looping over a large amount of data is effectively one giant slow command.

  2. Don't interpret Redis 6's IO threads as "concurrent command execution." The atomicity semantics of transactions, Lua, and INCR are completely unchanged—no extra locking needed. Likewise, don't expect IO threads to fix slow commands: if the slowness is in the execution layer, multi-threaded IO can't help.

  3. When investigating stalls, check the slow log first. SLOWLOG GET records command execution time (excluding network) and is the first stop for diagnosing "Redis occasionally hiccups"; combined with the latency family of commands, you can further distinguish slow commands from slow forks or slow disks.

  4. A single instance not saturating multiple cores is normal. Command execution uses only one core. To utilize a whole multi-core machine, the usual approach is multiple instances per host or Redis Cluster—not waiting for Redis to go multi-threaded on execution.

Summary​

Through in-memory operations, IO multiplexing, an event-driven architecture (event loop), and single-threaded command execution, Redis achieves extremely high concurrency while avoiding lock contention and thread-switching overhead. Redis 6's IO threads only parallelize network send/receive—command execution remains serial. That core hasn't changed, so the usage principles built around it (avoid slow commands, control big keys, use pipelines wisely) remain valid. Once you understand this, many Redis best practices stop being memorized checklist items and become inevitable conclusions derived from the model.

COMMENTS