Redis is a single-threaded, high-efficiency in-memory database designed based on the Reactor model. Its core is actually composed of event-driven components. The commonly known Reactor model is reflected in the event-driven model, as follows

Redis is an event driver with two types of events

  • File: Redis server through a socket with the client (or other Redis server) to connect, file events is the server socket operation of abstract, server and client communication will generate the corresponding files, while the server is through listening to complete a series of network communication and deal with the event.
  • Time events: Time events are abstractions of timed operations in Redis, such as the serverCron function, that need to be executed at a given point in time

File events

Redis network event handler is based on Reactor pattern, also known as file event handler.

  • File event handlers use I/O multiplexing to listen for multiple sockets at the same time and associate different event handlers based on the tasks performed by the socket

File events run in a single-threaded fashion, but by using I/O multiplexing programs to listen for multiple sockets, file event handlers implement a high-performance network communication model.

File event processing constitutes

The four components of the file event handler are the socket, the I/O multiplexer, the file event dispatcher, and the event handler shown below

Socket: A file event is an abstraction of a socket operation that is generated whenever a socket is ready to accept, write, read, close, and so on. Because a server typically connects to multiple sockets, it is possible for multiple file events to occur concurrently.

I/O multiplexer: The I/O multiplexer listens for multiple sockets and passes those sockets that generated events to the file event dispatcher. I/O multiplexing puts all of the event sockets into a queue that delivers the socket to the dispatcher in an orderly synchronized manner.

File event dispatcher: receives a socket from an I/O multiplexer and invokes the appropriate event handler based on the type of event generated by the socket.

Event handlers: The server associates different event handlers with sockets that perform different tasks. These handlers are functions that define what the server should do when an event occurs.

I/O multiplexing Note here that Redis thread safety only applies to the order in which socket sockets are established. For example, two clients C1, C2, c1 write k1=” A “, c2 also write k1=”b”, then C2 read k1; At this point, k1 read is uncertain, because the two operations of C2 are not transactional, and the network is fluctuating. But the solution to this problem is simple: client C2 writes two operations to Lua scripts to achieve atomicity of the transaction.

Generally speaking, Redis is a single-thread Reactor model. What is a Reactor model? A Reactor model is a model for managing sockets.

I/O threading model –Reactor Pattern

The classic multithreaded non-blocking I/O model is the Reactor model. When multiple clients request to the server, the server saves a socket connection list. The Reactor divides the entire process of the server into several events, such as receive event, read event, write event, execute event, etc. Reactor uses event detection to distribute these events to different processors for processing. Next, socket traversal and kernel callbacks.

Event detection for kernel traversal sockets

Each socket in the kernel corresponds to a callback function. When the client sends data to the socket, the kernel will call the callback function after receiving the data from the nic. The callback function maintains the event list.

There are multiple client socket connections on the server. First, the application layer tells the kernel what events each socket is interested in. Then, when the client sends data, there is a corresponding callback function (such as epoll, Select, and kqueue), which adds socket 1 to the event list as readable event1 when the kernel successfully copies data from the nic. Similarly, when the kernel discovers that the nic is writable, it adds socket 2 to the event list as writable event2. Finally, the application layer requests the kernel to read and write the event list. The kernel sends the event list containing event1 and Event2 back to the application layer. The application layer knows that socket 1 has data to read through the event list, and socket 2 can write data. See Figure 1.15

I/O multiplexing Redis based on kernel implementation

Redis I/O multiplexing programs are implemented by wrapping the common LIBRARIES of I/O multiplexing functions such as SELECT, Epoll, EVport, and KQueue. You can see the corresponding source files in the Redis source code, such as ae_selection. c, ae_epoll.c, ae_kqueue.c. As for which function to choose, the program automatically selects the highest-performing I/O multiplexing library as the underlying implementation at compile time.