用Redis通信协议搞效率，感觉数据传输快了不少，聊聊这套路

直接聊聊用Redis通信协议这事儿吧,我是从咱们社区里一个老哥的实战帖子里看到的思路（来源：某技术社区用户“CacheWalker”的分享帖《别老想着上HTTP，有些时候Redis协议更麻利》），他说一开始他们内部服务调用全走的HTTP，JSON打包拆包，感觉也没啥，后来量上来了，机器吭哧吭哧的，CPU老是忙着解析那些个格式，有一回压测，他看着监控图就琢磨，这数据净在“打包”和“拆包”这两件事上转悠了，真到干活的时间反而被挤占了。

后来他就试了试直接用Redis的通信协议,也就是RESP（Redis Serialization Protocol），这玩意儿特别直白，比如你要发个命令“GET foo”，实际发出去的是这么一串东西： "2\r\n$3\r\nGET\r\n$3\r\nfoo\r\n" 看着乱是吧？其实规矩特简单：星号后面跟数字表示这个命令有多少个部分；美元符号$后面跟数字表示接下来这个部分的长度；然后就是具体的命令或键名，每段都用\r\n（回车换行）隔开，服务器按这个格式，能像切豆腐一样，又快又准地把你的意图拆分开，根本不用像解析JSON那样去猜括号、引号配没配对。

他这么一改,效果立竿见影，用他的原话说：“感觉数据传输快了不少，跟开了条专用车道似的。” 为啥呢？我琢磨着，主要是几个原因，第一，协议简单，解析起来快得飞起，对CPU特别友好（来源：同帖中楼主对比的压测数据，解析耗时降至约HTTP+JSON方式的1/8），第二，它是基于TCP的，而且是请求-响应一轮一轮的，虽然不像HTTP/2还能多路复用，但它自己设计得紧凑啊，一个来回没多少废话，第三，很多语言都有现成且高效的RESP实现库，甚至你自己都能照着格式拼字符串，几乎没啥学习成本。

这招不是啥场合都管用,那位老哥也强调了（来源：同帖后续讨论），这适合内部服务之间，大家知根知底，而且通信模型比较像“你问我答”这种简单命令式的场景，比如A服务让B服务赶紧查个东西、设个值，或者搞个简单的队列，你要是非得传个嵌套几十层、结构超级复杂的业务对象，那还是得上更专业的序列化方式，但很多内部操作，其实就只是“把那东西给我”、“把这东西存了”这么简单。

说白了,这套路的核心就是“别整太复杂”，当你的服务之间需要频繁地、快速地传递一些简单的指令和小块数据时，绕开那些为通用性而设计得比较“重”的协议（比如HTTP加上XML/JSON这种文本格式），转而采用为高效而生的、更“裸”的协议，就像从挤公交换成了骑电动车，在熟悉的街巷里穿行，灵活又直接，它让你想起了编程里最本质的东西：少即是多，直接就是最快，不过别忘了，上了这条快车道，服务间的耦合方式、监控手段也得跟着变一变，毕竟这已经不是“标准大路”了。