您的位置 首页 > 德语词汇

protocol是什么意思?用法、例句(Redis通信协议(protocol))

大家好,关于protocol是什么意思?用法、例句很多朋友都还不太明白,不过没关系,因为今天小编就来为大家分享关于Redis通信协议(protocol)的知识点,相信应该可以解决大家的一些困惑和问题,如果碰巧可以解决您的问题,还望关注下本站哦,希望对各位有所帮助!

客户端和服务器通过TCP连接来进行数据交互,服务器默认的端口号为6379。

客户端和服务器发送的命令或数据一律以\\r\\n(CRLF)结尾。

protocol是什么意思?用法、例句(Redis通信协议(protocol))

Redis服务器接受命令以及命令的参数。

服务器会在接到命令之后,对命令进行处理,并将命令的回复传送回客户端。

新版统一请求协议在Redis1.2版本中引入,并最终在Redis2.0版本成为Redis服务器通信的标准方式。

你的Redis客户端应该按照这个新版协议来进行实现。

在这个协议中,所有发送至Redis服务器的参数都是二进制安全(binarysafe)的。

译注:命令本身也作为协议的其中一个参数来发送。

举个例子,以下是一个命令协议的打印版本:

"*3\\r\\n$3\\r\\nSET\\r\\n$5\\r\\nmykey\\r\\n$7\\r\\nmyvalue\\r\\n"

稍后我们会看到,这种格式除了用作命令请求协议之外,也用在命令的回复协议中:这种只有一个参数的回复格式被称为批量回复(BulkReply)

统一协议请求原本是用在回复协议中,用于将列表的多个项返回给客户端的,这种回复格式被称为多条批量回复(MultiBulkReply)

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

Redis命令会返回多种不同类型的回复。

通过检查服务器发回数据的第一个字节,可以确定这个回复是什么类型:

一个状态回复(或者单行回复,singlelinereply)是一段以"+"开始、"\\r\\n"结尾的单行字符串。

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

状态回复通常由那些不需要返回数据的命令返回,这种回复不是二进制安全的,它也不能包含新行。

状态回复的额外开销非常少,只需要三个字节(开头的"+"和结尾的CRLF)。

错误回复和状态回复非常相似,它们之间的唯一区别是,错误回复的第一个字节是"-",而状态回复的第一个字节是"+"。

错误回复只在某些地方出现问题时发送:比如说,当用户对不正确的数据类型执行命令,或者执行一个不存在的命令,等等。

一个客户端库应该在收到错误回复时产生一个异常。

-ERRunknowncommand'foobar'

-WRONGTYPEOperationagainstakeyholdingthewrongkindofvalue

在"-"之后,直到遇到第一个空格或新行为止,这中间的内容表示所返回错误的类型。

ERR是一个通用错误,而WRONGTYPE则是一个更特定的错误。一个客户端实现可以为不同类型的错误产生不同类型的异常,或者提供一种通用的方式,让调用者可以通过提供字符串形式的错误名来捕捉(trap)不同的错误。

不过这些特性用得并不多,所以并不是特别重要,一个受限的(limited)客户端可以通过简单地返回一个逻辑假(false)来表示一个通用的错误条件。

整数回复就是一个以":"开头,CRLF结尾的字符串表示的整数。

比如说,":0\\r\\n"和":1000\\r\\n"都是整数回复。

返回整数回复的其中两个命令是INCR和LASTSAVE。被返回的整数没有什么特殊的含义,INCR返回键的一个自增后的整数值,而LASTSAVE则返回一个UNIX时间戳,返回值的唯一限制是这些数必须能够用64位有符号整数表示。

整数回复也被广泛地用于表示逻辑真和逻辑假:比如EXISTS和SISMEMBER都用返回值1表示真,0表示假。

其他一些命令,比如SADD、SREM和SETNX,只在操作真正被执行了的时候,才返回1,否则返回0。

以下命令都返回整数回复:SETNX、DEL、EXISTS、INCR、INCRBY、DECR、DECRBY、DBSIZE、LASTSAVE、RENAMENX、MOVE、LLEN、SADD、SREM、SISMEMBER、SCARD。

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

对于前面的GET命令,服务器实际发送的内容为:

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

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

这种回复称为空批量回复(NULLBulkReply)。

当请求对象不存在时,客户端应该返回空对象,而不是空字符串:比如Ruby库应该返回nil,而C库应该返回NULL(或者在回复对象中设置一个特殊标志),诸如此类。

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

多条批量回复是由多个回复组成的数组,数组中的每个元素都可以是任意类型的回复,包括多条批量回复本身。

多条批量回复的第一个字节为"*",后跟一个字符串表示的整数值,这个值记录了多条批量回复所包含的回复数量,再后面是一个CRLF。

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

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

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

在回复的第一行,服务器发送*5\\r\\n,表示这个多条批量回复包含5条回复,再后面跟着的则是5条回复的正文。

多条批量回复也可以是空白的(empty),就像这样:

无内容的多条批量回复(nullmultibulkreply)也是存在的,比如当BLPOP命令的阻塞时间超过最大时限时,它就返回一个无内容的多条批量回复,这个回复的计数值为-1:

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

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

当SORT命令使用GETpattern选项对一个不存在的键进行操作时,就会发生多条批量回复中带有空白元素的情况。

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

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

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

["foo",nil,"bar"]

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

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

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

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

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

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

因为Redis协议将数据的长度放在数据正文之前,所以程序无须像JSON那样,为了寻找某个特殊字符而扫描整个payload,也无须对发送至服务器的payload进行转义(quote)。

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

#include<stdio.h>\nintmain(void){\nunsignedchar*p="$123\\r\\n";\nintlen=0;\np++;\nwhile(*p!='\\r'){\nlen=(len*10)+(*p-'0');\np++;\n}\n/*Nowppointsat'\\r',andthelenisinbulk_len.*/\nprintf("%d\\n",len);\nreturn0;\n}

#include<stdio.h>\nintmain(void){\nunsignedchar*p="$123\\r\\n";\nintlen=0;\np++;\nwhile(*p!='\\r'){\nlen=(len*10)+(*p-'0');\np++;\n}\n/*Nowppointsat'\\r',andthelenisinbulk_len.*/\nprintf("%d\\n",len);\nreturn0;\n}

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

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

Redis协议的实现性能可以和二进制协议的实现性能相媲美,并且由于Redis协议的简单性,大部分高级语言都可以轻易地实现这个协议,这使得客户端软件的bug数量大大减少。

protocol是什么意思?用法、例句的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于Redis通信协议(protocol)、protocol是什么意思?用法、例句的信息别忘了在本站进行查找哦。

本站涵盖的内容、图片、视频等数据,部分未能与原作者取得联系。若涉及版权问题,请及时通知我们并提供相关证明材料,我们将及时予以删除!谢谢大家的理解与支持!

Copyright © 2023