Understanding Redis Thread Model and Event Mechanism

Recently a friend asked for an article on Redis's thread model to avoid awkward interview moments, so here it is.

What is a Redis event?

Redis is an event‑driven program. When a client sends a request (e.g., GET ), the connection is established, the request is sent, and an event is triggered. Understanding events is a prerequisite for the thread model.

Redis events are of two types: file events and time events .

What is a file event?

A file event abstracts a socket. Each client connection corresponds to a socket, and each socket is treated as a file event. When a file event occurs, it is handed to a file‑event handler composed of an I/O multiplexing processor, a file‑event dispatcher, and an event processor.

How does the server work after receiving a request?

From the diagram, the processing steps are:

The server receives file events via the I/O multiplexing processor and enqueues them.

The file‑event dispatcher distributes events to appropriate handlers (e.g., a GET request goes to the read‑event handler).

The handler executes the operation and returns the result.

The dispatcher continues with the next event in the queue, resembling a producer‑consumer model.

Redis implements I/O multiplexing with mechanisms such as epoll , select , evport , kqueue , chosen at compile time via macros.

Now, regarding the second event type:

What is a time event?

Time events are operations scheduled at specific times, such as periodic RDB/AOF persistence, master‑slave synchronization, heartbeat messages, or key expiration checks.

How are time events implemented?

All time events are linked in a list; each node stores the next execution timestamp. The list is traversed periodically, executing due events and updating their next timestamps.

How do file events and time events cooperate?

The cooperation works as follows:

After server startup, it listens for file events; when a file event occurs, it is processed, then the server traverses time events. If a file event takes too long, it is paused for the next cycle.

When processing time events (e.g., RDB/AOF persistence), a separate thread is forked so the main thread is not blocked.

This loop repeats, completing the combined workflow.

Why did Redis 6.0 introduce multithreading?

Redis 6.0 added optional multithreading (disabled by default) to address performance bottlenecks in network I/O and memory. While command execution remains single‑threaded, network I/O can now use multiple threads, improving throughput in production environments.

Memory capacity issue: Cluster deployment with multiple ports can increase total memory.

Network I/O issue: Data transfer over the network is the main latency source; multithreading speeds up I/O while keeping command execution single‑threaded.

Conclusion

This article analyzed Redis's thread work model from an event perspective; the next piece will explore common caching solutions in production. Stay tuned.