几乎所有的主流编程语言都有Redis的客户端，不考虑redis非常流行的原因，如果站在技术的角度看原因还有两个：
- 客户端与服务端之间的通信协议是在TCP协议之上构建的，服务端默认的端口号是6379
- 客户端和服务器发送的命令或者数据一律以 （CRLF）结尾。
- redis制定了RESP实现了客户端与服务端的正常交互，这种协议简单，既能够被机器解析，又容易被人类识别。
RESP是Redis序列化协议(REdis Serialization Portocol)的简写。它是一种直观的文本协议，优势在于实现过程异常简单，解析性能极好。[官方文档]
Redis协议将传输的结构数据分为5种最小单元类型，单元结束时统一加上回车换行符号 。
- 单行字符串以符号开头
- 多行字符串以符号开头，后跟字符串长度
- 整数值以开头，后跟整数的字符串形式
- 错误消息以开头
- 数组以开头，后跟数组的长度
NULL：用多行字符串表示，不过长度要写成-1
空串：用多行字符串表示，长度填0
客户端向服务器发送的指令只有一种格式，格式如下（CRLF代表" "）。
- 新版统一请求协议在 Redis 1.2 版本中引入， 并最终在 Redis 2.0 版本成为 Redis 服务器通信的标准方式。
- 你的 Redis 客户端应该按照这个新版协议来进行实现。
- 在这个协议中， 所有发送至 Redis 服务器的参数都是二进制安全（binary safe）的。这个协议的一般格式如下
例如客户端发送一条set hello world命令给服务端，按照RESP 的标准，客户端需要将其封装为如下格式（每行用 分隔）：
- 参数数量为3个，因此第一行为：
- 参数字节数分别是355，因此后面几行为：
有一点要注意的是，上面只是格式化显示的结果，实际传输格式为如下代码:
稍后我们将会看到，这种格式除了用作命令请求协议之外，也用在命令的回复协议中：这种只有一个参数的回复格式叫做批量回复（Bulk Reply）
统一协议请求原本是用作回复协议中，用于将列表的多个项返回给客户端，这种回复格式被称为多条批量回复（Multi Bulk Reply）。
一个多条批量回复以 为前缀， 后跟多条不同的批量回复， 其中 argc 为这些批量回复的数量。
redis命令会返回多种不同协议的回复。通过检查服务器发回数据的第一个字节，可以确认这个回复是什么类型
我们知道redis-cli只能看到最终的执行结果，那是因为redis-cli本身就是按照RESP进行结果解析的，所以看不到中间结果，redis-cli.c源码对命令结果的解析结构如下：
例如执行set hello world，返回结果是OK，并不能看到加号：
为了看到Redis服务端返回的“真正”结果，可以使用nc命令、telnet命令、甚至写一个socket程序进行模拟
下面以nc命令进行演示，首先使用nc连接到Redis：
状态回复：set hello world的返回结果为+OK
状态回复
- 一个状态回复（或者单行回复，single line reply）是一段以 开始、 结尾的单行字符串。
- 状态回复通常由那些不需要返回数据的命令返回，这种回复不是二进制安全的，他也不能包含新行
- 状态回复的额外开销非常少，只需要三个字节（开头的 “+” 和结尾的 CRLF）。
以下是一个状态回复的例子：
- 客户端库应该返回号之后的所有内容。比如在上面的这个例子中， 客户端就应该返回字符串 “OK” 。
这里的OK就是单行响应
错误响应
- 错误回复和状态回复非常相似， 它们之间的唯一区别是， 错误回复的第一个字节是 ， 而状态回复的第一个字节是 。
- 错误回复只在某些地方出现问题时发送： 比如说， 当用户对不正确的数据类型执行命令， 或者执行一个不存在的命令， 等等。
- 一个客户端库应该在收到错误回复时产生一个异常。
以下是两个错误回复的例子：
- 在 “-” 之后，直到遇到第一个空格或新行为止，这中间的内容表示所返回错误的类型。
- ERR 是一个通用错误，而 WRONGTYPE 则是一个更特定的错误。 一个客户端实现可以为不同类型的错误产生不同类型的异常， 或者提供一种通用的方式， 让调用者可以通过提供字符串形式的错误名来捕捉（trap）不同的错误。
不过这些特性用得并不多， 所以并不是特别重要， 一个受限的（limited）客户端可以通过简单地返回一个逻辑假（false）来表示一个通用的错误条件。
整数响应
- 整数回复就是一个以 开头， CRLF 结尾的字符串表示的整数。
- 比如说， “:0 ” 和 “:1000 ” 都是整数回复。
- 以下命令都返回整数回复：
- 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 。
批量回复：多行字符串响应
服务器使用批量回复来返回二进制安全的字符串，字符串的最大长度是512MB。
服务端发送的内容中：
- 第一个字节是符合
- 接下来跟着的是表示实际回复长度的数字值
- 之后跟着一个 CRLF
- 再后面跟着的是实际回复数据
- 最末尾是另一个 CRLF
对于前面的 GET key 命令，服务器实际发送的内容为：
- 如果被请求的值不存在， 那么批量回复会将特殊值 -1 用作回复的长度值， 就像这样：
- 这种回复称为空批量回复（NULL Bulk Reply）。
- 当请求对象不存在时，客户端应该返回空对象，而不是空字符串： 比如 Ruby 库应该返回 nil ， 而 C 库应该返回 NULL （或者在回复对象中设置一个特殊标志）， 诸如此类。
数组响应：多条批量回复
像 这样的命令需要返回多个值， 这一目标可以通过多条批量回复来完成。
- 多条批量回复是由多个回复组成的数组，数组中的每个元素都可以是任意类型的回复，包括多条批量回复本身
- 多条批量回复的第一个字节为，后跟一个字符串表示的整数值，这个值记录了多条批量回复所包含的回复数量，再后面是一个 CRLF
在上面的示例中，服务器发送的所有字符串都由 CRLF 结尾。
正如你所见到的那样， 多条批量回复所使用的格式， 和客户端发送命令时使用的统一请求协议的格式一模一样。 它们之间的唯一区别是：
- 统一请求协议只发送批量回复。
- 而服务器应答命令时所发送的多条批量回复，则可以包含任意类型的回复。
以下例子展示了一个多条批量回复， 回复中包含四个整数值， 以及一个二进制安全字符串：
在回复的第一行， 服务器发送 *5 ， 表示这个多条批量回复包含 5 条回复， 再后面跟着的则是 5 条回复的正文。
- 多条批量回复也可以是空白的（empty）， 就像这样：
- 无内容的多条批量回复（null multi bulk reply）也是存在的， 比如当 BLPOP key [key …] timeout 命令的阻塞时间超过最大时限时， 它就返回一个无内容的多条批量回复， 这个回复的计数值为 -1
- 客户端库应该区别对待空白多条回复和无内容多条回复： 当 Redis 返回一个无内容多条回复时， 客户端库应该返回一个 null 对象， 而不是一个空数组。
多条批量回复中的空元素
多条批量回复中的元素可以将自身的长度设置为 -1 ， 从而表示该元素不存在， 并且也不是一个空白字符串（empty string）。
当 命令使用 GET pattern 选项对一个不存在的键进行操作时， 就会发生多条批量回复中带有空白元素的情况。
以下例子展示了一个包含空元素的多重批量回复：
其中， 回复中的第二个元素为空。
对于这个回复， 客户端库应该返回类似于这样的回复：
例子：
响应为：
嵌套
即：
客户端可以通过流水线，在一次写入操作中发送多个命令：
- 在发送新命令之前，无需阅读前一个命令的回复
- 多个命令的回复会在最后一并返回
当你需要和redis服务器进行沟通，但是又找不到redis-cli，而手上只有的时候，你可以通过redis特别为这种情况设计的内联命令格式来发送命令。
以下是一个客户端和服务器使用内联命令来进行交互的例子：
以下另一个返回整数值的内联命令的例子：
因为没有了统一请求协议中的项来声明参数的数量， 所以在 telnet 会话输入命令的时候， 必须使用空格来分割各个参数， 服务器在接收到数据之后， 会按空格对用户的输入进行分析（parse）， 并获取其中的命令参数。
redis协议非常利于阅读，定义也很简单，但这个协议的实现性能仍然可以和二进制协议一样快。
因为redis协议将数据的长度放在数据正文之前，所以程序无需像json那样，为了寻找某个特殊字符而扫描整个payload，也无需对发送服务器的payload进行转移。
程序可以在对协议文本中的各个字符进行处理的同时，查找 CR 字符，并计算出批量回复或者多条批量回复的长度，就像这样：
得到了批量回复或者多条批量回复的长度之后，程序只需要调用一次函数，就可以将回复的正文数据全部读入内存，而无需对这些数据进行任何处理
在回复最末尾的CR和LF不作处理，丢弃它们
redis协议里有大量冗余的回车换行符，但是这并不影响它成为互联网技术领域非常受欢迎的一个文本协议。
有很多开源项目使用RESP作为它的通信协议。
在技术领域，性能并不总是一切，还有简单性、易理解性以及易实现性
到此这篇redis端口6379（Redis端口号）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/12707.html