redis：通信协议

怼烎@ 2022-09-14 14:26 228阅读 0赞

几乎所有的主流编程语言都有Redis的客户端，不考虑redis非常流行的原因，如果站在技术的角度看原因还有两个：

*  **客户端与服务端之间的通信协议是在TCP协议之上构建的**，服务端默认的端口号是6379
 *  客户端和服务器发送的命令或者数据一律以`\r\n` （CRLF）结尾。
 *  redis制定了RESP实现了客户端与服务端的正常交互，这种协议简单，既能够被机器解析，又容易被人类识别。

> [RESP][]是Redis序列化协议(REdis Serialization Portocol)的简写。它是一种直观的文本协议，优势在于实现过程异常简单，解析性能极好。\[官方文档\]

# RESP #

Redis协议将传输的结构数据分为5种最小单元类型，单元结束时统一加上回车换行符号\\r\\n。

*  单行字符串以`+`符号开头

+hello world\r\n

*  多行字符串以`$`符号开头，后跟字符串长度

$11\r\nhello world\r\n

*  整数值以`:`开头，后跟整数的字符串形式

:1024\r\n  // 整数1024

*  错误消息以`-`开头

-WRONGTYPE Operation against a key holding the wrong kind of value\r\n

*  数组以`*`开头，后跟数组的长度

*3\r\n:1\r\n:2\r\n:3\r\n   //数组[1, 2, 3]

NULL：用多行字符串表示，不过长度要写成-1

$31\r\n

空串：用多行字符串表示，长度填0

$0\r\n\r\n

## 客户端—>服务器 ##

客户端向服务器发送的指令只有一种格式，格式如下（CRLF代表"\\r\\n"）。

>  *  新版统一请求协议在 Redis 1.2 版本中引入， 并最终在 Redis 2.0 版本成为 Redis 服务器通信的标准方式。
>  *  你的 Redis 客户端应该按照这个新版协议来进行实现。
>  *  在这个协议中， 所有发送至 Redis 服务器的参数都是二进制安全（binary safe）的。这个协议的一般格式如下

*<参数数量> CR LF
    $<参数 1 的字节数量> CR LF
    <参数 1 的数据> CR LF
    ...
    $<参数 N 的字节数量> CR LF
    <参数 N 的数据> CR LF

例如客户端发送一条set hello world命令给服务端，按照RESP 的标准，客户端需要将其封装为如下格式（每行用\\r\\n分隔）：

*3
    $3
    SET
    $5
    hello
    $5
    world

*  参数数量为3个，因此第一行为：

*  参数字节数分别是355，因此后面几行为：

$3
    SET 
    $5
    hello
    $5
    world

**有一点要注意的是，上面只是格式化显示的结果，实际传输格式为如下代码**:

*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]  
稍后我们将会看到，这种格式除了用作命令请求协议之外，也用在命令的回复协议中：这种只有一个参数的回复格式叫做**批量回复（Bulk Reply）**

统一协议请求原本是用作回复协议中，用于将列表的多个项返回给客户端，这种回复格式被称为**多条批量回复（Multi Bulk Reply）。**

一个多条批量回复以`*<argc>\r\n` 为前缀， 后跟多条不同的批量回复， 其中 argc 为这些批量回复的数量。

## 服务器—>客户端 ##

redis命令会返回多种不同协议的回复。**通过检查服务器发回数据的第一个字节，可以确认这个回复是什么类型**

·状态回复：在RESP中第一个字节为"+"。 
    ·错误回复：在RESP中第一个字节为"-"。 
    ·整数回复：在RESP中第一个字节为"："。
    ·字符串回复：在RESP中第一个字节为"$"。
    ·多条字符串回复：在RESP中第一个字节为"*"。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16]  
我们知道redis-cli只能看到最终的执行结果，那是因为redis-cli本身就是按照RESP进行结果解析的，所以看不到中间结果，redis-cli.c源码对命令结果的解析结构如下：

