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

This article mainly explains "what is Redis event and server". The content of the explanation 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 is Redis event and server".

Redis events and server events

Redis is single-threaded, but very fast, mainly because it is event-based and an event driver, and anyone who knows NIO should know this way.

The Redis server needs to handle two types of events.

File event (file event): the Redis server connects to the client through sockets, and the * * file event is the server's abstraction of socket operations. * * the communication between the server and the client produces corresponding file events, and the server completes a series of network communication operations by listening and processing these events.

Time event (file event): some operations in the Redis server (such as the serverCron function) need to be performed at a given point in time, and the time event is the server's abstraction of such timing operations.

File event

Redis developed its own network event handler based on the Reactor pattern, and each processor is called a file time processor (file event handler):

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 sockets according to the current new tasks of the socket.

When the listening socket is ready for connection reply (accept), read (read), write (write), close (close) and other operations, the file event corresponding to the operation will be generated. When this is a file, the processor will call the event handler of the associated number before the socket to handle these events.

Constitute

The file time processor consists of four parts, namely sockets. IMAGO multiplexer, file event distributor (dispatcher) and event handler.

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

The Iswap O multiplexer listens for multiple sockets and transmits time-generating sockets to the file event dispatcher. The Icano multiplexer always puts all time-generating sockets into a queue, and then sends sockets to the file time dispenser one at a time in an orderly, synchronous manner through this queue.

The file event distributor receives the socket from the Iram O multiplexer and calls the corresponding event handler according to the time type generated by the socket.

The server associates different event handlers for sockets that perform different tasks, and these handlers are functions that define what the server should do when it occurs at a certain time.

Tips: all the functions of Redis's iMago multiplexing program are achieved by wrapping the common select,epoll,evport and kqueue iWeibo multiplexing libraries, and the same API is implemented for each multiplexing library, so the underlying layer is interchangeable. When compiling, it will automatically select the highest-performance Imax O multiplexing function library in the system as the underlying implementation.

Example of client initiating a request:

Time event

There are also two types of time events for Redis:

Timed event: causes a program to execute once after a specified time.

Periodic events: have a program execute at specified intervals.

All time events are placed in an unordered linked list, and whenever the event executor runs, it traverses the entire list, finds all time events that have arrived, and calls the corresponding event handler. (disorder here refers to the disorder of the arrival time of the event.)

ServerCron function

The serverCron function is responsible for checking and adjusting the resources and status of Redis on a regular basis. The main tasks include:

Update all kinds of statistics of the server, such as time, memory footprint, database footprint, 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.

In the case of master, the slave service is synchronized periodically.

If you are in cluster, do regular synchronization and connectivity testing on the cluster.

The default execution time of this function is 10 times per second, which can be changed by adjusting the value of the configuration hz, which represents the number of times per second.

Hz 10

Update server time cache

There are many functions in the Redis server to obtain the current time of the system, and each acquisition requires a system call. In order to reduce the number of system calls, the unixtime attribute and mstime in the server state are used as the current time cache.

Struct redisServer {/ /... / / the current UNIX timestamp of the system saving the second progress time_t unixtime; / / the current UNIX timestamp of the system saving millisecond progress long long mstime; / /...}

Because the function runs 10 times per second, once every 100 milliseconds, the accuracy of these two properties is not high.

The server will only print the log, refine the server's LRU clock, decide whether to perform persistence tasks, calculate the server online time and other functions that do not require high time accuracy.

For functions that require high precision time such as setting the expiration time for keys and adding slow query logs, the server still executes the system call again to get the most accurate system current time.

Update the LRU clock

The lruclock property in the server state holds the server's LRU always, which is also a kind of server time cache and is used to calculate the length of idling of the object.

Struct redisServer {/ /... / / updates unsigned lruclock:22; / /...} by default every second.

Each redis object has a lru property, which holds the last time the object was accessed by a command.

Idle time = lruclock-lru.

Command:

OBJECT IDLETIME key: view the length of idling of objects INFO server: you can output the value of lruclock in server

Update server executes commands per second

Redis > INFO stats# Stats...instantaneous_ops_per_sec: 558.

The above command results show that the server processed about 558 commands in the last second.

Update server memory peak records

The server stat_peak_memory property records the peak amount of server memory.

