Redis design and implementation-Client server and events

Events

2. Redis server is event-driven and events are divided into file events and time events
• The file event is that the server connects to the client through the socket, and the communication between the two generates the corresponding file event, and the server listens and handles these events to complete the network operation;
• A time event refers to the timing operation of a Redis server
4. Redis's reactor-mode-based file event handlers run single-threaded and use an I/O multiplexing program to listen to multiple sockets and correlate different event handlers for sockets based on the tasks currently performed by the socket. ；
6. The file event handler consists of four parts:
• Sockets
• I/O multiplexing program: Listen to multiple socket generated file events and put into a queue, and then in an orderly synchronization, each time a socket to generate the corresponding event socket to the file event dispatcher, the event processor after processing and then transfer the next;
• File Event Dispatcher: Receives the socket from the I/O multiplexing program and invokes the appropriate event handler based on the type of event generated by the socket;
• Event handler: Handles specific events. such as command requests, replies, connection answers, and so on.
8. If a socket is readable and writable, the server reads and writes it first.
10. Time events are divided into timed events and periodic events, and a time event has 3 attributes: Global Unique ID, arrival time when, event handler Timeproc;
12. The server places all time events in an unordered list, traversing the list whenever the time event executor runs, looking for events that have arrived and invoking the appropriate event handlers.
14. The Redis server waits for a file event to be processed and checks whether there are currently any time events that can be processed, the processing of which is synchronized with an ordered atom, and no intermediate interrupt event processing is not preempted, so each event handler should minimize the blocking time. For example, write bytes to the super-preset constant size, the command server will actively use break to jump out of the write loop and leave the rest of the data for the next write.

Above text from Dimmacro, reprint please explain source:http://www.cnblogs.com/dimmacro/

Client

2. Each client that establishes a connection, the service side will establish the corresponding redisclient structure, and append to the Redisserver data organization to save the client's clients linked list;
4. There are three types of clients generally:
• Normal connection to the server through the Connect function, and has a connection event handler created;
• LUA scripting pseudo-client, created at server initialization and persisted until the server is shut down;
• AOF pseudo-client, used when loading aof, will be closed when loading is complete
6. Some important properties and descriptions in the Redisclient data structure:
• int FD: Represents the client type, 1 indicates a pseudo-client, and a greater than 1 represents a normal client;
• Name: Client name, needs to be set up using the Clients setname command;
• Flags: The current state of the client, such as the primary server, executing transactions, blocking and many other States;
• SDS QUERYBUF: The input buffer is used to save the command request sent by the client, the maximum can not exceed 1GB, otherwise the server will shut down the client;
• RobJ **argv: Commands and arguments that the server obtains after parsing a command request, Argv[0] represents a command, and other items represent parameters
• struct Rediscommand *cmd: Save the command corresponding to the implementation function, the required parameters, the total number of command execution and consumption time, etc.;
• The output buffer to save the result of the execution of the command, a fixed size for a short reply, a maximum of 16KB, a variable size for large data volume of the reply;
• int authenticated: Authentication result, 0 means failed, 1 means through
• CTime: Timestamp the client was created;
• Lastinteraction: The last time the client interacts with the service area;
• Obuf_soft_limit_reached_time: The first time the output buffer reaches the soft limit
8. The client is closed in several situations:
• The client process exits or is killed;
• The client sent an illegal command request and was shut down by the server;
• When the client is in a non-master server state, or the subscription status is blocked, and the time of timeout setting is exceeded, it is closed by the service side;
• Send command request more than 1GB;
• The command reply exceeds the hard limit of the output buffer, or exceeds the size of the soft limit within the soft limit time

Above text from Dimmacro, reprint please explain source:http://www.cnblogs.com/dimmacro/

Service Side

2. The process by which the Redis server initiates initialization:
• The Redis.c/initserverconfig function initializes the server state structure Server (which is an instance variable of the struct Redisserver type) and sets the default values for each property in the structure. General properties such as setting the server's run ID, run frequency, profile path, run schema, default port number, persistence condition, LRU clock, and create command table;
• Load the user given configuration parameters and configuration files, and update the server corresponding to the default properties;
• Call the Initserver function to allocate memory for the following data structures and set or manage the initialization values for them as needed:
• Server.clients list: Records the state structure of all clients connected to the server;
• Serer.db array: contains all databases;
• Save the Server.pubsub_channels Dictionary of the Channel subscription information and the Server.pubsub_patterns linked list of the saved mode subscription information;
• Server.lua: LUA environment for executing LUA scripts;
• Server.slowlog: Save slow query log
• Initserver also makes some very important settings, including:
• Set process signal processor for server;
• Create common shared objects such as "OK", "ERR", to avoid duplicate creation;
• Open the server listening port, for listening Socket association answer event handler, waiting for the server to receive the client connection when it is formally running;
• Open or create a new aof file to prepare for the aof write;
• Initializing the back-end I/O module (bio) for future I/O preparedness
• Load an RDB or aof file to restore the database state
• print ready-to-accept connections on port XXX and start receiving client connection requests and processing;
4. The client sends the request command to the full execution process that gets the reply processing:
• The client converts the Redis command into a protocol format and sends it to the server;
• The server reads the protocol format data and saves the input buffer to the client state;
• The data of input buffer is jinx analyzed, and the number of commands, parameters and parameters are extracted.
• Find the corresponding Rediscommand object in the command table according to the command;
• Preparation and implementation of the test before: including the number of parameters, user identity, server memory consumption, subscription check, the server is loading, whether to open the monitor, etc.;
• Executes the method in the Rediscommand and saves the reply information to the output buffer of the client state;
• After the execution of the detection work: whether to increase to slow query, update command time and counter, according to the need to write to aof, the necessary commands propagated to the slave server;
• Sends the reply data in the input buffer to the client
6. The Servercon function is executed every 100 milliseconds by default and is responsible for managing server resources, primarily by doing the following:
• Update server time cache unixtime, mstime;
• Update the LRU clock;
• Update the number of times the server executes commands per second;
• Update server memory peak record;
• Processing off the sigterm signal, mainly to do some persistence before closing;
• Manage client resources, including checking if the connection between the client and the server is timed out, and the client buffers are released too long;
• Manage database resources, call the Databasecron function to check some databases, delete expired keys, and shrink the dictionary as needed;
• Execution of bgrewriteaof delayed due to bgsave;
• Check the running state of the persistence operation, including whether it is complete, whether it is in progress, or whether it needs to be persisted, etc.
• If AoF is turned on, the contents of the AOF buffer are written to the aof file;
• Turn off the output buffer size beyond the displayed client;
• Increase the Cronloops counter value that records the number of Servercron function executions

Above text from Dimmacro, reprint please explain source:http://www.cnblogs.com/dimmacro/

Redis design and implementation-Client server and events