Deep into Redis client (Redis client properties, Redis buffer, close Redis client)

Redis database uses I/O multiplexing technology to achieve file event processor, the server uses single thread single process way to deal with multiple clients sent over the command request, it establishes network communication with multiple clients at the same time. The server creates a redisClient structure for the client it is connected to, which stores the properties of the current client and the data structure for performing the related functions.

I/O multiplexing: Linux has five types of I/O models: 1. Blocking 2. Non-blocking 3. Event-driven 5. Asynchronous

Block: During a network I/O, the C end sends a request and the S end receives it. When C sends a request to perform IO, no other operations can be performed and the result needs to be returned synchronously.

I/O multiplexing: When multiple C ends send requests at the same time, these I/O operations are temporarily suspended by selector(epoll, kqueue) and queued in memory. In this case, the S terminal can choose when to read and process the I/OS. In other words, the S terminal can hold multiple I/OS simultaneously.

Redis text event handler

Client name, socket, flag, and time properties

127.0.0.1:6379> Client list ID =2 addr=127.0.0.1:53555 fd=9 Name = age=6 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=clientCopy the code

  1. Name: By default, clients connected to the Redis server do not have a name (the name attribute, above)

    Give it a name

    127.0.0.1:6379> client setname "local_client" OK 127.0.0.1:6379> Client list ID =2 addr=127.0.0.1:53555 fd=9 name=local_client age=110 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=clientCopy the code

    If no name is set for the client, the client’s name property will point to a NULL pointer. If the client is named, the client’s name attribute will point to a string object that holds the client’s name

  2. The socket:

The client socket is logged by the FD property of the client state

If the fd attribute is -1, the client is a fake client. The request command for the pseudo client does not come from the network, but from a Lua script or AOF file (more on that later), so the pseudo client does not require a socket connection, nor does it have a socket descriptor. Pseudo-clients are used when executing Lua scripts that contain Redis commands, or when using AOF files to restore database state.

If the fd attribute value is an integer greater than -1, the client is a normal client. Normal clients communicate with the server using correlation sockets, so the server uses the FD attribute to record the descriptor of the client socket.

  1. Mark attributes

    The flags attribute of the client records the Role and status of the client.

    The flags attribute can be a single flag or multiple binary or combination flags, as shown below.

    Single flags: Flags = < flag >

    Combination marks: flags = < flag1 > | < flag2 > | < flag3 > |…

    Flags are represented using constants. All flags that Redis has are defined in the redis.h file.

    There are several flags for recording client roles.

    ● In the use of Redis master and slave server replication, the master and slave servers will become each other’s clients, that is, the slave server is the client of the master server, and the master server is also the client of the slave server. Redis uses the REDIS_MASTER flag to indicate that this client is the master server and the REDIS_SLAVE flag to indicate that another client is the slave server.

    ● Redis uses the REDIS_LUA_CLIENT flag to indicate that the client is a pseudo-client dedicated to processing Lua scripts. It is mainly used to execute the Redis commands contained in Lua scripts.

    ● Redis uses the REDIS_PRE_PSYNC flag to indicate that the client is a secondary server whose version is later than Redis 2.8. In this case, the primary server cannot use the PSYNC command to synchronize data with the secondary server. The REDIS_PRE_PSYNC flag can only be used if the REDIS_SLAVE flag is on.

    The following flags record the current status of the client.

    ● REDIS_ASKING indicates that the client sends the ASKING command to the server node in cluster mode.

    ● The REDIS_CLOSE_ASAP flag indicates that the client’s output buffer is too large for the server. The next time the server executes the serverCron function, the server will shut down the client whose output buffer is too large, so that the server stability is not affected by the client. When closed, the data stored in this buffer is also deleted and no information is returned to the client.

    ● The REDIS_CLOSE_AFTER_REPLY flag indicates that the command request sent from the CLIENT to the server contains incorrect protocol content or the user has executed the CLIENT kill command on the CLIENT. At this point, the server sends the client all the data stored in the client output buffer, and then shuts down the client.

    ● The REDIS_DIRTY_CAS flag indicates that the database key monitored by the transaction using the WATCH command has been modified.

    ● The REDIS_DIRTY_EXEC flag indicates that a transaction error occurred when the command was enqueued.

    The presence of both the REDIS_DIRTY_CAS and REDIS_DIRTY_EXEC flags indicates that the security of the Redis transaction has been breached. Whenever either flag is turned on, the EXEC command will fail. Both flags can only be used if the client has the REDIS_MULTI flag turned on.

    ● REDIS_MULTI flag indicates that the client is in the state of executing a transaction.

    ● The REDIS_MONITOR flag indicates that the customer is running the MONITOR command.

    ● The REDIS_FORCE_AOF flag forces the server to write the currently executing command to the AOF file. When the PUBSUB command is executed, the client turns on the REDIS_FORCE_AOF flag.

    ● The REDIS_FORCE_REPL flag forces the master server to copy the currently executing command to all slave servers connected to it. When the SCRIPT LOAD command is executed, both the REDIS_FORCE_AOF and REDIS_FORCE_REPL flags are enabled on the client. If a SCRIPT specified by the SCRIPT LOAD command is to be correctly loaded by the master and slave servers, the server must use the REDIS_FORCE_REPL flag to force the master to distribute the SCRIPT LOAD command to the corresponding slave servers.

    ● The REDIS_UNIX_SOCKET flag indicates that the server connects to the client using a UNIX socket.

    ● REDIS_BLOCKED indicates that the client is blocked by commands such as BRPOP and BLPOP.

    ● The REDIS_UNBLOCKED flag indicates that the client is no longer blocked; it is removed from the blocked state of the REDIS_BLOCKED flag. The REDIS_UNBLOCKED flag can only be used if the REDIS_BLOCKED flag is turned on.

    ● REDIS_MASTER_FORCE_REPLY flag: During command interaction between the master server and slave server, the slave server needs to send REPLICATION ACK command to the master server. However, before sending this command, the slave server must enable the REDIS_MASTER_FORCE_REPLY flag on the client corresponding to the master server; Otherwise, the master server will refuse to execute the REPLCATION ACK command sent by the secondary server.

  2. Time property

    ● Ctime property: This property records the time when the client is created. Using this time, you can calculate the time, in seconds, for the client to connect to the server. After executing the CLIENT list command, the age field returned records the connection seconds

    ● lastinteraction property: this property records the lastinteraction between the client and the server. Interaction is the exchange of command requests and results between the two. Using the lastinteraction property, you can calculate the idle time of the client, which is how much time has passed in seconds before the lastinteraction. The idle field returned by the CLIENT list command records this time. When idle is 0, the idle time is 0 seconds.

    ● OBUF_sofT_limit_reacheD_TIME property: This property records the time when the client output buffer first reaches the soft limit

