Redis Threading Model

0. Preface

Redis has developed its own network event handler based on the Reactor mode: This processor is known as the file event handler (handler):

• The file event handler uses an I/O multiplexing (multiplexing) program to listen to multiple sockets at the same time and correlate different event handlers for sockets based on the tasks currently performed by the socket.
  
• When a listening socket is ready to perform an operation such as a connection answer (accept), read (read), write (write), close (close), the file event corresponding to the operation is generated, and the file event handler invokes the associated event handler before the socket to handle these events.

Although the file event handler runs in a single-threaded fashion, the file event handler implements a high-performance network communication model and is able to interface well with other modules that are similarly single-threaded in the Redis server by using the I/O multiplexing program to listen for multiple sockets, which preserves the Redis Simplicity of the internal single-threaded design.

1. Composition of the file event handler

Shows the four components of the file event handler, which are sockets, I/O multiplexing programs, file event dispatcher (dispatcher), and event handlers, respectively.

A file event is an abstraction of a socket operation that produces a file event whenever a socket is ready to perform operations such as a connection answer (accept), write, read, close, and so on. Because a server typically connects multiple sockets, multiple file events can occur concurrently.

The I/O multiplexer is responsible for listening to multiple sockets and transmitting to the file event dispatcher those sockets that generated the event.

Although multiple file events may occur concurrently, the I/O multiplexer always queues all sockets that generate events into a queue, then through this queue, in order (sequentially), synchronization (synchronously), Send sockets to the file event dispatcher each time a socket: the I/O multiplexer will continue to pass the next socket to the file event dispatcher, as shown in, after the event generated by the previous socket has been processed (the socket is executed for the event handler associated with the event).

The file event dispatcher receives the socket from the I/O multiplexing program and invokes the appropriate event handler based on the type of event that the socket generates.

The server associates different event handlers for sockets that perform different tasks, which are functions that define the actions that the server should perform when an event occurs.

2. Implementation of the I/O multiplexing program

All of the features of the Redis I/O multiplexing program are implemented by wrapping the common Select, Epoll, Evport, and kqueue I/O multiplexing libraries, each of which is in the Redis source code for each I/O multiplexing function library. Should be a separate file, such as ae_select.c, AE_EPOLL.C, ae_kqueue.c, and so forth.

Because Redis implements the same API for each I/O multiplexing Library, the underlying implementation of the I/O multiplexing program is interchangeable, as shown in.

In the implementation of the I/O multiplexing program, Redis uses #include macros to define rules that automatically select the most system-neutral I/O multiplexing function library at compile time as the underlying implementation of the Redis I/O multiplexing program.

3. Type of Event

The I/O multiplexer can listen for multiple sockets of ae.h/ae_readable events and ae.h/ae_writable events, and the correspondence between these two types of events and socket operations is as follows:

