redis 管道

ps:读redis掘金小册

pipe管道命令

  管道命令本质上是为了减少网络io交互产生的,其实现是在客户端实现的,客户端将多个请求并到一起发送,然后一起返回,有效减少了io次数。
  这便是管道操作的本质,服务器根本没有任何区别对待,还是收到一条消息,执行一条消息,回复一条消息的正常的流程。客户端通过对管道中的指令列表改变读写顺序就可以大幅节省 IO 时间。管道中指令越多,效果越好。
  我们可以用: redis-benchmark -t set -P 2 -q来进行压测,看看其QPS。

io操作真正的耗时点在哪里

1.客户端进程调用write将消息写到操作系统内核为套接字分配的发送缓冲send buffer。

2.客户端操作系统内核将发送缓冲的内容发送到网卡,网卡硬件将数据通过「网际路由」送到服务器的网卡。

3.服务器操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。

4.服务器进程调用read从接收缓冲中取出消息进行处理。

5.服务器进程调用write将响应消息写到内核为套接字分配的发送缓冲send buffer。

6.服务器操作系统内核将发送缓冲的内容发送到网卡,网卡硬件将数据通过「网际路由」送到客户端的网卡。

7.客户端操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。

8.客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑进行处理。

  我们开始以为 write 操作是要等到对方收到消息才会返回,但实际上不是这样的。write 操作只负责将数据写到本地操作系统内核的发送缓冲然后就返回了。剩下的事交给操作系统内核异步将数据送到目标机器。但是如果发送缓冲满了,那么就需要等待缓冲空出空闲空间来,这个就是写操作 IO 操作的真正耗时。

  我们开始以为 read 操作是从目标机器拉取数据,但实际上不是这样的。read 操作只负责将数据从本地操作系统内核的接收缓冲中取出来就了事了。但是如果缓冲是空的,那么就需要等待数据到来,这个就是读操作 IO 操作的真正耗时。

  所以对于value = redis.get(key)这样一个简单的请求来说,write操作几乎没有耗时,直接写到发送缓冲就返回,而read就会比较耗时了,因为它要等待消息经过网络路由到目标机器处理后的响应消息,再回送到当前的内核读缓冲才可以返回。这才是一个网络来回的真正开销。

  而管道操作就是只用等一个网路来回从而减少时间开销,实际上减少了多余的通信次数。