Redis client buffer

Some of the concepts

● Input buffer: used to save the command requests sent by the client. The size of the input buffer changes dynamically, shrinking or increasing according to the input. 1GB is the maximum size of the input buffer. If the size of the input buffer exceeds 1GB, the client will be shut down.

● Output buffer: Used to save the result or return value returned by executing the client request command. Each client has two output buffers, one of fixed size and one of variable size.

Fixed output buffer: used to hold small return values such as common OK, < nil > or short strings, integer values and error values.

Variable output buffer: used to store return values of large length, such as a large string, large list, large collection, etc.

The buf and bufpos attributes form a fixed-size buffer for the client.

The buf property is a byte array of REDIS_REPLY_CHUNK_BYTES. The default value of the REDIS_REPLY_CHUNK_BYTES constant is 16 x 1024, which means the default size of the BUF array is 16KB.

The bufpos property records the number of bytes that the BUF array has used so far.

The server uses variable-size buffers when the BUF array is full or the response is too large to fit into the BUF array.

The linked list reply and one or more string objects form a variable-size output buffer. By using linked lists to concatenate multiple string objects, the server can store a very long command return value for the client without being limited by size. A variable size output buffer is shown.

The server uses Soft Limit and Hard Limit to Limit the size of the client buffer.

  1. Soft limit: If the soft limit is set to a size smaller than the output buffer size, and the output buffer size is not larger than the hard limit, the server uses the obuF_sofT_limit_reached_time property of the client state structure to record the start time when the client reaches the soft limit. The server then continues to monitor the client, and if the buffer size continues to exceed the soft limit for longer than the server has set, the server will shut down the client. Conversely, if the output buffer size does not exceed the soft limit within the specified time range, the client is not shut down and the value of the obuF_sofT_limit_reacheD_time property is set to 0.

  2. When the output buffer size exceeds the hard limit, the client is shut down immediately.

  3. Set soft and hard limits

    We can use the client-output-buffer-limit option to set soft and hard limits for normal clients, slave clients, or clients that perform message subscribe and publish functions

Authenticated property of the client

The authenticated attribute is a client authentication attribute that records whether a client is authenticated. The values of this property are 0 and 1, and the default value is 0.

When authenticated is 0, the server rejects all commands sent by the client except for the AUTH command.

Argv and argc properties on the client side

Argv attribute: This is an array where each element is a string object, where argv[0] is the command to execute, and the other elements that follow are the arguments passed to the command.

Argc property: The length of the array used to record the argv property.

When a client sends a command to the server, the server saves the command it receives in the QueryBuf property of the client state. Once saved, the server parses the contents of the command and stores the parsed command parameters and the number of command parameters in the argv and argc attributes, respectively

Closing the Client

There are several ways that normal clients can be shut down:

● After the CLIENT kill command is executed, the CLIENT is shut down.

● When the client process is killed, the client is disconnected from the server and the client is shut down.

● If a client sends a command to the server in an incorrect protocol format, the client is shut down.

● The client is shut down when the size of the command request exceeds the limit of the input buffer.

● The client will be shut down if the size of the output buffer exceeds the size of the output buffer.

● When the timeout value is set for the server and the idle time of the client exceeds the timeout value, the client will be shut down. If the client is the master server and the slave server is blocked by BLPOP, BRPOP, etc., or the slave server is executing commands related to subscriptions and publications, the client will not be shut down even if the idle time of the client exceeds the timeout value.