Shulou(Shulou.com)05/31 Report--

Today, the editor will share with you the relevant knowledge of what redis file events and time events are, the content is detailed, and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article.

Redis is single-threaded before 6.0. multithreading can be started through the configuration file after 6.0. multithreading after 6.0refers to the use of multithreading in io to speed up the speed of Ibano.

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

File event (file event)

The Redis server connects to the client (or other Redis server) through sockets, and file events are the server's abstraction of socket operations. The communication between the server and the client (or other servers) will produce corresponding file events, and the server will complete a series of network communication operations by listening and processing these events. The file event handler uses the Iram O multiplexing (multiplexing) program to listen to multiple sockets at the same time and correlate different event handlers for the socket according to the tasks currently performed by the socket. When the monitored socket is ready to perform operations such as connection reply (accept), read (read), write (write), close, and so on, the file event corresponding to the operation will be generated, and the file event handler will call the event handler associated before the socket to handle these events.

Time event (time event)

Some operations in the Redis server (such as the serverCron function) need to be performed at a given point in time, and time events are the server's abstraction of such timing operations. There are two types of time events, the first is timing events (allowing a program to execute once after a specified time) and the other is periodic events (allowing a program to execute at specified intervals).

File event 1, file event handler

The file event processor is composed of four parts: socket, Imax O multiplexer, file event dispatcher and event processor.

The Ithumb O multiplexer is responsible for listening to multiple sockets and passing to the file event dispatcher the sockets that generated the event. Although multiple file events may occur concurrently, the single Imax O multiplexer will always put the sockets of all produced events into a queue, and then through this queue, send sockets to file events in an orderly, synchronous, one socket at a time manner. When the event generated by the previous socket is processed (the event processing associated with the socket is executed), the IWeiO multiplexer will continue to transmit the next socket to the file event dispatcher. The file event dispatcher receives the socket from the Igamo multiplexer and uses the corresponding event handler according to the type of event generated by the socket. The server executes the sockets of different people to associate different event handlers, which define the actions that the server should perform when an event occurs.

2. Icano multiplexing

All the functions of Redis's multiplexing program are realized by wrapping select, epoll, evport and kqueue.

3. File event types

AE_READABLE event

The socket generates an AE_READABLE event when the socket becomes readable (the client performs a write or close operation) or when a new answerable socket appears.

AE_WAITABLE event

An AE_WAITABLE event is generated when the socket becomes writable (the client performs a read operation)

The AE_WAITABLE O multiplexer listens for both AE_READABLE events and AE_WAITABLE events. If both events are generated by a socket, the event dispatcher will give priority to the AE_READABLE event, meaning that the server will read the socket first and then write the socket.

4. The handler of file events

Connect the answer processor

Connection reply processor, which is used to reply to the client that connects to the server listening to the socket. When the Redis server initializes, the program associates the connection response processor with the AE_READABLE event of the server listening for the socket. When the client connects to the server listening for the socket, the socket generates an AE_READABLE event, causing the connection response processor to execute And perform the corresponding socket reply operation.

Command request processor

When a client successfully connects to the server through the connection reply processor, the server will associate the AE_READABLE event of the socket with the command request processor. When the client sends a command request to the server, the socket will generate an AE_READABLE event, trigger the command request processor to execute, and perform socket read-in and other operations. Throughout the client connection to the server, the server always associates the command request processor for the AE_READABEL event of the client socket.

Command reply processor

When the server has a command reply to send to the client, the server will associate 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, it will generate an AE_WAITABEL event, causing the command reply processor to execute and perform the corresponding socket write operation. When the command reply is sent, the server disassociates the command reply processor from the AE_WAITABLE event of the client socket.

5. Event instance of client-server connection completed at one time

First, the Redis client initiates a connection to the server, then the listening socket will generate an AE_READABEL event, trigger the connection reply processor to execute, the processor will reply to the connection request from the client, then create the client socket, as well as the client state, and associate the AE_READABEL event of the client socket with the command request processor so that the client can send a command request to the master server.

Then suppose the client sends a command request to the master server, then the client socket will generate an AE_READABEL event that causes the command to request the processor to execute, which reads the client's command and then passes it to the associated program to execute.

