How the Redis basics ———— handle Client connections

Redis Connection Setup

Redis receives a connection from a client by listening to a TCP port or a Unix socket, and when a connection is established, the following actions are performed within Redis: first, the client socket is set to nonblocking mode because Redis is in a network event The non-blocking multiplexing model used in processing. Then set the Tcp_nodelay property for this socket, disable the Nagle algorithm and then create a readable file event to listen to the data sent by this client socket when the client connection is initialized,

Will look at the current number of connections, and then compare the configured maxclients value, if the current number of connections has reached the maximum number of connections maxclients, then the connection can no longer receive, Redis will directly return the client a connection error, and immediately shut down the connection.

Service-side processing order

If more than one client connects to Redis and sends commands to REDIS, which client's request will the Redis server handle first? The answer is not sure, mainly related to two factors, one is the client corresponding to the size of the socket corresponding to the number, and the second is the Kernal report the order of the various client events. The steps for Redis to process data from a client are as follows: It calls the socket of the triggering event once read (), read only once (rather than reading the message on the socket), to prevent a particular client from sending too many commands. Situations that cause requests from other clients to be processed for a long time.

Once the call is complete, it will be executed in one order, regardless of the number of commands it contains. This guarantees a fair treatment of the individual client commands.

Redis Maximum number of connections maxclients

In Redis2.4, the maximum number of connections is directly hardcoded in the code, and in version 2.6 this value becomes configurable. The default value for MaxClients is 10000, and you can modify the value in redis.conf. Of course, this value is only a redis wishful thinking value, and Redis also takes care of the system itself to limit the number of file descriptors used by the process. At startup, Redis checks the system's soft limit to see the maximum number of open file descriptors. If the number set by the system is less than the maximum number of connections we wish to add 32, then this maxclients setting will not work and Redis will set this value as required by the system. (plus 32 is because a maximum of 32 file descriptors are used inside the Redis, so the connection can use the equivalent of all the available descriptors minus 32). When this occurs (when MaxClients is not working), the Redis startup process will have a corresponding log record. For example, the following command wants to set the maximum number of clients to 100000, so Redis needs to 100000+32 a file descriptor, and the system's maximum file description symbol is set to 10144, so Redis can only set maxclients to 10144–32 = 10112.

–maxclients 100000 [41422] Jan 11:28:33.179 # Unable to set the max number of files limit to 100032 (Invalid argument), Setting the max clients configuration to 10112. So when you want to set the MaxClients value, it is best to modify your system settings, of course, develop a good habit of reading the log can also find this problem. The specific setup method depends on your personal needs, you can only modify the limit of this session, you can also directly through the SYSCTL to modify the system's default settings. such as: ULIMIT-SN 100000 # This would only work if hard limit is big enough. Sysctl-w fs.file-max=100000

output buffer size limit

For Redis output (that is, the return value of a command), its size is often not controllable and may be a simple command that can produce large volumes of return data. It is also possible that because there are too many execution commands, the rate at which the returned data is generated exceeds the rate that is sent to the client, which in turn generates a message heap, resulting in an increasing output buffer, consuming too much memory, and even causing the system to crash. So Redis set up some protection mechanisms to avoid this situation, these mechanisms for different kinds of clients, there are different output buffer size restrictions, there are two ways: one is the size limit, when a client's buffer exceeds a certain number of hours, directly shut down the client connection The other is that the client connection is also closed directly when a client's buffer takes up too much space for a period of time.

the policies for different clients are as follows

For normal clients, the limit is 0, which is unrestricted, because normal clients typically use a blocking message answering pattern, such as sending a request, waiting for a return, then sending a request, and then waiting for the return. This pattern usually does not cause the accumulation of output buffers to swell. For pub/sub clients, the size limit is 32m, and when the output buffer exceeds 32m, the connection is closed. The persistent limit is that when the client buffer size lasts more than 8m for 60 seconds, it can also cause the connection to close. For Slave clients, the size limit is 256m, and the persistent limit is to close the connection when the client buffer size lasts more than 64m for 60 seconds.

All three of the above rules are configurable. You can use CONFIG SET command or modify redis.conf

file to configure

Input buffer size limit Redis's limit on the size of the input buffer compared to brute force, the server shuts down the connection directly when the client transmits a request larger than 1G. This approach can effectively prevent some client or server-side bugs caused by the input buffer too large problem.

Client Timeout

For the current Redis version, the service side will not shut down long-term idle clients by default. But you can modify the default configuration to set the time-out you want. For example, if the client is over how long without interaction, it shuts down directly. Similarly, this can also be configured by using the Config SET command or by modifying the redis.conf file.

It is worth noting that the timeout setting only works for the normal client, and for the Pub/sub client, the long-term idle state is normal.

Also, the actual timeout may not be as accurate as it is set, because Redis does not use timers or rotation traversal methods to detect client timeouts, but rather to do so in an asymptotic manner, one at a time. So the result is that maybe you set the timeout to be 10s, but the actual execution time is 12s after the client is shut down.

CLIENT command

The Redis CLIENT command enables three functions: check the status of the connection, kill a connection, and set a name for the connection.

As the output of the above command shows, there are currently two client connections for this Redis, and each line represents a connected

Information: Addr: TCP Address of the client, including IP and port FD: Client connection socket corresponding file descriptor handle number name: The name of the connection, default is NULL, can be set through client SETNAME age: Number of seconds for clients to live idle: Client Idle seconds Flags: type of client (N = Normal client, more types see http://redis.io/commands/client-list) Omem: Output buffer size cmd: Last command name executed

How the Redis basics ———— handle Client connections