Why is Redis single threaded

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.

Because CPU is not the bottleneck of Redis. The bottleneck in Redis is most likely to be machine memory or network bandwidth, and since single-threading is easy to implement and CPU is not a bottleneck, it makes sense to adopt a single-threaded solution. About redis performance, the official website also has, ordinary notebook easily handle hundreds of thousands of requests per second.

Why is Redis so fast

1, completely memory based, most 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.

2, the data structure is simple, the data operation is also simple, Redis data structure is specially designed;

3, 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;

4. Use multi-channel I/O multiplexing model, non-blocking IO;

5, the use of the underlying model is different, between them the underlying implementation and communication with the client between the application protocol is not the same, Redis directly built their own VM mechanism, because the general system call system function, will waste a certain amount of time to move and request;

Multiplex I/O multiplexing model, non-blocking IO

In the following example, a TCP server is simulated to handle 30 client sockets. Suppose you are an invigilator and ask 30 students to solve a competition question. Then you are responsible for checking the students’ answers. You have several choices:

  1. The first option: check and accept one by one in order. First check and accept A, then B, then C, D… If one student gets stuck, the whole class is delayed. This mode is as if you were looping through sockets one by one with no concurrency at all.
  2. Option two: You create 30 doppelganger, and each doppelganger checks if a student’s answer is correct. This is similar to creating a process or thread for each user to process the connection.
  3. The third option is, you stand on the stage and whoever answers the question raises their hand. At this time, C and D raise their hands, indicating that they have answered the question, you go down to check the answers of C and D in turn, and then continue to return to the platform. At this point, E and A raise their hands again, and then deal with E and A… This is the IO reuse model, and Linux select, poll, and epoll do this. Register the FDS of user sockets with epoll, and epoll helps you monitor which sockets are receiving messages, thus avoiding a lot of useless operations. The socket should be in non-blocking mode. In this way, the entire process blocks only when the select, poll, and epoll calls are called. Sending and receiving customer messages is not blocked, and the entire process or thread is fully used. This is event-driven, called reactor pattern.

The above example is shown in Redis as

There are 30 Redis clients (examinees) who maintain TCP connection with the network connection module (invigilators) of redis server. The clients will send requests to the server from time to time. When a Redis client initiates a request, the Unix system calls such as epoll will be triggered. Redis’s I/O multiplexing module encapsulates the underlying I/O multiplexing functions such as epoll, which are then forwarded to the appropriate event handler.

The file event handler uses the I/O multiplexing module to listen for multiple FDS (file descriptors) at the same time. When accept, Read, write, and Close file events occur, the file event handler calls back to the FD-bound event handler.

Although the whole file event processor runs on a single thread, the I/O multiplexing module is introduced to realize the monitoring of multiple FD reads and writes at the same time, which improves the performance of the network communication model and ensures the simplicity of the whole Redis service implementation.