Redis -- Pipeline

消息交互

一次操作

客户端将请求传送给服务器,服务器处理完后再将响应回复给客户端,这需要花费一个网络数据包来回的时间

多次操作

连续执行多条指令,会花费多个网络数据包来回的时间

在客户端代码层面,需要经历写-读-写-读才能完整地执行完两条指令,如果将顺序调整为写-写-读-读,两个指令同样能够正常完成
两个连续的写操作和两个连续的读操作总共只会花费一次网络来回,看起来像合并了一样
管道操作的本质:客户端通过改变管道中指令列表的读写顺序,可以大福节省IO时间,管道中的指令越多效果越好

管道本质

网络交互

  1. 客户端进程调用write函数将消息写到操作系统内核为套接字分配的发送缓冲send buffer
  2. 客户端操作系统内核将发送缓冲的内容发送到网卡,网卡硬件将数据通过网际路由送到服务器的网卡
  3. 服务器操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer
  4. 服务器进程调用read从接收缓冲中取出消息进行处理
  5. 服务器进程调用write将响应消息写到内核为套接字分配的发送缓冲send buffer
  6. 服务器操作系统内核将发送缓冲中的内容发送到网卡,网卡硬件将数据通过网际路由送到客户端的网卡
  7. 客户端操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer
  8. 客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑进行处理

解析

  1. write函数只负责将数据写到操作系统内核的发送缓冲,如果发送缓冲了,那么需要等待,这是写操作IO操作的真正耗时
  2. read函数只负责将数据从操作系统内核的接收缓冲取出来,如果接收缓冲是的,那么需要等待,这是读操作IO操作的真正耗时
  3. 对于value = redis.get(key)这个请求来说
    • write操作几乎没有耗时
      • 写到发送缓存就返回
    • read比较耗时
      • 因为需要等待消息经过网络路由到达目标机器处理后的响应消息,再回送到当前的内核接收缓冲才可以返回
  4. 对于管道来说
    • 连续的write操作没什么耗时
    • 之后第一个read操作会等待一个网络的来回开销
      • 然后所有的响应消息就已经回送到内核的接收缓冲了,后续的read操作直接可以从接收缓存中取出结果,速度非常快
0%