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

This article mainly explains "how to understand epoll and file events in Redis". The content in 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 "how to understand epoll and file events in Redis".

Event driven

The Redis server is an event driver, divided into file events and time events

File events: readable and writable events for socket

Scheduled task

They are all encapsulated in aeEventLoop structures

Typedef struct aeEventLoop {int stop; / / identifies whether the event ends the aeFileEvent * events; / / file event array, stores the registered file event aeFireEvent * fired; / / stores the triggered file event aeTimeEvent * timteEventHead; / / the linked list formed by multiple time events void * apidata; / / aeBeforeSleepProc * beforesleep of the model / / execute aeBeforeSleepProc * aftersleep; / / execute} aeEventLoop after the process is awakened

The event driver actually waits for the event to occur through the while/for loop.

While (! EventLoop- > stop) {if (eventLoop- > beforesleep! = NULL) eventLoop- > beforesleep (eventLoop) aeProcessEvents (eventLoop, AE_ALL_EVENTS | AE_CALL_AFTER_SLEEP);}

AeProcessEvents is the main function for event handling

Epoll

The Redis client interacts with the server through TCP socket, and the file event refers to the readable and writable event of the socket. The non-blocking mode is generally used, and the related Icano multiplexers include select/epoll/kqueue, etc., and different operating systems have different implementations.

Take epoll, for example, which is a solution proposed by the Linux kernel to handle a large number of concurrent network connections. Epoll provides 3 API

Epoll_create creates an epoll-specific file descriptor for subsequent epoll-related API calls

Int epoll_create (int size) / / size tells the kernel program the number of network connections it expects to register. After Linux 2.6.8, the kernel dynamically allocates / / the return parameter is an epoll-specific file descriptor.

The epoll_ctl function registers, modifies or deletes events to be monitored with epoll

Int epoll_ctl (int epfd, int op, int fd, struct epoll_event * event) / / the epoll file descriptor / / op operation type returned by the epfd function epoll_create: registration event; EPOLL_CTL_MOD: modify network connection event; EPOLL_CTL_DEL: delete event / / fd network connection socket file descriptor / / events to be monitored by event

The epoll_wait function blocks the process until an event occurs on several monitored network connections.

The epoll file descriptor / / epoll_event returned by the int epoll_wait (int epfd, struct epoll_event * event, int maxevents, int timeout) / epfd function epoll_create is used as an output parameter to return the maximum number of events that can be handled by the triggered event array / / maxevents each time / / the timeout epoll_wait function blocks the timeout. If no event occurs after the timeout time, the function will no longer block the direct return. When timeout equals 0, the function returns immediately. When timeout equals-1, the function blocks until there is an event. File event occurs.

Reids does not directly use the API of epoll, but supports four Imax O multiplexing models at the same time, and encapsulates the API of these models. Then, in the compilation phase, check the Icano multiplexing model supported by the operating system, and decide which model to reuse according to the policy.

Or take epoll as an example, Redis is encapsulated as follows

/ / corresponding epoll_createstatic int aeApiCreate (aeEventLoop * eventLoop) / / corresponding epoll_ctl add event static int aeApiAddEvent (aeEventLoop * eventLoop, int fd, int mask) / / corresponding epoll_ctl deletion event static int aeApiDelEvent (aeEventLoop * eventLoop, int fd, int delmask) / / corresponding epoll_waitstatic int aeApiPool (aeEventLoop * eventLoop, struct timeval * tvp)

Recall that the eventLoop structure mentioned above has a member apidata that points to four I fired O multiplexed model objects; events stores an array of events that need to be monitored, using the socket file descriptor as an array index access element; and fired stores an array of triggered events.

The structure of the file event is defined as follows:

Typedef struct aeFileEvent {int mask; / / file event type AE_READABLE readable event; AE_WRITEABLE writable event aeFileProc * rfileProc; / / read event handler function pointer aeFileProc * wfileProc; / / write event handler function pointer void * clientData; / / points to the corresponding client object} aeFileEvent

Take a look at the implementation of the create file event aeCreateFileEvent

Int aeCreateFileEvent (aeEventLoop * eventLoop, int fd, int mask, aeFileProc * proc, void * clientData) {aeFileEvent * fe = & eventLoop- > evnts [fd]; if (aeApiAddEvent (eventLoop, fd, mask) =-1) return AE_ERR; fe- > mask | = mask; if (mask & AE_READABLE) fe- > rfileProc = proc; if (mask & AE_WRITABLE) fe- > wfileProc = proc; fe- > clientData = clientData Return AE_OK;}

The Redis server handles transactions by creating various file events, such as:

Create socket and listen at startup, waiting for client connection

AeCreateFileEvent (server.el, server.ipfd [j], AE_READABLE, acceptTcpHandler, NULL)

After the client establishes a socket connection with the server, the server waits for a command request from the client

AeCreateFileEvent (server.el, fd, AE_READABLLE, readQueryFromClient, c)

After the server has processed the command request from the client, the command reply will be temporarily cached in the buf buffer of the client structure, and the command reply will not be sent to the client until the writable event of the client file descriptor occurs.

AeCreateFileEvent (server.el, c-> fd, AE_READABLLE, sendReplyToClient, c)

The execution of all events in Redis is controlled by the aeProcessEvents function. Among them, the execution file event will have a blocking condition (epoll_wait). If the blocking event is too long, it will hinder the execution of the time event (timing). In order to avoid this situation, the waiting time passed in when the file event is implemented is calculated by calculating the earliest time event.

Int aeProcessEvents (aeEventLoop * eventLoop, int flags) {shortest = aeSearchNearestTimer (eventLoop); long long ms = (shortest- > when_sec-now_sec) * 1000 +\ shortest- > when_ms-now_ms; / / blocking event occurrence numevents = aeApiPoll (eventLoop, ms); for (jambo0; j

Events [eventLoop-> fired [j]] .fd]; / handle file events, that is, execute rfileProc or wfileProc} / / handle time events processed + = processTimeEvents (eventLoop) according to type;} summarize

Now let's take a look at the flow of the corresponding commands on the Redis server as a whole.

The aeMain function schedules and executes file events and time events by calling the aeProcessEvents function. Event-related information is recorded in aeEventLoop. First, the execution interval n of the shortest time event is obtained through the aeSearchNearestTimer function, then the aeApiPoll function is called to get the listening socket, and finally the event handling functions rfileProc and wfileProc corresponding to the socket direction are executed, and finally the time event function processTimeEvents is executed.

A complete client-server connection event:

The device listens to the AE_READABLE event of the kit word. when the client sends a connection request and produces an AE_READABLE event, the server will reply to the client's connection request, combining the AE_READABLE event of the client socket with the command request handler (aeFileProc), and the client can send a command request to the server.

The client sends a command request to the server, and the client socket will generate an AE_READABLE event, which will trigger the command processor to execute, and the execution of the command will generate a corresponding command reply. The server will associate the AE_WRITABLE event of the client socket with the command reply handler (aeFileProc).

When the client tries to read the command reply, the client socket generates 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 contacts the association between the AE_WRITABLE event of the client socket and the command reply handler function (aeFileProc).

Thank you for your reading, the above is the content of "how to understand epoll and file events in Redis". After the study of this article, I believe you have a deeper understanding of how to understand epoll and file events in Redis. 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.