“This is the 14th day of my participation in the November Gwen Challenge.The final text challenge in 2021”.

The event

Redis server is an event driver, the server needs to handle two types of events, one is a file event, one is a time event. I’m going to focus on file events.

File events

The Redis server connects to the client through socket. The file event is the abstraction of socket operation. The communication between the server and the client will generate the file event in response, and the server will complete a series of network communication operations by listening and processing these events.

Redis developed its own network event handler based on the Reactor pattern, which is called file event handler.

• File event handlers use I/O multiplexers to listen on multiple sockets at the same time and associate different event handlers with the socket based on the task the socket is currently performing.

• When the socket being listened to is ready for connection reply, read, write, close, etc., file events corresponding to the operation will be generated, and the file event handler will call the event handler associated with the socket to handle these events.

Redis is single-threaded because file event handlers run single-threaded, but they implement a high-performance network communication model by listening for multiple sockets through I/O multiplexing programs.

File event handler composition

The file event handler consists of four parts, namely socket,I/O multiplexer, file event dispatcher, and event processing.

Whenever a Sokcet is ready to perform connection reply, write, read, close, etc., a file event is generated. A service usually connects to multiple sockets, so multiple file events can occur concurrently.

The I/O multiplexer listens for multiple sockets and passes the socket that generated the event to the file event dispatcher.

The I/O multiplexer queues all event-generating sockets through which sockets are sent to the file event dispatcher in an ordered, synchronous, one-socket at a time manner. After an event generated by a socket has been processed, the next socket is sent to the file event dispatcher.

The file event dispatcher invokes the corresponding event handler based on the type of event generated by the socket.

All the functionality of Redis’S I/O multiplexing program is achieved by wrapping the common library of multiplexing functions such as SELECT, Epoll, EVport, and so on.

The event type

I/O multiplexers can listen for AE_readable and AE_writable events on multiple sockets. These two types of events correspond to sockets as follows:

• When the client writes to the socket, the socket becomes readable and an AS_readable event is generated

• When a client reads a socket, the socket becomes writable and ae_writable events are generated.

If a socket generates both of these events, the file event dispatcher processes ae_readable events first.

Handler for file events

File event pairs should have multiple processors to meet different network communication requirements

1. Connection response processor

This handler is used to reply to clients that connect to the server listening on the socket.

When a client requests a connection, the socket emits an AE_readable event that causes the connection reply handler to execute.

2. Command request handler

This handler is responsible for reading the content of the command request sent by the client from the socket.

When the client connects to the server through the connection reply processor, the server associates the AE_readable event of the client socket with the command request processor. When the client sends a command request to the server, the Socket generates ae_readable events, which triggers the command request processor to execute the command request.

3. Command reply handler

Responsible for the server to execute the command to get the command reply through the socket back to the client.

When the server sends a command reply to the client, the server associates 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, the AE_WRITable event is generated, triggering the reply processor to execute the event.

A complete sample of client and server connection events

Assuming that a Redis server is running, the ae_readable event of the server’s listening socket will be listening and corresponds to the connection reply handler.

If a Redis client initiates a connection to the server at this point, listening on the socket will generate an AE_readable event that triggers the connection reply handler to execute, creating the client socket, and then associating AE_readable with the request handler.

Then, if the client sends a command request to the master server, the client socket will generate an AE_readable event, which will cause the command request processor to execute.

The ae_writable event of the client socket and the command reply processor are managed to send the command reply to the client. When a client attempts to read a command reply, the AE_writable event is generated, triggering the command reply processor to execute. 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.

Redis is a single threaded model why is it so efficient?

Pure memory access: Data is stored in memory with a response time of about 100 nanoseconds, which is an important basis for Redis terabyte access per second.

Non-blocking I/O: Redis uses Epoll as the implementation of I/O multiplexing, and its own event processing model converts epoll connections, reads and writes, and closes into time, so as not to waste too much time on I/O.

Single threading avoids the cost of thread switching and races.

Redis uses a single thread model, if each command execution takes a lot of time, it will cause other threads to block, which is fatal to the high performance service of Redis, so Redis is a database for high speed execution