RESP is a Protocol used by Redis clients and Redis servers to communicate with each other. Its full name is Redis Serialization Protocol. It is easy to understand and also shows the characteristics of Redis: Serialization (single thread)

Note: RESP is an application-layer protocol, which means it relies on TCP/IP at the bottom

RESP’s design philosophy

The authors of Redis laid down the following three principles in designing the RESP protocol:

  1. Keep the implementation simple
  2. Parsing is fast for a computer
  3. For humans, it’s very readable

Request message format

When the Redis client requests the server, the message format is very simple, the template is as follows.

*< number of arguments >CRLF $< length of bytes for parameter 1 >CRLF < data for parameter 1 >CRLF... $< bytes of parameter N >CRLF < data of parameter N >CRLFCopy the code

In fact, there are three elements: the total number of parameters, the length of bytes of parameters, and parameter data

For example, start the Redis-CLI client and send a command:

set key1 value1
Copy the code

The content of the RESP packet corresponding to the command is

*3CRLF$3CRLFsetCRLF$4CRLFkey1CRLF$6CRLFvalue1
Copy the code

For our human viewing convenience, I printed out the CRLF control characters

*3
$3
set
$4
key1
$6
value1
Copy the code

Attach a comment

*3 //* indicates the start of the packet. 3 indicates three parameters. The values are set, key1, and value1 $3 // $3: The first parameter is 3 bytes long. Set // One parameter is $4 // The second parameter is 4 bytes long. Key1 // Second parameter is $6 // The third parameter is 6 bytes long // The third argumentCopy the code

The client request message is as simple as that

Response message format

There is only one format for a request message, but many formats for a response message

Simple String reply

A simple string reply is a one-line reply that begins with +, does not allow line breaks, and ends with \r\n. There are many instructions that will only reply with an OK after successful execution. This format is used to effectively reduce transmission and parsing overhead.

Like the one above

set key1 value1
Copy the code

If the command is executed successfully, the returned message is

+OKCRLF
Copy the code

Error response

In THE RESP protocol, the error reply is a variant of a simple string reply. The format is very similar except that the first character starts with -. The content of the error reply is usually a string describing the error type.

Error reply occurs in some abnormal scenarios, such as when the wrong command is sent or the number of operands is not correct. When the client receives an error reply, it is treated as an exception.

For example,

set1 key1 value1
Copy the code

The set1 command does not exist, so an error message is returned

-ERR unknown command `set1`, with args beginning with: `key1`, `value`,CRLF
Copy the code

Integer reply

The integer reply message is very simple

: digital CRLFCopy the code

This occurs when a user executes an EXISTS, INCr, or llEN command that returns a numeric value or a Boolean, for example

exists key1
Copy the code

Is the reply packet

:1CRLF
Copy the code

Batch reply

The template of batch reply packets is as follows

$< content length >CRLF < content >CRLFCopy the code

It starts with $, followed by the length of bytes sent, followed by CRLF, then sends the actual data, and finally ends with CRLF. If there is no message to reply to, the reply length is -1.

For example,

get key1
Copy the code

Is the reply packet

$6CRLF
value1CRLF
Copy the code
get key2
Copy the code

Is the reply packet

$-1CRLF
Copy the code

Multiple batch reply

The batch reply packets are the same as the client request packets

*< number of arguments >CRLF $< length of bytes for parameter 1 >CRLF < data for parameter 1 >CRLF... $< bytes of parameter N >CRLF < data of parameter N >CRLFCopy the code

This is common when retrieving hash, set, list, etc., for example

lrange key2 0 -1
Copy the code

Is the reply packet

*2 $3,123 $6,123,456Copy the code