static sds cliFormatReplyTTY(redisReply *r, char *prefix) {
        
        sds out = sdsempty();
        switch (r->type) {
        
        case REDIS_REPLY_ERROR:
        // 处理错误回复
        case REDIS_REPLY_STATUS:
        // 处理状态回复
        case REDIS_REPLY_INTEGER:
        // 处理整数回复
        case REDIS_REPLY_STRING:
        // 处理字符串回复
        case REDIS_REPLY_NIL:
        // 处理空
        case REDIS_REPLY_ARRAY:
        // 处理多条字符串回复
        return out;
    }

例如执行set hello world，返回结果是OK，并不能看到加号：

![在这里插入图片描述][a2c940b3ebc74900adcae9691afe7037.png]  
为了看到Redis服务端返回的“真正”结果，可以使用nc命令、telnet命令、甚至写一个socket程序进行模拟

下面以nc命令进行演示，首先使用nc连接到Redis：  
![在这里插入图片描述][3293146db9114409aeddeea9274b2a9c.png]状态回复：set hello world的返回结果为+OK

![在这里插入图片描述][772d0039ddfa4ae2a367303ec20f8c00.png]

### 状态回复 ###

*  一个状态回复（或者单行回复，single line reply）是一段以 `+`开始、 `\r\n`结尾的**单行字符串**。
    
     *  状态回复通常由那些不需要返回数据的命令返回，这种回复不是二进制安全的，他也不能包含新行
     *  状态回复的额外开销非常少，只需要三个字节（开头的 “+” 和结尾的 CRLF）。

以下是一个状态回复的例子：

+OK

*  **客户端库应该返回`+`号之后的所有内容**。比如在上面的这个例子中， 客户端就应该返回字符串 “OK” 。

![在这里插入图片描述][520d8a3d72784581aa896cc7f46cfce8.png]  
这里的OK就是单行响应

### 错误响应 ###

*  错误回复和状态回复非常相似， 它们之间的唯一区别是， 错误回复的第一个字节是 `-` ， 而状态回复的第一个字节是 `+`。
 *  错误回复只在某些地方出现问题时发送： 比如说， 当用户对不正确的数据类型执行命令， 或者执行一个不存在的命令， 等等。
 *  **一个客户端库应该在收到错误回复时产生一个异常**。

以下是两个错误回复的例子：

-ERR unknown command 'foobar'
    -WRONGTYPE Operation against a key holding the wrong kind of value

*  **在 “-” 之后，直到遇到第一个空格或新行为止，这中间的内容表示所返回错误的类型**。
 *  ERR 是一个通用错误，而 WRONGTYPE 则是一个更特定的错误。 一个客户端实现可以为不同类型的错误产生不同类型的异常， 或者提供一种通用的方式， 让调用者可以通过提供字符串形式的错误名来捕捉（trap）不同的错误。

不过这些特性用得并不多， 所以并不是特别重要， 一个受限的（limited）客户端可以通过简单地返回一个逻辑假（false）来表示一个通用的错误条件。  
![在这里插入图片描述][e1335eccc906406f86f96bb09a104a73.png]

### 整数响应 ###

*  **整数回复就是一个以 `:` 开头， CRLF 结尾的字符串表示的整数**。
 *  比如说， “:0\\r\\n” 和 “:1000\\r\\n” 都是整数回复。
 *  以下命令都返回整数回复：
    
     *  SETNX key value
     *  DEL key \[key …\]
     *  EXISTS key
     *  INCR key
     *  INCRBY key increment
     *  DECR key
     *  DECRBY key decrement
     *  DBSIZE
     *  LASTSAVE
     *  RENAMENX key newkey
     *  MOVE key db
     *  LLEN key
     *  SADD key member \[member …\]
     *  SREM key member \[member …\]
     *  SISMEMBER key member
     *  SCARD key 。

![在这里插入图片描述][d36f6bc672f546228546b0605c910b9e.png]

### 批量回复：多行字符串响应 ###

服务器使用批量回复来返回二进制安全的字符串，字符串的最大长度是512MB。

客户端：GET mykey
    服务器：foobar

服务端发送的内容中：

*  第一个字节是`$`符合
 *  接下来跟着的是表示实际回复长度的数字值
 *  之后跟着一个 CRLF
 *  再后面跟着的是实际回复数据
 *  最末尾是另一个 CRLF

对于前面的 GET key 命令，服务器实际发送的内容为：

"$6\r\nfoobar\r\n"

*  **如果被请求的值不存在， 那么批量回复会将特殊值 -1 用作回复的长度值**， 就像这样：

客户端：GET non-existing-key
    服务器：$-1

*  **这种回复称为空批量回复**（NULL Bulk Reply）。
 *  **当请求对象不存在时，客户端应该返回空对象，而不是空字符串**： 比如 Ruby 库应该返回 nil ， 而 C 库应该返回 NULL （或者在回复对象中设置一个特殊标志）， 诸如此类。

### 数组响应：多条批量回复 ###

像`LRANGE key start stop` 这样的命令**需要返回多个值， 这一目标可以通过多条批量回复来完成**。

redis> RPUSH fp-language lisp
    (integer) 1
    
    redis> LRANGE fp-language 0 0
    1) "lisp"
    
    redis> RPUSH fp-language scheme
    (integer) 2
    
    redis> LRANGE fp-language 0 1
    1) "lisp"
    2) "scheme"