Redis > INFO memory# Memory...used_memory_peak:6180016used_memory_peak_human:5.89M...

The above command looks at the peak memory size.

Processing SIGTERM signal

When the server is started, Redis associates a processor (a function) for the process's SIGTERM signal, which is responsible for turning on the shutdown_asap identity of the server state when the server receives a SIGTERM signal.

Each time the serverCron function runs, the program checks the shutdown_asap property of the server state. If the value is 1, the server will persist the RDB first, and then shut down the server.

Manage client resources

Mainly check the client:

If the connection between the client and the server has timed out, release the client.

If the client's input buffer exceeds a certain length after the last command request, the program may release the client's current input buffer and recreate a default size input buffer. this prevents the client from consuming too much memory in your input buffer.

Manage database resources

This section mainly examines a part of the database in the server, deletes the expiration key, and shrinks the dictionary (hash table) if necessary.

Execution of delayed BGREWRTEAOF

During the execution of the BGSAVE command by the server, if the client sends the BGREWRITEAOF command to the server, the server will delay the execution of the BGREWRITEAOF command until after the execution of the BGSAVE command.

The server's aof_rewrite_scheduled property records whether the BGREWRITEAOF command is delayed.

A struct redisServer {/ /... / value of 1 indicates that a BGREWRITEAOF command has been delayed int aof_rewrite_scheduled; / /...}

When the serverCron command runs, it checks whether the BGSAVE and BGREWRITEAOF commands are executed. If neither is executed, then check the aof_rewrite_scheduled property of the server. If the value is 1, then execute the delayed BGREWRITEAOF command.

Check the running status of the persistence operation

The server status uses the rdb_child_pid and aof_child_pid attributes to record the child process ID that executes the BGSAVE and BGREWRITEAOF commands, which can also be used to check whether the corresponding command is being executed:

Struct redisServer {/ /... / record the child process executing the BGSAVE command ID / / if not executed, the value is-1 pid_t rdb_child_pid; / / record the child process executing the BGREWRITEAOF command ID / / if not executed, the value is-1 pid_t aof_child_pid; / /.}

Each time the serverCron function is executed, the program checks the values of these two properties, and as long as one of the attributes is not-1, the program checks whether the child process has a signal to the server process (calling other functions).

If a signal arrives, it means that the new RDB file has been generated or the AOF file has been rewritten, and the server needs to take follow-up actions, such as replacing the old AOF file with the new AOF.

If no signal arrives, the persistence operation is not completed and the program does not take action.

If the values of both properties are-1, do three checks:

Check to see if any BGREWRITEAOF commands are delayed, and if so, start executing the command.

Check whether the auto-save condition is met, and if so, and the server is not currently performing any other persistence operation, then start a new BGSAVE operation (because the previous check may trigger a new BGREWRITEAOF, during all this check, the program will reconfirm whether the persistence operation is already being performed).

Check that the AOF rewrite conditions set by the server are met, and if the conditions are met and the server does not perform other persistence operations, then a new BGREWRITEAOF operation is started (also confirmed one by one, as the previous two checks may cause new persistence operations).

Illustration:

Writes the contents of the AOF buffer to the AOF file

If the server has AOF persistence enabled and there is still data to be written in the AOF buffer, then the serverCron function will call the appropriate program to write the contents of the AOF buffer to the AOF file.

Shut down the asynchronous client

In this step, the server closes clients whose output buffer size exceeds the limit.

The input buffer of the client is used to vinegar the command requests sent by your client:

Typedef struct redisClient {/ /... Sds querybuf; / /...}

What is stored in this buffer is the value of the protocol.

The value of set mKey mValuequerybuf is * 3\ r\ nroom3\ r\ nSET\ r\ nroom4\ r\ nmKey\ r\ nroom6\ r\ nmValue\ r\ n

The size of the input buffer will be dynamically reduced or expanded according to the content, but its value cannot exceed 1G, otherwise the server will shut down the client.

Increase the value of the cronloops counter

The cronloops property of the server state records the number of times the serverCron function is executed

If the struct redisServer {/ /... / / serverCron function is not executed once, the value is incremented by 1 int cronloops; / /.}

At present, the only function of this property in the server is to implement the function of executing the specified code once without executing N times in the replication module.

