Shulou(Shulou.com)05/31 Report--

This article mainly introduces why redis is single-threaded, the article is very detailed, has a certain reference value, interested friends must read it!

Redis, that is, remote dictionary service, is an open source log database written in ANSI C language, which supports network, memory-based and persistent Key-Value database, and provides API in multiple languages.

File event handler

Redis developed a network event handler based on the Reactor pattern, which is called a file event handler. It consists of four parts: multiple sockets, IO multiplexer, file event dispatcher and event handler. Redis is called a single-threaded model because the consumption of the file event dispatcher queue is single-threaded.

Message processing flow

The file event handler uses the Iram O multiplexing (multiplexing) program to listen to multiple sockets at the same time and correlate different event handlers for the socket according to the tasks currently performed by the socket.

When the monitored socket is ready to perform operations such as connection reply (accept), read (read), write (write), close, and so on, the file event corresponding to the operation will be generated, and the file event handler will call the event handler associated before the socket to handle these events.

Although multiple file events may occur concurrently, the Imax O multiplexer always pushes all the sockets that generate the events into a queue and then passes through that queue Send sockets to the file event dispatcher one socket at a time, one socket at a time, one synchronously at a time: when the event generated by the previous socket is processed (the socket is executed by the event handler associated with the event), the Igamo multiplexer will continue to transmit the next socket to the file event dispatcher.

The implementation of Ipaw O Multiplexing Program

All the functions of Redis's Icano multiplexing program are realized by wrapping select, epoll, evport and kqueue, each of which corresponds to a separate file in the Redis source code, such as ae_select.c, ae_epoll.c, ae_kqueue.c and so on.

Because Redis implements the same API for each Ihammer O multiplexing function library, the underlying implementation of the Imax O multiplexing program is interchangeable, as shown in the following figure.

For a detailed explanation of epoll, you can click to view it and thoroughly understand the principle of efficient operation of epoll.

Redis defines the corresponding rules with the # include macro in the implementation source code of the Redis O multiplexing program. The program will automatically select the best performance Icando O multiplexing function library in the system at compile time as the underlying implementation of the Icando O multiplexing program:

/ * Include the best multiplexing layer supported by this system. * The following should be ordered by performances, descending. * / # ifdef HAVE_EVPORT#include "ae_evport.c" # else # ifdef HAVE_EPOLL # include "ae_epoll.c" # else # ifdef HAVE_KQUEUE # include "ae_kqueue.c" # else # include "ae_select.c" # endif#endif # endif

Type of file event

The Icano multiplexer can listen for ae.h/AE_READABLE events and ae.h/AE_WRITABLE events of multiple sockets. The corresponding relationship between these two types of events and socket operations is as follows:

The socket generates an AE_READABLE event when the socket becomes readable (the client performs a write operation on the socket, or performs a close operation), or when a new acceptable socket appears (the client performs a connect operation on the server's listening socket).

When the socket becomes writable (the client performs a read operation on the socket), the socket generates an AE_WRITABLE event. The IAE_WRITABLE O multiplexer allows the server to listen for both AE_READABLE and AE_WRITABLE events of a socket. If both events are generated by a socket, the file event dispatcher will give priority to the AE_READABLE event and wait until the AE_READABLE event has been processed before processing the AE_WRITABLE event. That is, if a socket is both readable and writable, the server will read the socket first and then write the socket.

The handler of the file event

Redis writes multiple handlers for file events, and these event handlers are used to implement different network communication requirements. The common handlers are as follows:

In order to reply to each client that connects to the server, the server associates the response processor for the listening socket.

In order to receive the command request from the client, the server requests the command processor for the client socket association command.

In order to return the execution result of the command to the client, the server replies to the processor for the command associated with the client socket.

Connect the answer processor

The acceptTcpHandler function in networking.c is the connection response processor of Redis, which is used to reply to the client that connects to the server listening to the socket, which is implemented as the wrapper of the sys/socket.h/accept function.

When the Redis server initializes, the program will associate the connection reply processor with the AE_READABLE event of the server listening socket. When a client connects to the server listening socket with the sys/socket.h/connect function, the socket will generate an AE_READABLE event, causing the connection response processor to execute and perform the corresponding socket reply operation, as shown in the figure.

Command request processor

The readQueryFromClient function in networking.c is the command request processor of Redis, which is responsible for reading the command request content sent by the client from the socket, which is implemented as the wrapper of the unistd.h/read function.

When a client successfully connects to the server through a connection reply processor, the server associates the AE_READABLE event of the client socket with the command request handler. When the client sends a command request to the server, the socket generates an AE_READABLE event, triggering the command request processor to execute and performing the corresponding socket read operation, as shown in the figure.

Throughout the client connection to the server, the server always associates the command request processor for the AE_READABLE event of the client socket.

Command reply processor

The sendReplyToClient function in networking.c is the command reply processor of Redis, which is responsible for returning the command reply obtained by the server after executing the command to the client through the socket, which is realized as the wrapper of the unistd.h/write function.

When the server has a command reply to send to the client, the server will associate the AE_WRITABLE event of the client socket with the command reply processor. When the client is ready to receive the command reply from the server, it will generate the AE_WRITABLE event, trigger the command reply processor to execute, and perform the corresponding socket write operation, as shown in the figure.

When the command reply is sent, the server disassociates the command reply processor from the AE_WRITABLE event of the client socket.

An example of a complete client-server connection event

Assuming that the Redis server is running, the AE_READABLE event of the server's listening socket should be in the listening state, and the corresponding processor of the event is the connection reply processor.

If a Redis client initiates a connection to the Redis server, the listening socket generates an AE_READABLE event that triggers the connection reply processor to execute: the processor answers the client's connection request, then creates the client socket and the client state, and associates the AE_READABLE event of the client socket with the command request processor Enables the client to send a command request to the master server.

After that, the client sends a command request to the Redis server, then the client socket will generate an AE_READABLE event, trigger the command request processor to execute, and the processor reads the command content of the client, and then passes it to the relevant program to execute.

Executing the command will generate a corresponding command reply, and in order to send these command replies back to the client, the server will associate the AE_WRITABLE event of the client socket with the command reply processor: when the client tries to read the command reply, the client socket will generate an AE_WRITABLE event, triggering the command reply processor to execute, and when the command reply processor writes all the command reply to the socket The server disassociates the AE_WRITABLE event of the client socket from the command reply processor.

The above is all the content of the article "Why redis is single-threaded". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.