Que signifie le protocole Redis ?

Le client Redis interagit avec le serveur Redis en utilisant un protocole appelé RESP (REdis Serialization Protocol, protocole de sérialisation redis). Bien que ce protocole soit conçu pour Redis, il peut également être utilisé dans d'autres systèmes logiciels d'architecture client-serveur. (Annotation : à en juger par certaines informations publiques, la conception du protocole IM de Momo fait référence au protocole Redis)

RESP pèse les aspects suivants :

La mise en œuvre doit être simple et l'analyse doit être rapide et pratique . Les gens qui lisent

RESP peuvent sérialiser différents types de données, tels que des entiers, des chaînes, des tableaux, et conçoivent également des types spéciaux pour les erreurs. Le client envoie une requête sous la forme d'un tableau de paramètres de chaîne au serveur Redis pour exécution, et Redis renvoie le type de données lié à la commande.

RESP est binaire et ne nécessite pas d'analyser les données en masse envoyées d'un processus à un autre, car il utilise un préfixe de longueur pour transmettre des données en masse.

Remarque : Le protocole mentionné ici est uniquement utilisé pour la communication client-serveur. Redis Cluster utilise différents protocoles binaires pour l'échange de messages entre les nœuds.

Couche réseau

Le client communique avec Redis en établissant une connexion TCP avec le port 6379.

Bien que RESP ne soit techniquement pas lié à TCP, pour Redis, le protocole n'est utilisé que pour TCP (ou d'autres protocoles de streaming tels que les protocoles de domaine Unix). (Annotation : D'un autre côté, memcached prend en charge à la fois TCP et UDP, mais en fait, l'environnement de production n'utilise essentiellement que TCP. Je pense qu'il s'agit d'une conception excessive, et elle peut être utilisée par des pirates informatiques pour effectuer des attaques par réflexion UDP Memcached. . . )

Modèle de réponse à la requête

Redis reçoit des commandes composées de différents paramètres. Lorsque la commande est reçue, elle est traitée et la réponse est envoyée au client.

Il s'agit du modèle le plus simple, mais il y a deux exceptions :

Redis prend en charge le pipeline (sera mentionné plus tard). Ainsi, le client peut envoyer plusieurs commandes à la fois et attendre des réponses. Lorsque le client s'abonne à un canal Pub/Sub, le protocole change de sémantique et devient un protocole push, ce qui signifie que le client n'a pas besoin d'envoyer de commandes car le serveur enverra automatiquement de nouveaux messages au client après réception du message ( canal auquel le client est abonné).

En plus de ces deux points, le protocole Redis est un simple protocole requête-réponse.

Description du protocole RESP

Le protocole RESP a été introduit dans Redis 1.2, mais il est désormais devenu le protocole d'interaction standard pour Redis 2.0. Vous devez utiliser ce protocole lors de l'implémentation d'un client Redis.

RESP est en fait un protocole de sérialisation qui prend en charge les types suivants : chaînes simples, erreurs, entiers, chaînes en bloc et tableaux.

RESP, en tant que protocole de réponse aux requêtes, est utilisé dans Redis comme suit :

Le client envoie des commandes au serveur Redis sous la forme d'un tableau de chaînes RESP Bulk. Le serveur implémente différentes commandes et renvoie l'implémentation RESP correspondante.

Dans RESP, le type de certaines données est déterminé par le premier octet :

Pour les SIMple Strings le premier octet de la réponse est "+" pour les Erreurs le premier mot de la réponse La section est "-". Pour les entiers, le premier octet de la réponse est ":". Pour les chaînes en bloc, le premier octet de la réponse est "$". Pour les tableaux, le premier octet de la réponse est "*"

.

En plus RESP Vous pouvez utiliser une chaîne ou un tableau en bloc spécial pour représenter les valeurs nulles, qui seront mentionnées plus tard.

Dans RESP les différentes parties du protocole sont toujours séparées par "rn" (CRLF).

Chaînes simples RESP

Les chaînes simples sont codées par : un signe plus, suivi d'une chaîne ne contenant aucun caractère CR ou LF (pas de nouvelle ligne), se terminant par CRLF ("rn")Finish.

SImple Strings transfère les chaînes sécurisées non binaires avec un minimum d'effort. Par exemple, de nombreuses commandes Redis répondent "OK" en cas de succès, ce qui correspond à 5 octets codés avec RESP Simple String :

"+OKrn"

Afin de transmettre des caractères binaires sécurisés Pour les chaînes, utilisez RESP Bulk Strings.

Lorsque Redis répond à une chaîne simple, la bibliothèque cliente doit renvoyer à l'appelant la chaîne du premier caractère "+" à la fin de la chaîne, à l'exclusion des octets CRLF.

Erreurs RESP

RESP a un type de données spécial pour les erreurs. En fait, l'erreur ressemble à RESP Simple String, mais la première chaîne est "-" au lieu du signe plus. La vraie différence entre les chaînes simples et les erreurs dans RESP est que les erreurs sont traitées comme des exceptions par le client et que la chaîne qui constitue le type d'erreur est la chaîne elle-même. Le format de base est :

"-Message d'erreur"

La réponse d'erreur ne sera envoyée que lorsqu'une erreur se produit, par exemple, vous avez utilisé le mauvais type de données ou la commande n'existe pas attends. Lorsqu'il reçoit une réponse d'erreur, le client doit lever une exception.

Ce qui suit est un exemple de réponse d'erreur :

-ERR commande inconnue 'foobar'-WRONGTYPE Opération sur une clé contenant le mauvais type de valeur

en "-" jusqu'au premier espace ou au premier mot d'une nouvelle ligne, indiquant le type d'erreur à renvoyer. Il s'agit simplement d'une convention de Redis lui-même, et non du format spécifié par 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 != &#39;\r&#39;) {
        len = (len*10)+(*p - &#39;0&#39;);
        p++;
    }

    /* Now p points at &#39;\r&#39;, 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使用教程栏目！

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!