1. 从常见性能瓶颈说起聊天应用为什么会盯上RESP协议做聊天应用的朋友基本都经历过这样的阶段功能越加越多用户量慢慢起来然后某一天线上告警突然弹出消息延迟飙到几百毫秒Redis的CPU先顶着不住了。我接手的一个开源聊天项目就卡在这个节点上。一开始架构很简单客户端走WebSocket连到网关网关把消息写进Redis做持久化和离线推送同时通过发布订阅广播给在线用户。所有消息的序列化格式用的是JSON——当时图省事没想太多结果瓶颈恰好就藏在图省事这三个字里。排查下来问题很清晰网关和Redis之间的通信占了大量CPU开销。为什么JSON序列化和反序列化在字符串和字节之间来回折腾字段名反复解析嵌套结构要递归处理。压测数据显示在每秒接入上万条消息时JSON库的CPU占用可以占到网关进程总CPU的40%以上。而Redis客户端到服务器之间的链路早就走的是RESP协议也就是Redis Serialization Protocol——一个极致轻量的文本协议。一个念头冒出来如果网关之间、网关和内部服务之间的通信也改成RESP而不是JSON会不会把CPU从序列化这个无底洞里救出来答案是肯定的而且效果远超预期。但这并不是把JSON替换成RESP的简单找平真正动手之后才发现RESP协议在聊天场景里能发挥的作用远比省CPU要大得多。它有一套自己的类型系统有它自己的语义连在长连接场景下的调试体验都完全不一样。这篇文章就按我从选型、改造、压测到踩坑的全过程展开讲里面不少结论是用真金白银的线上故障换回来的希望能给你省点弯路。先说结论如果你也在做IM、直播弹幕、或者物联网指令下发这类以短消息为主、连接数多、要求低解析成本的服务RESP协议值得在选型时放进候选名单。它本身是Redis序列化协议的缩写诞生于2009年最初只是Redis服务器和客户端之间的一套文本协议却因为设计得足够规整、紧凑天然适合在高频、小型数据包场景里做内部微服务的通信格式。2. RESP协议的本质优势它到底比JSON省在哪了2.1 协议格式的底层设计类型前缀让解析器可以逐字节推进RESP的核心设计非常简单每种数据类型都由一个单字节前缀表示表示简单字符串例如OK\r\n-表示错误信息例如-ERR unknown command\r\n:表示整数例如:1000\r\n$表示批量字符串长度由前置数字指定例如$3\r\nabc\r\n*表示数组例如*2\r\n$1\r\na\r\n$1\r\nb\r\n还有对应的带错误标志的批量字符串!、带空值的_、带浮点数的,等等消息的边界是明确的\r\n这意味着解析器不需要像JSON那样读一个左大括号然后在内部不断寻找对应的右大括号逐级递归地匹配结构。它是逐行推进的一行读完毕这一行的含义就完整了不需要上下文依赖。数据被解析器消费时是线性的不需要构建中间AST抽象语法树。JSON解析器的工作方式是先将整段字节流拆成结构填入一个树形对象再遍历这棵树生成目标对象。RESP则是流式的读到$就知道下一段是定长字节流直接按长度截取无需维护栈状态也没有括号配对的问题。这带来的直接收益在极端场景下特别明显当一条消息只有几十字节时JSON解析要走完整个嵌套逻辑而RESP解析器通常只是两次memcpy级别的复制。2.2 密集消息场景下少了什么JSON格式有天然的文字冗余。一条简单的消息{type:chat,room:room-123,from:user-42,content:hello,ts:1700000000}同样的信息用RESP批量字符串数组来表达*5\r\n$4\r\nchat\r\n$7\r\nroom-123\r\n$7\r\nuser-42\r\n$5\r\nhello\r\n$10\r\n1700000000\r\n在字节长度上JSON用了74字节RESP用了约64字节。压缩不多大概13%。但真正的差距不在bytes上而在解析器需要执行的指令数上。JSON解析器每读到一个引号都要判断是否转义每出现一个冒号都有键值的分派逻辑字段存在性和类型检查也要逐一过。RESP的解析器几乎不需要判断类型之外的东西。我这里有一组在相同服务器配置下做过的数据单条消息负载长度不同消息体大小JSON解析耗时微秒RESP解析耗时微秒CPU占用下降32字节1.020.3862.7%128字节1.450.5661.4%512字节2.301.0156.1%2KB5.182.8744.6%消息体越小RESP的解析优势越明显这正好撞在聊天场景的需求上。IM里大量消息都是几十字节到几百字节的短消息RESP的赢面最大。2.3 流式解析能力对长连接的意义聊天应用的核心是长连接消息本质上是双向的字节流。RESP天然支持流式处理你不需要等完整的消息体到达才能开始处理可以边接收边解析。每条消息以\r\n结尾解析器拿到消息边界就立刻回调上层逻辑。这一点在WebSocket网关里尤其舒服网关把WebSocket帧拆开内部再组RESP消息处理完一帧推给下一个节点整条流水线是管道式的。JSON要达到同样的流式效果就要额外上增量解析incremental parsing之类的复杂手段而且实现难度和维护成本都很高一般项目根本不会为了这个去引第三方库。3. 改造网关消息层从JSON迁移到RESP的具体过程3.1 设计目标与消息结构定义我先声明一个前提迁移到RESP并不意味着我们完全抛弃JSON。对外API、WebSocket客户端的payload依然保留JSON——客户端生态成熟没有必要动。我们动的是网关到网关、网关到Redis、网关到推送服务之间这些内部链路的通信格式。设计内部消息结构时我们没有按原始字段逐个映射而是定义成了一张规范表。因为Redis集群会话存储中每个Key的Value实际上是一个RESP数组如果网关侧直接把消息映射成RESP数组那么写Redis和相互转发的逻辑就能完全复用一套编码器。我们定义了以下类型常量1聊天消息chat message2系统通知system notification3回执确认ack4心跳heartbeat5离线消息请求offline fetch6群成员变更member change每条消息统一编码为RESP数组第一个元素是消息类型整数第二个元素是房间ID字符串第三个元素是发送者ID字符串第四个元素是消息内容字符串第五个元素是时间戳整数。结构示例如下*5\r\n:1\r\n$8\r\nroom-123\r\n$7\r\nuser-42\r\n$5\r\nhello\r\n:1700000000\r\n这样定义的好处是每个字段的位置是固定的解析器可以按索引直达某个字段不必做键查找。虽然RESP本身没有键概念但我们在应用层把位置当成了隐式键。3.2 各语言网关的RESP编解码实现我所在的团队网关语言比较混杂核心网关是Go后续加的Python节点跑算法类逻辑客户端SDK有Java版。RESP的编解码器在三个语言里都只花了不到一百行代码。Go版本的编码器核心思路是把所有消息统一走一个bytes.Buffer用fmt.Fprintf的形式拼出带长度的字节序列尽量避免字符串拼接产生的临时对象。解码器则利用bufio.Reader.ReadString(\n)读行按前缀分派处理。下面是我们Go网关中的解码器骨架func DecodeRESP(r *bufio.Reader) (interface{}, error) { line, err : r.ReadString(\n) if err ! nil { return nil, err } prefix : line[0] switch prefix { case : return line[1 : len(line)-2], nil case -: return RESPError{Message: line[1 : len(line)-2]}, nil case :: return strconv.ParseInt(strings.TrimSpace(line[1:]), 10, 64) case $: n, _ : strconv.Atoi(strings.TrimSpace(line[1:])) if n -1 { return nil, nil } buf : make([]byte, n2) if _, err : io.ReadFull(r, buf); err ! nil { return nil, err } return buf[:n], nil case *: n, _ : strconv.Atoi(strings.TrimSpace(line[1:])) arr : make([]interface{}, n) for i : 0; i n; i { v, err : DecodeRESP(r) if err ! nil { return nil, err } arr[i] v } return arr, nil } return nil, fmt.Errorf(unknown RESP prefix: %c, prefix) }编码器相对简单分类拼字节就好了func EncodeArray(items ...interface{}) []byte { buf : new(bytes.Buffer) buf.WriteString(fmt.Sprintf(*%d\r\n, len(items))) for _, item : range items { encodeItem(buf, item) } return buf.Bytes() } func encodeItem(buf *bytes.Buffer, item interface{}) { switch v : item.(type) { case string: buf.WriteString(fmt.Sprintf($%d\r\n%s\r\n, len(v), v)) case int64: buf.WriteString(fmt.Sprintf(:%d\r\n, v)) case []byte: buf.WriteString(fmt.Sprintf($%d\r\n, len(v))) buf.Write(v) buf.WriteString(\r\n) } }Python节点的实现稍微考验性能因为Python本身就不是以字节操作见长。我们的选择是不用纯Python手写RESP而是直接复用现有Redis库redis-py自带的RESP编解码底层redis-py在处理StrictRedis的execute_command时底层就是RESP序列化在这之上包一层我们自己的消息封装。3.3 Redis侧读写路径的打通改造过程中最关键的一步是把网关间的相互转发和Redis的存储统一走同一套RESP编码。这里有个小技巧Redis本身暴露的网络协议就是RESP所以客户端库发出的命令天然也是RESP序列化的。我们网关发往Redis的指令如果把Payload直接作为Redis Key的Value那么Redis命令本身的RESP结构加上Value的RESP编码是嵌套的*3\r\n$3\r\nSET\r\n$5\r\nmsg:1\r\n$12\r\n*5\r\n:1\r\n...\r\nRedis存储层拿到的Value就是一个RESP数组字符串取出来时可以直接透传。这意味着我们在网关A编码好的消息存进Redis后网关B从Redis读出来不需要任何反序列化就能直接原样推送。这对于离线消息、消息漫游这类要求存什么发什么的场景省掉了一层编解码延迟和数据转换的开销都压低了。这里要特别说明一下在使用Redis的LIST结构做消息队列时每个LPUSH的元素同样可以塞RESP字节流消费者BRPOP取出来就是消息原文无需二次解析。而且因为RESP自带长度前缀即使消息里包含换行符、二进制内容也不会破坏边界。这一点在实际的聊天消息里太关键了——用户发一条带换行、带表情符号、带特殊字符的消息JSON格式在传输层需要转义RESP用长度前缀直接把整块内容兜住。4. 压测实录连接数、消息长度和CPU开销的实测数据4.1 整个压测环境是怎么搭的为了验证RESP改造的实际收益我在内部搭了一套对比压测环境。两台配置完全一致的物理机Intel Xeon E5-2680 v4单机64GB内存。一台跑网关Linux一台跑Redis同样的Linux内核版本。压测工具用Go写了个简单的WebSocket客户端模拟器并发连接从5000到5万递增每连接随机发送房间ID和消息内容消息长度控制在16到256字节之间。压测脚本用客户端模拟器每秒向网关发送固定数量的消息网关通过内部RESP协议转发给Redis再由Redis发布订阅推回给其他在线客户端。整个过程分成JSON协议版本和RESP协议版本两组每组压测跑10分钟取稳定段的数据。4.2 两条关键曲线CPU利用率和P99延迟下面是同一批压测数据中摘取的关键对比。以每秒10万条消息的吞吐为例指标JSON协议版本RESP协议版本变化网关单核CPU占用61%38%下降37.7%Redis服务器CPU占用12%9%下降25%网关平均解析耗时1.98微秒0.63微秒下降68.2%P99消息投递延迟8.2ms5.1ms下降37.8%内存分配次数每秒3.4万次1.8万次下降47%CPU下降是符合预期的但内存分配次数下降也值得注意。JSON解析需要为字符串、字段名、堆对象做大量分配RESP解析器只需在批量字符串处分配一次性缓冲。内存分配减少意味着垃圾回收的停顿也减少这在Go这种带GC的语言里影响很大。我们在压测日志里直接观察到GC暂停次数在RESP版本下降了一半以上。延迟数据同样明显。P99从8.2毫秒压到5.1毫秒等于单条消息在内部链路上省了3毫秒。这对于聊天场景来说体感非常明显——特别是群聊场景里一份消息要扇出给多个接收方每个接收方都要读取并转发一份RESP编码省下的延迟是叠加的。4.3 短连接与消息扇出场景的特殊收益聊天场景里有一类容易被忽略的负载新用户上线时拉取离线消息。网关要把用户离线期间的几百条消息从Redis里一批批捞出来依次推送。在JSON版本里每条消息都要从存储的JSON字符串完整反序列化成一个对象再把对象重新序列化成JSON推给客户端来回两次转换CPU翻一倍。RESP版本里从Redis取出的就是RESP字节流如果客户端本身也支持RESP我们自研的App和桌面端都支持可以直接原样透传连转换为省掉了。还有消息扇出一个500人的房间里用户A发一条消息网关要把消息推给499个在线用户。JSON版本里网关每推送一个用户就需要把对象重新序列化一次假设序列化耗时是2微秒那么扇出成本是998微秒。RESP版本里编码一次得到字节流之后499次推送直接复用同一段内存扇出成本只有约500微秒主要花在TCP发送上CPU意义上接近零。5. 迁移路上踩过的坑RESP不是Redis专属但也没你想的那么万能5.1 自建解析器与Redis官方协议的不兼容问题第一个坑来自我自己对RESP文档细节的忽视。一开始我直接照搬Redis的RESP实现来解析消息但Redis客户端和服务端之间有ANONYMOUS协议栈虽然RESP2里只定义了简单字符串、错误、整数、批量字符串、数组这五种类型实际上服务器回包还包含一些特殊形态比如命令执行错误时返回的是-ERR行而在旧版本里有些命令回的是*-1这样的空数组。如果只按官方文档实现而没做兼容某些垃圾输入或异常回包会把解析器打崩。解决方法是解析器做了严格容错遇到未知前缀就返回错误并跳过当前块而不是panic。同时所有解析错误都输出到错误计数通道方便排查线上异常。5.2 RESP没有键值结构字段顺序变更容易翻车RESP本质上没有Map/Dict类型只有数组。如果你要传递的是结构化对象你得靠第几个元素是什么的约定来还原。这在跨团队协作时很容易翻车——别人新增一个字段直接在数组中间插一位你解析器还在按旧索引取字段取到的是错位的数据bug藏得很深。我们的规矩是内部消息以消息类型为维度每个类型的字段布局写进统一的协议文档并加上单元测试锁定索引位置。新增字段必须在数组尾部追加禁止在中间插入。同时限定了最大数组长度默认64超过就断开连接防止畸形消息导致内存膨胀。5.3 与Redis语义的混淆命令和数据的边界RESP协议既被Redis用作命令请求格式又被用作数据存储格式这两个场景语义不同。Redis做命令请求时数组的第一个元素是命令名SET、GET、PUBLISH等后续元素是参数。但我们的聊天消息里第一个元素是消息类型整数。如果网关层误把这个数组原样当成Redis命令发给RedisRedis会试图把整数当成命令名执行直接报错。这个问题听起来低级但实际发生在某个版本上我们为了走捷径把消息体直接塞给Redis PUBLISH命令的参数位结果PUBLISH的第2个参数必须是频道名第3个参数才是消息传参位置错了一位整个消息被发布到了错误的频道。排查了大半天最后靠记录Redis的MONITOR输出才定位到。5.4 长连接场景下的心跳协议设计RESP没有内建心跳帧。在长连接场景里必须应用层自己设计心跳。我们用的是RESP整数简单字符串的复合:4\r\nPING\r\n这样既可以通过整数帧识别心跳类型又可以用字符串携带额外的存活标记。心跳间隔设了30秒客户端在15秒内没有任何其他消息时必须主动发心跳网关如果60秒没收到任何有效RESP帧会直接断开连接。这里有个细节因为RESP是按\r\n分割的流协议心跳帧必须保持严格的帧完整性不能跨TCP包解析。我们内部在连接上封装了一层帧缓冲每收到一个完整RESP帧才交给上层处理避免半包问题。5.5 客户端兼容性老版本SDK怎么过渡我们移动端的老版本SDK一直是收发JSON的升级RESP需要版本兼容。上线策略是新协议期间网关对旧客户端一律返回JSON。网关维护一张客户端版本号到协议类型的映射表版本号大于等于3.2的客户端走RESP老版本走JSON。内部网关之间则始终走RESP。这样设计的好处是老客户端的消息进入网关时先由网关解析成内部RESP标准消息再转发到新的RESP链路。新客户端收到的始终是RESP。等到老版本客户端自然淘汰完网关里再删掉JSON的序列化/反序列化路径顺便又省一截CPU。6. 深度思考RESP协议的适用边界和后续演进思路6.1 RESP适合的协议画像RESP协议不是银弹。它的强项集中在三种场景里短小频繁的消息几十字节到几百字节的高频指令解析开销被压到最低明确且固定的字段布局字段数量不多且位置可固定无需键名字符串需要流式解析的长连接网关节点间相互转发或网关和Redis等存储层直接交换数据相反如果消息是嵌套很深的结构化数据、字段数量庞大且经常变动RESP就变成了负担。你要维护一份约定客户端要用约定的索引还原结构一旦结构变了所有下游解析器都要同步改。这种场景JSON或MessagePack依然更合适。6.2 与MessagePack、Protocol Buffers的横向比较既然聊到协议选型RESP免不了和另外两个常客比较。MessagePack是二进制的JSON字段名仍然要保留一定的映射成本。Protocol Buffers需要事先定义.proto文件生成代码虽然编解码效率极高但是动态修改协议要重新生成代码、重新编译、重新发布改造成本高。RESP是纯文本的调试友好telnet直接连端口就能看到可读协议流在定位问题上天然有优势。选型时要权衡的其实不是哪个最快而是哪个最快且最省事。RESP不需要额外的IDL接口描述语言不需要代码生成器一个解析器几十行就写完在任何语言里都能5分钟内跑通。这在快速迭代的团队里很加分。6.3 RESP3的演化和我们能借用什么Redis 6.0引入了RESP3协议相比RESP2增加了一些类型Map、Set、Double、Boolean、Big Number、Verbatim String、Streamed String等。其中对我们比较有用的是Map类型直接提供了键值结构避免了RESP2里用数组模拟map的错位问题。另一个是Push类型可以直接实现服务端向客户端的主动消息推送——这和我们聊天网关的推送语义非常吻合。不过RESP3的完整特性目前只在Redis客户端支持得比较完善自建协议如果想用Map和Push需要自己实现解析器。由于我们的内部链路没有历史包袱我倾向于在后续版本里升级到RESP3的子集保留数组作为基础类型、新增Map类型用于房间元数据、新增Push类型用于服务端主动通知。等于在不破坏现有消息结构的基础上补上RESP2缺失的能力。6.4 从RESP迁移中总结出的协议设计方法论这次改造给我最大的收获不是RESP本身而是协议设计与业务形态对齐这个思维。聊天消息的特征是数量巨大、单条极小、字段固定、有实时性要求。RESP恰好把这三个特征全占了。你再去看物联网场景、远程调用场景其实也都能找到对应的协议。具体可以沉淀出这样几条方法论协议选型永远以业务消息的大小分布和频率分布为第一参考而不是以团队的熟悉度如果协议自带类型系统尽量让协议类型直接映射业务实体而不是另起一套抽象层减少转换无论选什么协议字段变更流程都要有明确的兼容性纪律。RESP用位置约定字段那位置从哪天起就永远不许变解析器必须要能容忍未知字节宁可跳过和报错不能把异常输入当成合法数据继续处理7. 最后的落地感受这套改造值不值讲点更实在的。如果你还没动手我只能说改造RESP的过程里80%的时间其实花在协议设计而非编码上。一旦把字段布局定好、解析器写完剩下的就是把现有链路里所有对象转JSON的站点替换成按字段顺序塞进RESP数组。我们的线上数据在迁移后至今大概跑了一年多Redis CPU峰值下降约30%网关CPU峰值下降约40%。之前为了扛高峰时常要临时扩容两到三倍的网关实例RESP改造后同配置下没有再发生过CPU告警。更实际的价值是因为RESP编码天然自带长度前缀曾经出现过一次服务端生成了超长消息体导致内存溢出的隐患排查时一看到RESP帧结构就能直接定位是哪个字段越界了。按我个人的体会RESP这波改造的收益曲线是U型的改造前期要写协议定义、改网关、改SDK看不到明显收益中途数据开始好看了CPU曲线往下掉到最后稳定运行时反而开始怀念JSON的调试便利因为RESP的文本虽然可读但没有键名抓包时得对着字段索引表才能看懂。但是当你在深夜排查线上推送延迟问题时翻出字段表对着协议文档定位的速度比翻JSON嵌套结构要快得多。如果你也想尝试我的建议是先在一条独立的内部链路上做验证——比如网关到推送服务这段流量可控、出问题影响面小。跑顺了再推广到网关到Redis的存储链路最后才是客户端SDK。客户端侧的升级尽量做灰度通过版本号路由到新旧协议确保老用户不受影响。最后分享一个我踩过几次坑之后才养成的习惯做协议迁移时一定要保留一段时间的双写比对——新旧代码同时解析同一份输入把结果对比一遍再决定是否切流量。RESP迁移中我们靠这个抓到了至少三个字段错位的隐性bug如果没有双写比对这些bug上线后大概率要等大促流量高峰才会暴露。稳妥永远比炫技重要。
