Redis RESP 协议简介（1）

我要继续努力推进工作，力争在开源存储领域有所作为，对 Redis RESP 建立了解可以帮助我们对于诸多开源存储引擎（比如 KiwiDB）建立理解。

这篇文档可以理解为对 RESP 协议文档的一个简单翻译。

在 Redis 的官方文档 中, Redis 的设计团队表示：

Redis RESP 协议具有下面的三个优点：

• 易于实现
• 解析迅速
• 可读性好

同时，RESP 协议可以对于诸如整数、字符串、数组一类的数据类型做可序列化。同时，它还支持自定义错误类型。

简单来说，在 RESP 协议框架的指导之下，客户端将 “指令-指令所对应的参数” 打包为一个字符串数组，并将其发送给服务端，而服务端，将根据客户端发送的内容，反馈相对应的内容。

同时，RESP 协议是二进制安全的，它将会使用前缀长度，用以指导为批量数据准备的内存空间的大小。

注意：RESP 适用于单节点版本的 Redis，集群版本的实现协议另有安排。

RESP 的版本简介

RESP 协议最初在 Redis 1.2 中被正式支持，并在 Redis 2.0 中过渡到 RESP 2 协议，并成为 Redis 服务端与客户端交互的正式标准。

RESP3 基于 RESP2 展开改进，并在 Redis 6.0 中得到了更为有力的支持（我们同时引入了 HELLO 指令，用于在客户端与服务端间，展开版本的切换）。

目前，截至 Redis 7，无论是哪一个版本的 RESP 协议都是可以使用 Redis 核心指令的，只是在部分的细节上面，服务端的反馈，会有所差别。

未来版本的 Redis 将会全面升级至 RESP 3，RESP 2 将会被放弃。同时所有的新特性将会要求使用 RESP3。

网络层的协议

客户端经由一个端口（默认 6379）采用 TCP 协议连接 Redis。

其它协议是不支持的。

“请求与响应” 模型

Redis 服务端接受指令以及其所对应的参数，之后构造响应并且返回。

不过也存在一些例外的情况：

• Redis 的请求可以被流水线化。在这种情况下，客户端一次可以发送多个请求
• 当 RESP2 的连接转向 订阅/发布 模型，协议的语义将会被转变（也就是同一则指令所对应的内涵），并且成为一个推送模型。这种情况下面，客户端不再需要向服务端发送消息，因为服务端将会自动向客户端发送新消息（经由管道，即客户端订阅的 channel）。
• MONITOR 指令将会把模型调整为推送模型
• 保护模式。这种情况下，Redis 将会拒绝所有非白名单内的连接，无论客户端是否已经写入内容到 socket 之中。
• RESP3 中指定的推送类型。正如名字所言，一个推送类型将会要求服务端源源不断地向连接传送数据。这种情况下，服务端反馈的内容，可能与客户端无关。

RESP 协议的更细节描述

在 RESP 协议中，第一个字节决定了数据的类型（这种字节对应 ASCII 码中的键值，举例来说， \r 对应的就是 13）。

RESP 协议的终止符号是 \r\n，它往往也作为内容的分界线。

在这个基础上面，RESP 的数据被划分为三种类型：

• 简单（Simple） 正如同编程语言中的布尔类型、整数类型，是清晰的文本
• 散装（Bulk） 简单的字符串，或者是纯粹的二进制数据流
• 聚合类型（Aggregate） 数组类型、位图类型等复合类型

下面的表格记载了每一种类型，对应的版本，分类，以及对应的符号：

RESP data type	Minimal protocol version	Category	First byte
Simple strings	RESP2	Simple	+
Simple Errors	RESP2	Simple	-
Integers	RESP2	Simple	:
Bulk strings	RESP2	Aggregate	$
Arrays	RESP2	Aggregate	*
Nulls	RESP3	Simple	_
Booleans	RESP3	Simple	#
Doubles	RESP3	Simple	,
Big numbers	RESP3	Simple	(
Bulk errors	RESP3	Aggregate	!
Verbatim strings	RESP3	Aggregate	=
Maps	RESP3	Aggregate	%
Attributes	RESP3	Aggregate	`
Sets	RESP3	Aggregate	~
Pushes	RESP3	Aggregate	>

下一篇文章的内容是对于每一种数据类型的具体介绍。

写在最后

感谢业界老师们的信任与支持。