会用redis吗？那还不快来了解下redis protocol

简介

redis是一个非常优秀的软件，它可以用作内存数据库或者缓存。因为他的优秀性能，redis被应用在很多场合中。

redis是一个客户端和服务器端的模式，客户端和服务器端是通过TCP协议进行连接的，客户端将请求数据发送到服务器端，服务器端将请求返回给客户端。这样一个请求流程就完成了。

当然在最开始的时候，因为用的人很少，系统还不够稳定，通过TCP协议传输的数据不规范的。但是当用的人越来越多，尤其是希望开发适用于不同语言和平台的redis客户端的时候，就要考虑到兼容性的问题了。

这时候客户端和服务器端就需要一个统一的交互协议，对于redis来说这个通用的交互协议就叫做Redis serialization protocol(RESP)。

RESP是在Redis 1.2版本中引入的，并在Redis 2.0中成为了与 Redis 服务器通信的标准方式。

这就是说，从Redis 2.0之后，就可以基于redis protocol协议开发出自己的redis客户端了。

redis的高级用法

一般来说，redis的客户端和服务器端组成的是一个请求-响应的模式，也就是说客户端向服务器端发送请求，然后得到服务器端的响应结果。

请求和响应是redis中最简单的用法。熟悉redis的朋友可能会想到了两个redis的高级用法，这两个用法并不是传统意义上的请求-响应模式。

到底是哪两种用法呢?

第一种就是redis支持pipline，也就是管道操作，管道的好处就是redis客户端可以一次性向服务器端发送多条命令，然后等待服务器端的返回。

第二种redis还支持Pub/Sub，也就是广播模型，在这一种情况下，就不是请求和响应的模式了，在Pub/Sub下，切换成了服务器端推送的模式。

Redis中的pipline

为什么要用pipline呢？

因为redis是一个典型的请求响应模式，我们来举个常见的incr命令的例子：

Client: INCR X Server: 1 Client: INCR X Server: 2 Client: INCR X Server: 3 Client: INCR X Server: 4

事实上客户端只想得到最终的结果，但是每次客户端都需要等待服务器端返回结果之后，才能发送下一次的命令。这样就会导致一个叫做RTT(Round Trip Time)的时间浪费。

虽然每次RTT的时间不长，但是累计起来也是一个非常客观的数字。

那么可不可以将