Why is Redis so fast

1. 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 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;

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

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

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. Epoll listens for incoming events on the socket and calls the fD-bound event handler when an Accept, read, write, or close file event occurs.

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.

end