Why does Redis use single threads?

Before we get to that, let’s take a look at the common overhead of introducing multithreading:

1. Context switch:

Even single-core cpus support multi-threaded code execution, and the CPU implements this mechanism by allocating CPU time slices to each thread. The time slice is the time that the CPU allocates to each thread. Because the time slice is very short, the CPU makes us feel that multiple threads execute simultaneously by constantly switching threads. The time slice is generally tens of milliseconds (ms).

The CPU uses the time slice allocation algorithm to execute tasks in a cycle. After the current task executes a time slice, it switches to the next task. However, the state of the previous task will be saved before switching, so that the state of the task can be loaded again when switching back to the task next time. The process from saving the task to reloading is a context switch.

When a new thread is switched in, the data it needs may not be in the current processor’s local cache, so the context switch will result in some cache misses and the thread will run more slowly on the first schedule. This is why the scheduler assigns a minimum execution time for each runnable thread.

2. Synchronize memory

The visibility of memory is not covered here.

3. Block:

A lock is required to access shared resources to ensure data security. When a lock contention occurs, the thread that fails to compete will be blocked.

Usually, when we use multithreading, if we don’t have a good system design, we actually get something like this. When we first increase the number of threads, throughput increases, but as we increase the number of threads further, throughput slows down and sometimes even drops.

The key reason is that there is often a shared resource, such as a shared data structure, that can be accessed simultaneously by multiple threads. When multiple threads modify the shared resource, additional mechanisms are required to ensure that the shared resource is correct, and this additional mechanism incurs additional overhead. Without careful design, such as simply using a coarse-grained mutex, the result is undesirable: even if you add threads, most of the threads are waiting for the mutex to access a shared resource, parallelism becomes serial, and system throughput does not increase with the number of threads.

Why is Redis so fast?

  • Redis is memory based implementation completely memory based, the vast majority of requests are pure memory operations, very fast. Data is stored in memory, similar to a HashMap, which has the advantage of O(1) time complexity for both lookup and operation.

  • The data structure is simple and the operation of the data is also simple. The data structure in Redis is specially designed.

  • The use of single thread, avoid unnecessary context switch and competition conditions, there is no multi-process or multi-threading caused by the switch and CPU consumption, do not have to consider the problem of various locks, there is no lock release lock operation, there is no performance consumption due to the possibility of deadlock;

  • Redis multiplexing mechanism

The IO multiplexing mechanism in Linux refers to the process of multiple I/O streams by a single thread, and is often referred to as the SELECT /epoll mechanism. In simple terms, this mechanism allows multiple listening sockets and connected sockets to exist simultaneously in the kernel, in the case that Redis only runs on a single thread. The kernel always listens for connection requests or data requests on these sockets. As soon as a request arrives, it is handed over to the Redis thread for processing, which implements the effect of one Redis thread processing multiple IO streams.