Executing the command will generate a corresponding command reply, and in order to send this command reply back to the client, the server will associate the AE_WAITABLE event with the command reply processor. When the client tries to read the command reply, the client generates an AE_WAITABLE event, which triggers the command reply processor to execute. When the command reply processor writes the command reply full server to the socket, the server disassociates the AE_WAITABLE event of the client socket from the command reply processor execution.

2. Time events 1. Composition of time events

Id

The server creates a globally unique ID for time events. The number of ID increases sequentially from small to large.

When

UNIX timestamp with millisecond accuracy, recording the arrival time of time events.

TimeProc

Time event handler, a function. When the time event arrives, the server invokes the appropriate processor to handle the event.

Whether a time event is a timing event or a periodic event depends on the return value of the time event handler. If the event handler returns ae.h/AE_NOMORE, then the event is a timing event, which is deleted after it arrives once, and then no longer arrives. If the event handler returns an integer value that is not AE_NOMORE, then the event is a periodic event. When a time event arrives, the server updates the when property of the event according to the return value of the event handler, so that the event arrives again after a period of time, and keeps updating and running in this way.

Realize

The server puts all the time events in an unordered linked list (the unordered is not the id field, but the when field, so it traverses the real linked list with each execution. Whenever the time event executor runs, it traverses the entire linked list, finds all events that have arrived, and invokes the appropriate event handler

It should be noted here that although it is an unordered linked list, the length of the linked list will not be very long. In normal mode, the Redis server only uses one serverCron time event, so this place is reduced to the role of a pointer, while in benchmark mode, the server only uses two time events, so the impact of full traversal on performance can be ignored.

ServerCron function

A continuously running Redis server needs to check and adjust its resources and status periodically to ensure that the server can run stably for a long time. These periodic operations are performed by the redis.c/serverCron function, and its main tasks include:

Update all kinds of statistics of the server, such as time, memory footprint, database occupancy, etc.

Clean up expired key-value pairs in the database.

Close and clean up clients with failed connections.

Try an AOF or RDB persistence operation.

If the server is the master server, periodically synchronize the slave server

If you are in cluster mode, perform regular synchronization and connectivity tests on the cluster.

Scheduling and execution of events

Because there are both file events and time events in the server, the server must schedule these two events to decide when to handle file events and when to handle time events. and how much time it takes to deal with them, and so on.

The pseudo code for the process is as follows:

Def aeProcessEvents (): # get the time of arrival closest to the current time event tem_event = aeSearchNearestTimer () # calculate how many seconds until the event arrived in the previous step remaind_ms = time_event.when-unix_ts_now () # if the event has arrived, the value of remaind_ms may be negative Set to 0 remaind_ms = max (remaind_ms, 0) # Block and wait for the file event to be generated. The maximum blocking time is determined by the timeval structure. # if the value of remaind_ms is 0, it will be returned immediately after the aeAPiPoll call Do not block aeApiPoll (timeval) # handle all generated file events processFileEvents () # handle all arrived time events proccessTimeEvents ()

Scheduling and execution rules for events:

1) the maximum blocking time of the aeApiPoll function is determined by the time event whose arrival time is closest to the current time. This method can not only avoid frequent polling (busy waiting) of time events by the server, but also ensure that the aeApiPoll function will not block for too long.

2) because the file event is random, if no time event arrives after waiting for and processing a file event, the server will wait and process the file event again. With the continuous execution of the file event, the time will gradually approach to the arrival time set by the time event, and finally arrive at the arrival time, at which time the server can start to deal with the arrival time event.

3) the processing of file events and time events is executed synchronously, orderly and atomically, and the server will not interrupt event processing or preempt events, so whether it is the processor of file events or the handlers of time events, they will try their best to reduce the blocking time of the program and actively relinquish the execution power when necessary, thus reducing the possibility of event hunger. For example, when a command reply processor sends a command reply writer to a client socket, if the number of bytes of the writer exceeds a preset constant, the command reply processor will actively use break to jump out of the write loop and save the rest of the data for next time; in addition, time events will also put very time-consuming persistence operations to the child thread or child process execution.

4) because time events are executed after file events, and there is no preemption between events, the actual processing time of time events is usually a little later than the arrival time set by time events.

There is a cooperative relationship between file events and time events, and the server takes turns to handle these two events, and there is no preemption in the process of handling the events. The actual processing time of time events is usually later than the set arrival time.

These are all the contents of the article "what are redis file events and time events". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

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.