Redis network communication and connection mechanism learning

Read this article.

Http://blog.nosqlfan.com/html/4153.html

The content described herein is based on Redis2.6 and above.

Note: You can view server version information and many other information on the client through the info command.

> Info
# Server
redis_version:3.2.3

This paper mainly introduces some internal implementation mechanisms of Redis processing client connection, including connection processing, timeout , buffer and so on.

Establishment of a connection

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 non-blocking mode because Redis uses a non-blocking multiplexing model for network event processing.
Nagle algorithm
Then create a readable file event to listen to the data sent by this client socket

The above mentioned the Nagle algorithm, see here basic can be (http://baike.baidu.com/view/2468335.htm)

The Nagle algorithm is designed to send large chunks of data as much as possible to avoid flooding the network with small chunks of data. The basic definition of the Nagle algorithm is that at any moment, there can be at most one small segment that is not recognized. The so-called "small segment" refers to a data block smaller than the MSS size,
The so-called "unconfirmed" refers to a data block sent out after it has not received an ACK from the other party to confirm that the data has been received. The Nagle algorithm only allows a packet that is not ACK to exist in the network, it does not control the size of the packet, so it is actually an extended stop-Wait for the protocol, except that it is based on packet stop-and so on, rather than byte-based stop-and so on. Tcp_nodelay option By default, the sending data takes the Nagle algorithm. This improves network throughput, but is less real-time, and is not allowed in some highly interactive applications.
Use the Tcp_nodelay option to suppress the Nagle algorithm. Because Nagle can sometimes be slow: because TCP/There is not only Nagle algorithm in IP, but also a TCP acknowledgement delay mechanism. When the server side receives the data, it does not immediately send an ACK to the client side,
Instead, the ACK is sent for a period of time (assuming T), and it expects the server to send a response data to the client side within the T-time so that the ACK can be sent with the reply data.
It's like answering data with an ACK in the past. Tcp_cork options So-called CORK is the meaning of the plug, the image of the understanding is to use the CORK to plug the connection, so that the data first not sent out, wait until the plug after pulling out.
When this option is set, the kernel tries to stitch the small packet into a large packet (an MTU) and send it out, of course, after a certain amount of time (typically 200ms, the value remains to be confirmed),
The existing data must also be sent when the kernel is still not combined into an MTU. The Nagle algorithm differs from the Cork algorithm Nagle algorithm is concerned with the network congestion problem, as long as all the ACK back to the contract. Avoid the network because too many small packets (the proportion of the protocol header is very large) and congestion (in fact, to avoid too many packets, it does not care about the size of the package). And the cork algorithm is to improve the utilization of the network, so that the total number of protocol head occupies as small as possible (it is concerned about the size of the packet, hoping to make small packets into a large package). They do not have the same focus. At the user control level, the Nagle algorithm is completely not controlled by the user socket, you can simply set the Tcp_nodelay and disable it,
The cork algorithm is also enabled or disabled by setting or clearing tcp_cork. 

Then check the maximum number of connections:

When the client connection is initialized, Redis looks at the current number of connections, then compares the configured maxclients values, and if the current number of connections has reached the maximum number of connections maxclients,
That means the connection is no longer acceptable, and Redis returns a connection error directly to the client and shuts down the connection immediately.

Note: First establish the connection, then check and then disconnect. Increase the concurrency amount.

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 continuously sending too many commands,
Situations that cause requests from other clients to be processed for a long time.
Of course, when the read () call is completed, 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.

About the maximum number of connections maxclients

In Redis2. 4  10000, you can also modify this value in the redis.conf.

Redis also takes care of the system itself, which limits the number of file descriptors that the process uses. 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.

100000 [41422:33.179set100032 
10112.

Modify Soft Limit

100000 if  is  -W fs.file-max=100000

Output Buffer size limit

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 limits, there are two ways to restrict:

One is the size limit, when a client's buffer exceeds a certain large hour, and the client connection is shut down directly
The other is that when a client's buffer is too large for a period of time, it also shuts down the client connection directly

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.

This also learns that the client of Redis is divided into three kinds: normal client, pub/sub client, slave client.

Input buffer size limit

Compare violence when the client transmits a request that is larger than 1G, the server shuts down the connection directly. 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 important to note that the timeout setting only works for normal clients, and for Pub/Sub clients, the long-term idle state is normal .
In addition, 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.
Part of each check. 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

In fact, it is the command associated with the client connection. The Redis CLIENT command enables three functions: check the status of the connection, kill a connection, and set a name for the connection.

For example, the following command (actual experiment):

>Client Listid=2Addr=10.117.146.21:55330Fd=6Name= age=1759348idle=0Flags=s db=0sub=0psub=0multi=-1qbuf=0qbuf- Free=0Obl=0Oll=0omem=0Events=r cmd=Replconfid= *Addr=10.117.146.21:19654Fd=5Name= age=1422idle=0Flags=n db=0sub=0psub=0multi=-1qbuf=0qbuf- Free=32768Obl=0Oll=0omem=0Events=r cmd=client

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

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, the default is empty, you can set the age by client SETNAME: The number of seconds that clients survive idle: Client Idle seconds Flags: The type of the client (N represents the normal client, more types see http://redis.io/commands/client-list)omem: Output buffer size cmd: Last executed command name

Once you have obtained the list of clients through the above command, you can kill the specified connection by using the client Kill command. The parameter of CLIENT KILL is the addr value above.

As mentioned above, client SETNAME and client GETNAME can be used to set a name for a connection.

Finish.

Redis network communication and connection mechanism learning