Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the Redis event-driven model". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what the Redis event-driven model is.

I. Multiplexing

"Multiplex" refers to multiple network connections, and "reuse" refers to the reuse of the same thread.

The multiplexing model of multiple streams uses the ability of select, poll, and epoll to monitor multiple streams' Icano events at the same time, blocking the current thread when idle, and waking up from the blocked state when one or more streams have Icano events, so the program polls all streams once (epoll polls only those streams that actually emit events) and processes only those that are ready in sequence. This practice avoids a large number of useless operations.

Redis uses multiplexing technology to handle concurrent connections. The internal implementation of non-blocking IO adopts epoll and adopts a simple event framework implemented by epoll+ itself. Read, write, close, and connect in epoll are all converted into events, and then make use of the multiplexing feature of epoll to never waste any time on io.

II. Redis event

The Redis server is an event driver that mainly handles the following two types of events:

File events: file events are actually abstractions of Socket operations. The communication between the Redis server and the Redis client will generate file events. The server monitors and handles these events to complete a series of network operations.

Time event: time event is actually the abstraction of timing operation. As we have mentioned earlier, RDB, AOF, and timing deletion keys can be completed by the server to schedule or periodically, and the underlying layer is realized by triggering time events.

2.1 File event

A file event is an abstraction of a socket operation, and a file event occurs whenever a socket is ready to perform connection reply (accept), write, read, close, and so on. Because a server usually connects multiple sockets, multiple file events may occur concurrently

Redis developed its own event handler based on the Reactor pattern

Although multiple file events may occur concurrently, the Imax O multiplexer always queues all the sockets that generate the events into a queue and then passes through that queue. Transfer 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 whole process of a Redis client connecting to the server and sending commands

The Redis client initiates a connection to the server

The listening socket generates an AE_READABLE event that triggers the connection response processor to execute: the processor responds to 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 so that the client can send a command request to the master server

If the client sends a command request to the master server, the client socket will generate an AE_READABLE event, issue a command to the 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 that triggers 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

2.2 time event

The continuously running Redis server checks and adjusts its resources and status periodically. These regular operations are performed by the serverCron function, and its main tasks include:

Update server statistics (time, memory footprint, database footprint)

Clean up out-of-date key-value pairs in the database

AOF, RDB persistence

If it is a master-slave server, periodically synchronize the slave server

If it is in cluster mode, synchronize and connect to the group regularly.

The Redis server puts time events in a linked list, and when the time event executor runs, it traverses the entire list. Time events include:

Periodic events (Redis generally only executes serverCron time events, serverCron time events are periodic)

Timing event

Implementation ideas:

Record the last time this function was executed to deal with the problem caused by the modification of the system time.

Traverse the linked list to find all events whose when_sec and when_ms are less than the current time.

Executes the handler function corresponding to the event.

Check the event type, and if it is a periodic event, refresh the next execution event for that event.

Otherwise, delete the event from the list

Thank you for reading, the above is the content of "what is the Redis event-driven model". After the study of this article, I believe you have a deeper understanding of what the Redis event-driven model is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.