Understanding Redis 7.0.11 Multithreading Configuration and Operation

Redis 7.0.11 introduces a multithreading mode that can be enabled by configuring two options in the source code: server.io_threads_do_reads and server.io_threads_num. The corresponding configuration calls are shown below.

createBoolConfig("io-threads-do-reads", NULL, DEBUG_CONFIG | IMMUTABLE_CONFIG, server.io_threads_do_reads, 0, NULL, NULL), /* Read + parse from threads? */
createIntConfig("io-threads", NULL, DEBUG_CONFIG | IMMUTABLE_CONFIG, 1, 128, server.io_threads_num, 1, INTEGER_CONFIG, NULL, NULL), /* Single threaded by default */

1. Enabling multithreading requires setting the two options mentioned above.

2. During the beforesleep phase, Redis evaluates the write‑backlog of each client; if the backlog exceeds a threshold, multithreading is turned on.

3. In the processTimeEvents stage, the same backlog check may disable multithreading; the mode is activated only when the backlog is greater than or equal to server.io_threads_num * 2.

4. When multithreading is active, network reads are performed by a thread pool, each client’s data is read into a buffer and parsed, while command execution remains single‑threaded and the response is written back to the client’s write buffer.

5. For writes, each client’s write buffer is flushed to the network by a thread from the pool.

6. Each write operation to the network has a byte‑size limit; if the data is not fully sent, a write event is registered and the remaining data is sent in the next event loop iteration, which is not considered part of the multithreaded mode.

7. Command execution itself is single‑threaded; large keys or values can block the server, so performance impact must be considered.

The author notes that Redis’s multithreading implementation is still imperfect, especially when network writes are limited and trigger write events that are handled outside the multithreaded path.