In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-03-26 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)05/31 Report--
This article is about how Redis handles client connections. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.
How Redis handles client connections this paper mainly introduces some internal implementation mechanisms of Redis dealing with client connections, including connection handling, timeout, buffer and so on. The following editor will explain how Redis handles client connections.
How does Redis handle client connections
Redis receives connections from clients by listening on a TCP port or Unix socket. When a connection is established, the following operations will be performed within Redis:
First, the client socket is set to non-blocking mode because Redis uses a non-blocking multiplexing model for network event handling.
Then set the TCP_NODELAY property for the socket to disable the Nagle algorithm
Then create a readable file event to listen to the data transmission of the client socket
When the client connection is initialized, Redis will check 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 be received. Redis will directly return a connection error to the client and close the connection immediately.
Server-side processing order
If multiple clients connect to Redis and all send commands to Redis, which client will the Redis server process first? In fact, the answer is uncertain, mainly related to two factors, one is the size of the number corresponding to the socket corresponding to the client, and the other is the sequence in which each client event is reported by kernal.
The steps for Redis to process data sent by a client are as follows:
It calls read () on the socket that triggers the event and reads it only once (rather than reading the message on the socket) to prevent requests from other clients from going unprocessed for a long time because one other client keeps sending too many commands.
Of course, when this read () call is complete, no matter how many commands it contains, it will be executed sequentially at one time. This ensures fair treatment of each client command.
About the maximum number of connections maxclients
In Redis2.4, the maximum number of connections is hard-coded directly in the code, but in version 2.6 this value becomes configurable. The default value for maxclients is 10000, and you can also modify this value in redis.conf.
Of course, this value is only a wishful thinking of Redis, and Redis also takes into account the system's own limit on 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 want plus 32, then the maxclients setting will not work, and Redis will set this value as required by the system. (add 32 because up to 32 file descriptors are used internally in Redis, so connections can use as many descriptors minus 32 as all available descriptors).
When this happens (if the maxclients setting does not work), there will be a corresponding log record during the startup of the Redis. For example, the following command wants to set the maximum number of clients to 100000, so Redis needs 1000 million 32 file descriptors, while the system's maximum file descriptor is set to 10144, so Redis can only set maxclients to 10144-32 = 10112.
$. / redis-server-- maxclients 100000
How does Redis handle client connections
[41422] 23 Jan 11 Invalid argument 2833. 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's best to change your system settings by the way. Of course, you can also find this problem by getting into the habit of reading logs.
The specific setting method depends on your personal needs. You can only modify the limits of this session, or you can modify the default settings of the system directly through sysctl. Such as:
Ulimit-Sn 100000 # This will only work if hard limit is big enough.
Sysctl-w fs.file-max=100000
Output buffer size limit
For the output of Redis (that is, the return value of a command), its size is often uncontrollable and may be a simple command that produces a large amount of returned data. In addition, it is also possible that due to the execution of too many commands, the rate of data returned exceeds the rate sent to the client, which will also result in message accumulation, resulting in larger and larger output buffers, taking up too much memory, and even causing the system to crash.
Therefore, Redis has set some protection mechanisms to avoid this situation. These mechanisms work on different types of clients and have different output buffer size limits in two ways:
One is the size limit. When the buffer of a client exceeds a certain size, the client connection is closed directly.
The other is that when a client's buffer takes up too much space for a period of time, it also closes the client connection directly.
The policies for different clients are as follows:
For ordinary clients, the limit is 0, that is, no limit, because ordinary clients usually use blocking message response mode, such as: send a request, wait for a return, send a request again, and then wait for a return. This mode usually does not cause the heap expansion of the output buffer.
For Pub/Sub clients, the size limit is 32m, and when the output buffer exceeds 32m, the connection is closed. The persistence limit is that when the client buffer size exceeds 8m for 60 seconds, it will also cause the connection to close.
For Slave clients, the size limit is 256m, and the persistence limit is to close the connection when the client buffer size exceeds 64m for 60 seconds.
The above three rules are configurable. You can configure it through the CONFIG SET command or by modifying the redis.conf file.
Input buffer size limit
Redis has a violent limit on the size of the input buffer. When the request size transmitted by the client exceeds 1G, the server will directly close the connection. This method can effectively prevent the problem of excessive input buffer caused by some client or server bug.
Client timeout
For the current version of Redis, the server does not close long-idle clients by default. But you can change the default configuration to set the timeout you want. For example, if the client has not interacted for how long, it will be shut down directly. Similarly, this can also be configured through the CONFIG SET command or by modifying the redis.conf file.
It is worth noting that the timeout setting only works for ordinary clients, and long-term idle status is normal for Pub/Sub clients.
In addition, the actual timeout may not be as accurate as set, because Redis does not use timers or rotation traverses to detect client timeouts, but in an asymptotic way, one part at a time. So the result is that maybe the timeout you set is 10s, but the real execution time is 12s before the client is shut down.
CLIENT command
Redis's CLIENT command performs three functions: checking the status of a connection, killing a connection, and setting a name for the connection.
The CLIENT LIST command can obtain the status of all current clients by using the following methods:
Redis 127.0.0.1 6379 > client list
Addr=127.0.0.1:52555 fd=5 name= age=855 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
Addr=127.0.0.1:52787 fd=6 name= age=6 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
As you can see from the output of the above command, there are currently two client connections to this Redis, and each line represents the information of one connection:
Addr: TCP address of the client, including IP and port
Fd: the file descriptor handle number corresponding to the client connection socket
Name: the name of the connection. It is empty by default and can be set through CLIENT SETNAME.
Age: number of seconds the client survives
Idle: the number of seconds the client is idle
Flags: type of client (N represents normal client. For more types, see http://redis.io/commands/client-list)
Omem: the size of the output buffer
Cmd: name of the last command executed
You can check the CLIENT LIST documentation to see exactly what all the output means.
When you get the client list from the above command, you can kill the specified connection with the CLIENT KILL command. The parameter to 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.
Thank you for reading! This is the end of this article on how Redis handles client connections. I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.