Redis之所以能拥有如此丰富的客户端生态——从Java的Jedis、Lettuce到Python的redis-py、Go的go-redis——很大程度上得益于它采用了一套极其简单、人类可读的通信协议RESP。RESP经历了一次重大升级：从Redis 6.0开始引入的RESP3协议。很多开发者平时只调用客户端API，对底层协议一知半解，遇到握手参数、版本协商、Push消息处理等问题时就容易犯迷糊。这篇文章就把RESP2和RESP3的字节格式、类型系统、交互流程彻底讲清楚。
RESP2协议的五种基本类型
RESP2是Redis从诞生之初一直到5.x版本使用的协议版本。它的设计哲学是"简单到极致"：所有数据都用一段以\r\n结尾的字节序列表示，第一个字节是类型标识符，客户端根据这个标识符解析剩余内容。整个协议不依赖外部库，一个下午就能手写出一个能用的解析器。
RESP2一共定义了五种类型。简单字符串以+开头，用于返回OK这类状态；错误以-开头，比如-WRONGTYPE Operation against a key holding the wrong kind of value\r\n；整数以:开头，用于INCR、LLEN这类命令的返回值；批量字符串以$开头，后跟字符串长度，可以安全传输二进制数据；数组以*开头，是命令参数和批量结果的载体。
下面用一段伪代码展示客户端发送SET命令时的实际报文。注意命令本身也是以数组形式编码的，每个参数都是一个批量字符串：
*3\r\n $3\r\n SET\r\n $4\r\n name\r\n $5\r\n hello\r\n
这段报文的含义是：一个包含3个元素的数组，元素分别是SET、name、hello。服务端收到后返回+OK\r\n。如果执行GET name，服务端返回$5\r\nhello\r\n；若key不存在，则返回$-1\r\n表示空值。正是这种可读性，你可以直接用telnet连接Redis调试命令，不需要任何专门工具。
RESP2的局限：为什么需要RESP3
RESP2最大的问题在于类型表达能力的缺失。Redis服务端明明知道一个key是哈希表、一个是集合，但通过RESP2返回给客户端时，一切都被压平成了数组和字符串。以HGETALL命令为例，RESP2返回的是一个交替包含field和value的扁平数组，客户端必须"知道"这个命令返回的是键值对，才能把它们两两配对还原成字典。如果客户端想做一个通用的代理或中间件，这类隐式约定就成了噩梦。
第二个痛点是连接内多路复用的语义问题。RESP2模式下，一个连接上同一时刻只能承载普通命令回复，订阅消息、阻塞命令的结果都混在同一个通道里。RESP2用特定的状态回复（比如subscribe命令返回的特殊数组）来区分消息类型，客户端解析逻辑复杂且容易出错。此外，RESP2无法表达浮点数、布尔值等现代数据类型，浮点数只能以字符串传输，客户端还得自己调用parseFloat。
这些问题在单机小规模使用时不明显，但随着Redis被用作缓存、消息总线、流处理平台，客户端对协议类型信息的要求越来越高。Redis 6.0引入RESP3，正是为了在保持向后兼容的前提下解决这些结构性缺陷。
RESP3新增的类型与语义
RESP3在保留RESP2全部类型的基础上，新增了一批语义更丰富的类型。Map类型以%开头，后跟键值对数量，HGETALL在RESP3下直接返回Map，客户端拿到手就是现成的字典结构：%2\r\n$4\r\nname\r\n$5\r\nhello\r\n...。Set类型以~开头，SMEMBERS返回的不再是无序数组而是明确的集合。Double类型以,开头，如,3.14159\r\n，浮点数有了原生表达。
此外还有几个重要的新类型。Boolean以#开头，取值为#t\r\n或#f\r\n；大整数Big Number以(开头，支持任意精度整数；Verbatim String以=开头，适合返回带格式提示的文本；最有意思的是Push类型，以>开头，它让服务端可以主动向客户端推送带外消息，订阅通知、失效通知等都可以走Push通道，与普通命令回复在协议层面明确区分开。配合RESP3引入的CLIENT-UNPAUSE等连接管理命令，客户端处理并发消息的逻辑清晰了很多。
需要注意，RESP3还引入了两个流式类型：属性类型|可以为后续数据附加元信息（类似HTTP头），而blob error（!开头）用于承载较长文本的错误消息。不过目前这些类型在实际命令输出中使用较少，主流客户端主要适配的还是Map、Set、Double、Boolean和Push这五种。
协议切换实践与兼容性建议
Redis服务端默认仍以RESP2与客户端通信，即便服务端是7.x版本。客户端如果想使用RESP3，必须在连接建立后发送HELLO命令主动协商：
HELLO 3 # 服务端若支持，返回一个Map，其中proto字段为3 # 客户端想回退，发送 HELLO 2 即可切回RESP2
HELLO是RESP3体系的基石命令，它同时承担协议版本协商、身份认证（AUTH参数）和客户端信息设置的功能，可以完全取代旧的AUTH和CLIENT SETINFO组合。各大客户端库对HELLO的封装程度不同：Lettuce从6.x起支持hello(3)，go-redis v9默认就会尝试RESP3并在失败时回退，redis-py需要在实例化时传protocol=3。
升级兼容性方面有几点经验值得参考。第一，不要假设服务端一定支持RESP3，写客户端代码时要处理好HELLO失败后的降级路径；第二，RESP3下部分命令的返回结构发生了变化，比如HGETALL从数组变成Map，如果代码里直接按下标取值，切换协议后会直接出错，建议优先通过客户端库的类型映射接口访问；第三，一些中间件和代理（早期版本的Codis、部分Lettuce Pool实现）对RESP3支持不完善，生产环境切换前务必在预发环境验证全量命令的返回格式。理解了RESP的演变逻辑，你会发现Redis客户端的很多设计决策——连接独占、pipeline批量发送、订阅连接分离——其实都是协议特性的直接映射，掌握了协议，排查问题的眼界也会宽很多。