If (cronloops% n = = 0) {/ / specifies the code, which should be something the server handles, how often is the server command request process handled

When a command is requested, when the client enters a command, the client converts the command into a protocol and then sends the protocol content to the server.

Protocol format * CRLF $CRLF CR LF...$ CRLF CRLF Note: CRLF is a newline\ r\ nsocket sending protocol

Let's try it first:

Cmd:set mKey mValueprotocal:*3\ r\ nroom3\ r\ nSET\ r\ nroom4\ r\ nmKey\ r\ nroom6\ r\ nmValue\ r\ n

Then we use java socket directly to send the protocol to the server.

Public static void main (String [] args) throws Exception {Socket socket = new Socket ("192.168.2.11", 16379); / / get the output stream and write data OutputStream outputStream = socket.getOutputStream () to socket; PrintWriter printWriter = new PrintWriter (outputStream); printWriter.print ("* 3\ r\ nroom3\ r\ nSET\ r\ nroom4\ r\ nmKey\ r\ nroom6\ r\ nmValue\ r\ n"); printWriter.flush () / / close the output stream socket.shutdownOutput (); / / read the socket data returned by the server InputStream inputStream = socket.getInputStream (); InputStreamReader inputStreamReader = new InputStreamReader (inputStream); BufferedReader bufferedReader = new BufferedReader (inputStreamReader); String info = ""; String temp = null; while ((temp = bufferedReader.readLine ())! = null) {info + = temp System.out.println ("client receives server sending message:" + info);} / / closes the corresponding resource bufferedReader.close (); inputStream.close (); printWriter.close (); outputStream.close (); socket.close ();}

Execution result:

The client receives the message sent by the server: + OKProcess finished with exit code 0

Check if there is a value on the server:

Redis > get mKey "mValue" server initialization process initializes server state

The first step is to create an instance variable of type strct redisServer as the server state and set default values for each property in the structure. It mainly includes the following parts:

Set the running ID of the server.

Sets the default running frequency of the server.

Sets the default profile path for the server.

Sets the running architecture of the server.

Sets the default port number for the server.

Set the default RDB persistence conditions and AOF persistence conditions for the server.

Initialize the server's LRU clock.

Create a command table.

After initialization, move on to the next step, loading the configuration item.

Load configuration item

When starting the server, the user can modify the default configuration of the server by giving configuration parameters or by specifying a configuration file, such as

Redis-server-port 16379

Then we modify the running port number of the server by giving the configuration parameters, which can also be configured in the configuration file.

If the user sets new values for some properties, the server updates the corresponding properties with the user-specified values, or if no new values are set, with the default values initialized in the previous step.

After loading the configuration, proceed to the next step to initialize the server data structure.

Initialize the server data structure

In the first step, the server only creates one data structure of the command table. In addition to the command table, the server also includes other data structures, such as server.clients linked list, server.db array and so on.

In addition to initializing these data structures, there are some important setup operations that need to be done, including:

Set up a process signal processor for the server.

Create a shared object, such as a string object that contains "OK" and "ERR" replies.

Open the listening port of the server and do not listen on the socket connection response processor, waiting for the server to accept the connection from the client when the server is officially running.

Create a time event for the serverCron function and wait for the serverCron function to be executed when the server is officially running.

If AOF persistence is turned on, open an existing AOF file, and if it does not exist, create a new AOF file that is not ready for AOF writes.

Initialize the server's background Iamp O module to prepare for future Imax O operations.

After this step is completed, proceed to the next step, restore the database state.

Restore database state

After initializing the completion rate server variable, the server also needs to load the RDB file or AOF file and restore the database state of the server according to the contents of the file record. RDB files are not as priority as AOF files! If there is an AOF file, the RDB file will not be used.

If AOF persistence is enabled, the server uses AOF files to restore the database state.

If AOF persistence is not enabled, use the RDB file to restore the database state.

After the database state is restored, the final step begins to execute the event loop.

Execute event loop

This is the last step of initialization, and the server begins to execute the server's event loop (loop). At this time, the initialization of the server is complete, and you can begin to accept connection requests from the client and process command requests from the client.

Thank you for reading, the above is the content of "what is Redis event and server". After the study of this article, I believe you have a deeper understanding of what is Redis event and server, 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.