• When the socket becomes readable (the client performs a write operation on the socket or performs a close operation), or a new acceptable socket appears (the client performs a connect operation on the server's listening socket), the socket generates ae_readable Event.
• When the socket becomes writable (the client performs a read operation on the socket), the socket produces the Ae_writable event.

The I/O multiplexing program allows the server to listen for both the Ae_readable event and the Ae_writable event of the socket, and if a socket produces both events, the file event dispatcher takes precedence over the Ae_readable event until Ae_readable Handle the Ae_writable event only after the item has been processed.

This means that if a socket is readable and writable, then the server will read the socket first and then write the socket.

4. API

The Ae.c/aecreatefileevent function accepts a socket descriptor, an event type, and an event handler as a parameter, adding a given socket's event to the listening range of the I/O multiplexer and associating the event with the event handler.

The Ae.c/aedeletefileevent function accepts a socket descriptor and a listener event type as a parameter, letting the I/O multiplexer cancel the listener for a given event of a given socket and cancel the association between the event and the event handler.

The Ae.c/aegetfileevents function accepts a socket descriptor that returns the type of event that the socket is listening on:

• If no event is monitored for the socket, then the function returns Ae_none.
• If the read event of the socket is being monitored, then the function returns ae_readable.
• If the write event for the socket is being monitored, the function returns ae_writable.
• If the read and write events of the socket are being monitored, then the function returns Ae_readable | Ae_writable.

The ae.c/aewait function accepts a socket descriptor, an event type, and a number of milliseconds for a parameter, blocks and waits for a given type of socket event to occur within a given time, when the event succeeds, or after the wait time-out, the function returns.

The Ae.c/aeapipoll function accepts a SYS/TIME.H/STRUCT timeval structure as a parameter and, within a specified time, blocks and waits for all sockets that are set to listen state by the aecreatefileevent function to produce a file event. The function returns when at least one event is generated, or after a wait time-out.

The Ae.c/aeprocessevents function is a file event dispatcher that calls the Aeapipoll function to wait for the event to occur, then iterates through all the resulting events and invokes the appropriate event handlers to handle the events.

The Ae.c/aegetapiname function returns the name of the I/O multiplexing function library used by the I/O multiplexer: Returning "Epoll" means the underlying is the Epoll library, and returning "select" means the underlying is the select library, and so on.

5. Processor for file events

Redis has written multiple processors for file events that are used to implement different network communication requirements, such as:

• In order to answer each client that connects to the server, the server will associate the connection answering processor for the listening socket.
• In order to receive a command request from a client, the server requests the processor for the Client Socket Association command.
• In order to return the execution result of the command to the client, the server responds to the handler for the Client Socket Association command.
• When the primary server and the replication operations are performed from the server, the master and slave servers need to correlate with the replication processor specifically written for the replication function.
• Wait a minute.
  In these event handlers, the server is most commonly used to communicate with the client connection answering processor, command request processor, and command reply processor.

5.1 Connecting the answering processor

The Networking.c/accepttcphandler function is a Redis connection answering processor, which is used to respond to clients that connect to a server listening socket, and is implemented as a wrapper for the sys/socket.h/accept function.

When the Redis server is initialized, the program associates this connection answering processor with the server listening socket ae_readable event, and when a client uses the Sys/socket.h/connect function to connect to the server to listen to the socket, the socket generates AE The _readable event, which raises the connection answering processor, executes and performs the corresponding socket answer operation, as shown in.

5.2 Command Request processor

The Networking.c/readqueryfromclient function is a Redis command request processor, which is responsible for reading the command request content sent from the client from the socket, which is implemented as a wrapper for the Unistd.h/read function.

When a client successfully connects to the server through a connection answering processor, the server associates the Ae_readable event of the client socket with the command request processor, and the socket generates a Ae_readable event when the client sends a command request to the server. Raises the command request handler to execute and performs the corresponding socket read-in operation as shown in.

Throughout the client connection to the server, the server will always request the processor for the client socket's Ae_readable Event Association command.

5.3 Command Reply processor

The Networking.c/sendreplytoclient function is a Redis command reply handler, which is responsible for returning the command reply from the server to the client via a socket, which is implemented as a wrapper for the Unistd.h/write function.

When a server has a command reply that needs to be routed to the client, the server associates the Ae_writable event of the client socket with the command reply handler, and when the client is ready to receive the command reply returned by the server, it generates a ae_writable event that causes the command reply handler to execute. and perform the corresponding socket write operation, as shown in.

When the command reply is sent, the server will dismiss the association between the command reply processor and the Ae_writable event of the client socket.

5.4 Example of a complete client-server connection event

Let's trace the entire process of the Redis client connecting to the server and sending commands to see what happens in the process, and how the events are handled.

Assuming a Redis server is working, the Ae_readable event for the listener socket on this server should be in the listening state, and the corresponding processor for that event is the connection answering processor.

If at this point a Redis client initiates a connection to the server, the listener socket generates a ae_readable event that triggers the connection answering processor to execute: The processor responds to the client's connection request, creates a client socket, and client state, and ae_r the client socket The Eadable event is associated with the command request processor, allowing the client to send command requests to the primary server.

Then, assuming that the client sends a command request to the primary server, the client socket generates the Ae_readable event, which causes the command request processor to execute, the processor reads the client's command content, and then passes it on to the relevant program to execute.

The execute command will produce a corresponding command reply, in order to return these command replies back to the client, the server associates 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 produce the Ae_writable event. Triggers the command to reply to the processor execution, and when the command reply processor writes all the command replies to the socket, the server unlocks the association between the ae_writable event of the client socket and the command reply processor.

Summarizes the entire communication process described above, and the event handlers used to communicate.

5.5 Receiving Network Connections

Completed the service side of the network initialization, and the event polling has begun to work, what the event polling to do, is to constantly rotation multiplexer, to see if the event has not occurred before, if it happens, it will separate the event, into the EventLoop fired array, These events are then processed.

Redis will continuously rotation the multiplexer, separate the network events, if it is an accept event, the new receive client connection and register it to the multiplexer and EventLoop, if it is a query event, by reading the client's command to do the corresponding processing, all of which are single-threaded, Sequential execution, so no concurrency problems occur.

Reference:
73732883

Redis Threading Model