Redis Learning Notes-Event handling

The Redis server is an event driver and the server needs to handle the following two types of events:

• File event: The Redis server connects to the client (or other Redis server) through a socket, and the file event is the server's abstraction of the socket operation. The communication between the server and the client (or other server) generates corresponding file events, and the server completes a series of network communication operations by listening for and processing these events;
• Time event: Some operations in the Redis server (such as the Servercron function) need to be performed at a given point in time, and the time event is the server's abstraction of such timed operations.

File Event File event 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.

Composition

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

Four components of a file event handler

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 multiplexing program always places all sockets that generate events into a queue, and then through this queue, in order (sequentially), synchronization (synchronously), Sends a socket to the file event dispatcher each time a socket is received.

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 generated by the socket;

Event handlers are functions that define the actions that the server should perform when an event occurs.

Implementation of the I/O multiplexing program

All of the functions 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 corresponds to a separate file in the Redis source code, such as Ae_ Select.c, AE_EPOLL.C, ae_kqueue.c, etcetera.

Because Redis implements the same API for each I/O multiplexing function library, the underlying implementation of the I/O multiplexing program is interchangeable,

In the implementation of the I/O multiplexing program, Redis defines the corresponding rules using the # include macro, which automatically selects the most system-neutral I/O multiplexing function library at compile time as the underlying implementation of the Redis I/O multiplexing program:

# 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 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 if there is a new acceptable socket (the client performs a listening socket on the server Connect operation), 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_ The Ae_writable event is processed only after the readable event has been processed.

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 and event handlers;
• The Ae.c/aedeletefileevent function accepts a socket descriptor and a listener event type as a parameter, allowing the I/O multiplexer to cancel the listener of a given socket for an event and to 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 the socket does not have any events being monitored, 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 of the socket is being monitored, then 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 has been generated, or the wait has timed out;
• The Ae.c/aeprocessevents function is a file event dispatcher that calls the Aeapipoll function to wait for the event to occur, and then iterates through all the generated 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 multiplexing Program: Returning "select" means the underlying is the select library, and so on.

Processor for file events

Connect the answering processor

The networking.c/accepttcphandler function is a Redis connection answering processor that is used to answer clients that connect to the server listening sockets. Its main call anet.c in the Anettcpaccept function implementation, specifically implemented as sys/socket.h/accept function wrapper.

When the Redis server is initialized, the program associates this connection answering processor with the ae_readable event of the server listening socket, when there is a client with the Sys/socket.h/connect function . When the connection server listens to the socket, the socket generates a Ae_readable event, causes the connection answering processor to execute, and performs the corresponding socket answer operation.

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 , specifically implemented as unistd.h/ The wrapper for the 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 AE_ when the client sends a command request to the server The readable event, which raises the command request processor execution, and performs the corresponding socket read-in operation;

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

Command Reply handler

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 processor , and when the client is ready to receive the command reply returned by the server, The Ae_writable event is generated, triggering the command to reply to the processor execution and performing the corresponding socket write operation .

Redis Learning Notes-Event handling