The Redis client interacts with the Redis server by using a protocol called RESP (REdis Serialization Protocol, redis serialization protocol). Although this protocol is designed for Redis, it can also be used in other client-server architecture software systems. (Annotation: Judging from some public information, Momo’s IM protocol design refers to the Redis protocol)
RESP weighs the following aspects:
The implementation must be simple and the parsing must be fast and convenient People read
RESP can serialize different data types, such as integers, strings, arrays, and also designs special types for errors. The client sends a request in the form of a string parameter array to the Redis server for execution, and Redis returns the data type related to the command.
RESP is binary-safe and does not require parsing bulk data sent from one process to another because it uses a length prefix to transmit bulk data.
Note: The protocol mentioned here is only used for client-server communication. Redis Cluster uses different binary protocols for message exchange between nodes.
Network layer
The client communicates with Redis by establishing a TCP connection with port 6379.
Although RESP is not technically related to TCP, for Redis the protocol is only used for TCP (or other streaming protocols such as Unix domain protocols). (Translation note: Memcached, on the other hand, supports both TCP and UDP, but in fact, the production environment basically only uses TCP. I think this is an over-design, and it may be used by hackers to conduct memcached UDP reflection attacks. .)
Request response model
Redis receives commands composed of different parameters. When the command is received it is processed and the response is sent to the client.
This is the simplest model, but there are two exceptions:
Redis supports pipelining (will be mentioned later). So the client can send multiple commands at once and wait for responses. When the client subscribes to a Pub/Sub channel, the protocol will change its semantics and become a push protocol, which means that the client does not need to send commands because the server will automatically send new messages to the client after receiving the message ( channel to which the client is subscribed).
In addition to these two points, the Redis protocol is a simple request-response protocol.
RESP protocol description
RESP protocol was introduced in Redis 1.2, but it has now become the standard interaction protocol for Redis 2.0. You should use this protocol when implementing a Redis client.
RESP is actually a serialization protocol that supports the following types: Simple Strings, Errors, Integers, Bulk Strings and Arrays.
RESP, as a request response protocol, is used in Redis as follows:
The client sends commands to the Redis server in the form of an array of RESP Bulk Strings. The server implements different commands and returns the corresponding RESP implementation.
In RESP, the type of some data is determined by the first byte:
For SImple Strings, the first byte of the response is " ", for Errors, the first byte of the response It is "-" for Integers, the first byte of the response is ":" for Bulk Strings, the first byte of the response is "$", for Arrays, the first byte of the response is "*"
In addition, RESP can Use a special Bulk String or array to represent Null values, which will be mentioned later.
In RESP different parts of the protocol are always separated by "\r\n" (CRLF).
RESP Simple Strings
Simple Strings are encoded as follows: a plus sign, followed by a string containing no CR or LF characters (no newlines), ending with CRLF ("\ r\n") ends.
SImple Strings transmits non-binary safe strings with minimal effort. For example, many Redis commands respond "OK" when successful, which is 5 bytes encoded with RESP Simple String:
" OK\r\n"
In order to transmit binary For safe strings, use RESP Bulk Strings.
When Redis responds to a Simple String, the client library should return to the caller the string from the first " " character to the end of the string, excluding CRLF bytes.
RESP Errors
RESP There is a special data type for error. Actually error is just like RESP Simple String, but the first string is "-" instead of plus sign. The real difference between Simple Strings and Errors in RESP is that errors are treated as exceptions by the client, and the string that constitutes the Error type is the string itself. The basic format is:
"-Error message\r\n"
The Error response will only be sent when an error occurs, for example, you operated the wrong data type. Or the command does not exist, etc. When receiving an Error response, the client should throw an exception.
The following is an example of an error response:
-ERR unknown command 'foobar'-WRONGTYPE Operation against a key holding the wrong kind of value
在"- " to the first space or the first word on a new line, indicating the type of error to return. This is just a convention of Redis itself, not the format specified by RESP Error.
例如，ERR 是通用错误，而 WRONGTYPE 是一种更加具体的错误，表示客户端尝试操作错误的数据类型。这称为 Error Prefix （Error前缀），客户端可从此得知服务器返回错误的类型而不需依赖于那个确切的消息描述，后者会随时改变。
一个客户端的实现可能对不同的error返回不同类型的异常，或者向调用者返回代表错误的字符串。然而这种特性并不是必须的，因为这并没什么卵用，一些精简的客户端实现可能简单的返回一般的错误情况，例如 false。
RESP Integers
这种类型就是一个代表整数的以CRLF结尾的字符串，并以“:”字节开头。例如 ":0\r\n", 或 ":1000\r\n" 都是整数响应。
很多Redis命令返回RESP Integers, 像 INCR, LLEN 和 LASTSAVE。
返回的整数并没什么特殊的含义，它就是 INCR 增加后的数字，LASTSAVE 的UNIX时间戳等。但返回的整数可以保证是在64位有符号整数的范围内。
整数响应也被大量的用于表示true或false。例如EXISTS和 SISMEMBER 等命令会返回1表示true， 0表示false。
以下命令会返回一个整数: SETNX, DEL, EXISTS, INCR, INCRBY, DECR, DECRBY, DBSIZE, LASTSAVE, RENAMENX, MOVE, LLEN, SADD, SREM, SISMEMBER, SCARD。
RESP Bulk Strings
Bulk Strings 用于表示一个二进制安全的字符串，最大长度为512M。
Bulk Strings 的编码格式如下：
“$” 后跟字符串字节数（prefix length），以CRLF结束实际的字符串CRLF结束
所以字符串"foobar" 被编码成：
"$6\r\nfoobar\r\n"
空字符串：
"$0\r\n\r\n"
RESP Bulk String 也可以用一种代表Null值的特殊格式来表示不存在的值。这种特殊格式的长度值为-1， 并且没数据，所以Null表示为：
"$-1\r\n"
这称为 Null Bulk String。
当服务器返回Null Bulk String时，客户端API不应该返回空串，而是nil 对象。例如Ruby库应该返回 'nil' 而 C 库应该返回 NULL (或在返回的对象设置特殊的标记)，等等。
RESP Arrays
客户端用RESP Arrays向Redis服务器发送命令。同样某些Redis命令要返回一个元素集合时也使用RESP Arrays作为返回的类型。一个例子是LRANGE 命令返回一个元素列表。
RESP Arrays使用以下格式发送：
“*” 为第一个字节，后跟数组的元素个数，然后CRLF。然后是数组中的每一个RESP类型表示的元素。
例如一个空数组表示为：
"*0\r\n"
而有两个RESP Bulk Strings "foo" 和 "bar" 的数组编码为：
"*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n"
正如你所见，在数组前面的 *570b78fce6f4d82c6d7725059f1f48f1CRLF 后，数组中的其他的数据类型一个接一个的连接在一起。例如一个有三个整数的数组编码如下：
"*3\r\n:1\r\n:2\r\n:3\r\n"
数组可以包含混合类型，它不要求所有的元素都是相同的类型。例如，一个有4个interges和1个bulk string的数组可以编码为：
*5\r\n :1\r\n :2\r\n :3\r\n :4\r\n $6\r\n foobar\r\n
（为清晰起见响应被分为多行）。
服务器发送的第一行 *5\r\n 表示后跟有5个响应，然后每个代表元素的响应被发送。
Null 数组的概念同样存在，它是Null值的替代方式 (通常使用Null Bulk String，但由于历史原因我们有两种格式)。
例如当BLPOP命令超时，它返回一个长度为-1的Null 数组，如下所示：
"*-1\r\n"
在服务端返回Null数组时，客户端库API应该返回null对象而不是空数组。区分返回空的列表与其他的情况(如BLPOP命令超时的情况)是有必要的。
RESP允许数组的数组。例如一个含两个数组的数组编码如下：
*2\r\n *3\r\n :1\r\n :2\r\n :3\r\n *2\r\n +Foo\r\n -Bar\r\n
高效解析Redis协议
尽管Redis协议非常可读并且容易实现，它却可以兼得二进制协议的高效。
RESP使用长度前缀来传输bulk 数据，所以不需要像JSON一样扫描数据负载中的特殊符号，或者用引号括住数据负载。
Bulk和Multi Bulk长度的处理可以一次处理一个字符，同时可以扫描CR字符，像如下的C代码：
#include <stdio.h>
int main(void) {
unsigned char *p = "$123\r\n";
int len = 0;
p++;
while(*p != '\r') {
len = (len*10)+(*p - '0');
p++;
}
/* Now p points at '\r', and the len is in bulk_len. */
printf("%d\n", len);
return 0;
}当第一个CR被识别后，后面的LF可以忽略不处理。然后bulk数据可以一次读取而不需要分析 数据负载。最后剩下的CR和LF字符串可以丢弃不处理。
与二进制协议比较性能时，Redis协议在大部分的高级语言实现起来足够简单，减少了客户端软件的bug数量。
注：
1. 协议中的CR和LF相当于分割符，命令间存在多个CRLF不应影响后续解析，应为多个CRLF应被忽略掉。例如：
$> (printf "PING\r\nPING\r\nPING\r\n\r\n\rPING\r\n"; sleep 1) | nc localhost 6379 +PONG +PONG +PONG +PONG
2. 对比一下memcached的协议，redis的协议确实设计得比较精简：
(1) 一致的请求形式。redis的请求都是以 Bluk String 数组发送，不同命令只是数组的元素个数不同，所有命令的处理可以先读取完整个数组再根据不同命令解析数组的参数；而不是像mc协议一样，不同请求的命令格式不同，那么在读取网络字节流的过程中就要对不同命令做不同的处理，增加了协议解析的难度。
(2) 长度前缀是高效解析协议的关键。字段长度信息并不是二进制协议的专利，文本协议也可以有。
更多Redis相关知识，请访问Redis使用教程栏目！
The above is the detailed content of What does redis protocol mean?. For more information, please follow other related articles on the PHP Chinese website!