*  **多条批量回复是由多个回复组成的数组，数组中的每个元素都可以是任意类型的回复**，包括多条批量回复本身
 *  \*\*多条批量回复的第一个字节为`*`，后跟一个字符串表示的整数值，这个值记录了多条批量回复所包含的回复数量，再后面是一个 CRLF \*\*

客户端： LRANGE mylist 0 3
    服务器： *4
    服务器： $3
    服务器： foo
    服务器： $3
    服务器： bar
    服务器： $5
    服务器： Hello
    服务器： $5
    服务器： World

在上面的示例中，服务器发送的所有字符串都由 CRLF 结尾。

正如你所见到的那样， 多条批量回复所使用的格式， 和客户端发送命令时使用的统一请求协议的格式一模一样。 它们之间的唯一区别是：

*  统一请求协议只发送批量回复。
 *  而服务器应答命令时所发送的多条批量回复，则可以包含任意类型的回复。

以下例子展示了一个多条批量回复， 回复中包含四个整数值， 以及一个二进制安全字符串：

*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 条回复， 再后面跟着的则是 5 条回复的正文。

*  **多条批量回复也可以是空白的**（empty）， 就像这样：

客户端： LRANGE nokey 0 1
    服务器： *0\r\n

*  **无内容的多条批量回复（null multi bulk reply）也是存在的**， 比如当 BLPOP key \[key …\] timeout 命令的阻塞时间超过最大时限时， 它就返回一个无内容的多条批量回复， 这个回复的计数值为 -1

客户端： BLPOP key 1
    服务器： *-1\r\n

*  **客户端库应该区别对待空白多条回复和无内容多条回复： 当 Redis 返回一个无内容多条回复时， 客户端库应该返回一个 null 对象， 而不是一个空数组**。

> 多条批量回复中的空元素

多条批量回复中的元素可以将自身的长度设置为 -1 ， 从而表示该元素不存在， 并且也不是一个空白字符串（empty string）。

当 `SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ASC | DESC] [ALPHA] [STORE destination]`命令使用 GET pattern 选项对一个不存在的键进行操作时， 就会发生多条批量回复中带有空白元素的情况。

以下例子展示了一个包含空元素的多重批量回复：

服务器： *3
    服务器： $3
    服务器： foo
    服务器： $-1
    服务器： $3
    服务器： bar

其中， 回复中的第二个元素为空。

