Why did Redis choose the single-threaded model in its initial release?

Redis chose to use the single-threaded model to process the vast majority of network requests from clients from the very beginning. There are many reasons for this consideration. The authors analyze the relevant data and find that the most important reasons are as follows:

  1. Using a single-threaded model brings better maintainability and facilitates development and debugging;
  2. Client requests can be processed concurrently using the single-threaded model. The performance gains from using a multithreaded model do not offset the development and maintenance costs
  3. The performance bottleneck for the vast majority of operations running in the Redis service is not CPU, but memory and network bandwidth, and memory and network bandwidth bottlenecks still exist when using multiple threads.
  4. Avoid context switches and race conditions for multiple threads

Note: Redis single threading refers to the fact that the network request module uses one thread, i.e. one thread to process all network requests, while other modules still use multiple threads.

Warning 1: Here we have been emphasizing the single thread, only in the process of our network request only one thread, a formal Redis Server running must be more than one thread, here we need to pay attention to clearly! For example, Redis will persist as child process or child thread (whether child thread or child process needs further research). For example, I look at the Redis process on the test server and find the thread under that process:

The “-t” parameter of the ps command indicates the thread to be displayed (Show Threads, possibly with SPID Column.). The “SID” column indicates the thread ID, while the “CMD” column indicates the thread name.

Warning # 2: In the last paragraph of the FAQ above, it states that Redis 4.0 will support multi-threading, but only for certain operations! So this article in the future version of the single-thread way needs to be verified by readers!

Why did Redis add multithreading support in versions after 4.0?

FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB FLUSHDB Why do they need to be processed asynchronously through multiple threads?

Delete operation

We can use the DEL command in Redis to delete the value of a key. If the key-value pairs to be deleted occupy a small amount of memory, it does not take much time to delete them synchronously.

However, for some very large key pairs in Redis, tens or hundreds of MEgabytes of data cannot be processed in a few milliseconds, and Redis may need to spend a lot of time freeing memory space, which will block the pending task. Affects PCT99 and availability for Redis services to process requests.

However, the task of freeing memory can be handled asynchronously by background threads. This is how the UNLINK command works. It simply removes the key from the metadata, and the actual deletion is performed asynchronously in the background.

end