对于这个回复， 客户端库应该返回类似于这样的回复：

["foo", nil, "bar"]

例子：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_10_color_FFFFFF_t_70_g_se_x_16]  
响应为：

![在这里插入图片描述][f1f2db01e4a847dda6275cf57675e524.png]

> 嵌套

![在这里插入图片描述][b2ed477c6df849c0a58f970f35c48fb6.png]

即：  
![在这里插入图片描述][78a21c4613664ba7a91d5ee907fc06d7.png]

## 多命令和流水线 ##

客户端可以通过流水线，在一次写入操作中发送多个命令：

*  在发送新命令之前，无需阅读前一个命令的回复
 *  多个命令的回复会在最后一并返回

## 内联命令 ##

当你需要和redis服务器进行沟通，但是又找不到redis-cli，而手上只有`telnet`的时候，你可以通过redis特别为这种情况设计的内联命令格式来发送命令。

以下是一个客户端和服务器使用内联命令来进行交互的例子：

客户端： PING
    服务器： +PONG

以下另一个返回整数值的内联命令的例子：

客户端： EXISTS somekey
    服务器： :0

因为没有了统一请求协议中的`*`项来声明参数的数量， 所以在 telnet 会话输入命令的时候， 必须使用空格来分割各个参数， 服务器在接收到数据之后， 会按空格对用户的输入进行分析（parse）， 并获取其中的命令参数。

# 高性能redis协议分析器 #

redis协议非常利于阅读，定义也很简单，但这个协议的实现性能仍然可以和二进制协议一样快。

因为redis协议将数据的长度放在数据正文之前，所以程序无需像json那样，为了寻找某个特殊字符而扫描整个payload，也无需对发送服务器的payload进行转移。

程序可以在对协议文本中的各个字符进行处理的同时，查找 CR 字符，并计算出批量回复或者多条批量回复的长度，就像这样：

#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;
    }

**得到了批量回复或者多条批量回复的长度之后，程序只需要调用一次`read`函数，就可以将回复的正文数据全部读入内存，而无需对这些数据进行任何处理**

在回复最末尾的CR和LF不作处理，丢弃它们

# 小结 #

redis协议里有大量冗余的回车换行符，但是这并不影响它成为互联网技术领域非常受欢迎的一个文本协议。

有很多开源项目使用RESP作为它的通信协议。

在技术领域，性能并不总是一切，还有简单性、易理解性以及易实现性

[RESP]: http://doc.redisfans.com/topic/protocol.html
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/23780ddaf43f4c80876622a0e41fb136.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/7a865f7412ec4143b98c7c3c65073ca4.png
[a2c940b3ebc74900adcae9691afe7037.png]: /images/20220828/45eec519be9240b2b77a88b8facc559d.png
[3293146db9114409aeddeea9274b2a9c.png]: /images/20220828/d2f6761a414a42dda84958a253ab808e.png
[772d0039ddfa4ae2a367303ec20f8c00.png]: /images/20220828/d3cba41b83a74d42b812e7b78e68a763.png
[520d8a3d72784581aa896cc7f46cfce8.png]: /images/20220828/ae5e524cc6274a959540596aeb530db9.png
[e1335eccc906406f86f96bb09a104a73.png]: /images/20220828/4846d1107d574ece853519094e689252.png
[d36f6bc672f546228546b0605c910b9e.png]: /images/20220828/5156c11eab984c6bb99903f35e9c7352.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_10_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/dade0063c4ca4585ad9d90ed3eab1e51.png
[f1f2db01e4a847dda6275cf57675e524.png]: /images/20220828/1346f74b6b514087ad2459ec26178b54.png
[b2ed477c6df849c0a58f970f35c48fb6.png]: /images/20220828/cb53e284291e4ce6a82ce688505127cd.png
[78a21c4613664ba7a91d5ee907fc06d7.png]: /images/20220828/728dcd75dbf444e388359c8eb14b74be.png