Redis（六）管道(Pipelining)

管道技术并不是Redis特有的，管道技术在计算机科学中有很多地方的应用。

来自wiki的解释：

In computing, a pipeline, also known as a data pipeline,[1] is a set of data processing elements connected in series, where the output of one element is the input of the next one. The elements of a pipeline are often executed in parallel or in time-sliced fashion. Some amount of buffer storage is often inserted between elements.

在计算机中，管道又叫做数据管道，是数据处理元件。一个元件的输出作为另一个元件的输入。管道中元素经常是并行或者是基于事件分片。在元素之间会插入缓冲区。

说白了就是传输计算元素。与计算机领域相关的管道非常多，其中平时应用开发中遇到的就是网络协议的HTTP pipelining。

HTTP Pipelining

HTTP pipelining is a technique in which multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses.[1]

HTTP pipelining是一种技术，多个HTTP请求基于一个TCP连接以无等待匹配的响应的方式被发送。

HTTP中引入pipelining主要是为了提高性能。在一些高延迟的网络中，如果需要等待上一个HTTP请求的响应后再发送下一个请求，那么网络延迟势必是性能瓶颈之所在。pipelining为了解决这个问题，即流水线式发送HTTP请求，client不等待上一个请求的响应，只要server端按照请求的顺序返回响应即可。这样虽然无法从根本上解决网络延迟的问题，但是却可以减少request/response这种模式带来的环回时间。

Pipelining带来了以下的优势：

• 如上所述，减少了多个请求的整体环回时间，提高了性能
• 对于server端，能够在单位时间内接收到更多的请求，在server性能满足的前提下，提高了server端的吞吐量

同样万物平衡，Pipelining也有很多限制：

• 请求之间应该保证无依赖，后一个请求不能依赖前一个请求的响应结果。这种场景不适合使用pipelining
• 非幂等性请求不能使用pipelining（如post请求），同样的post请求会改变资源的状态，在使用pipelining技术中，会导致不幂等

下图引用wiki和《HTTP权威指南》中关于HTTP pipelining的描述：

参考

Pipelining
HTTP pipelining
《HTTP权威指南》

Redis-Pipelining

在看完pipelining，相信大家对管道（流水线）技术有一个初识。下面再来看下它是如何在Redis中被应用，为什么应用。

• Redis Pipelining介绍
• Redis Pipelining解决的问题
• Jedis中Pipelining的使用
• Jedis中的Pipleling的Benchmark
• Redis Pipelining在项目实战中的应用

一.Redis Pipelining介绍

Redis是是一种client-server的request/response的模式，Redis有单独的TCP Server。

• client发送请求请求到server端，然后需要阻塞等待server端的响应
• server端处理请求然后返回响应给client

即如上中介绍的HTTP的request/response一样。在这种模式中，数据包必须从client发送到server端，然后再从server端返回到client端，这个时间叫做RTT（Round Trip Time）。

假设Redis Server每秒能处理100k请求，但是RTT是250ms，这样Redis Server实际每秒只能处理4个请求，而且这种影响会随着网络延迟越大而逐渐加剧。所带来的直接影响：

• 阻塞客户端线程或进程，消耗资源，大量请求时无疑降低client性能
• 降低server端的吞吐量

为了解决该问题，需要一种client无等待响应的方式发送请求至server的模式，即Redis pipelining。

Redis pipelining使得client能够无等待响应的方式连续发送多条命令请求至Redis Server端，然后Server端按照请求顺序返回响应结果，类似：

client> set k0 v0;
client> set k1 v1;
client> set k2 v2;
server> ok
server> ok
server> ok

二.Redis Pipelining解决的问题

从以上的Redis pipelining介绍中可以看出，Redis pipelining降低了高延迟网络中，request/response方式带来的请求应答的环回时间消耗：

• 无序等待响应的方式发送请求，减少等待时间（特别在高延迟网络中）
• 一次性返回响应，减少多次响应的带来的时间消耗

更重要的一点是，在request/response的方式中，逐次发送请求至server端，server端每次都需要read/write，这里的read/write是systcall，涉及到内核态和用户态的切换，非常消耗系统资源。Redis pipelining的方式尽量减少了这种系统状态的切换开销。

三.Jedis中Pipelining的使用

Pipelining急需要Redis Server端的支持又需要Redis client的支持。client需要能够不获取响应的情况下发送多个命令，server端需要编排好响应以请求的顺序返回给客户端。

Redis的经典Client jedis是支持Pipelining的。使用方式可以分为两种，获取响应方式也可以分为两种。

1.使用pipelining方式：

• 直接使用pipelining
• 在事务中使用pipelining

2.获取响应方式：

• 同步，一次性获取所有请求的响应，以list方式返回
• 同步，在调用pipelining的操作时，指定返回的响应

关于测试的代码和pipelining的api使用详情可以戮

四.Jedis中的Pipleling的Benchmark

前面第二节中分析Pipelining就是解决网络延迟，提高吞吐量。那么在使用Pipelining的情况下，相对于不使用的情况下，性能是否提高了？提高多少？

一切都需要用数据来说话。下面分别跑下测试，比较下。Jedis的测试案例中有Benchmark模块，这里直接使用其Pipelining和GetSet的Benchmark的测试程序：

执行命令数	ops(no pipelining/pipelining)
100	6666 ops/9090 ops
100000	26870 ops/316455 ops
1000000	28967 ops/422922 ops

从以上的可以看出使用Pipelining的情况下大致能提高20倍的性能。

五.Redis Pipelining在项目实战中的应用

首先认识下Pipelining的特点：

• 批量流水线发送
• 一次返回相应的响应

两个特点决定了应用场景必须有以下特点：

• 由于是批量流水线发送，所以每个请求之间需要无状态，即后请求不依赖前请求的响应结果
• 由于一次返回响应，所以响应中可能会存在有些请求命令执行成功，有些失败。所以应用场景必须能够容忍数据处理错误或者数据丢失的风险，或者能够接受通过其他机制弥补丢失或者错误的数据方式

一般适用于批量缓存数据或者预加载缓存数据。因为不需要逐条发送缓存的数据，可以pipelining方式发送。因为是缓存数据，缓存的场景能够容忍某一些数据缓存失败，无非是没有命中，再次加载单条加载至缓存。

最近在做一个业务数据预警检查的项目，采用责任链模式，将需要预警检查的每条数据遍历责任链，完成数据一致性校验检查。责任链中每个检查器都是可配置生效失效，而且支持可扩展检查器。扩展性、可配置型较强，但是带来的问题即每条需要预警检查的数据遍历责任链检查器时，都需要重复的查询一些其他的表数据与配置。这里从而引入了巨大的磁盘I/O，产生性能瓶颈。

后来想如果，能将这些其他表的数据预加载进入缓存中，每次遍历需要预警检查的数据时，不从DB中查询获取，直接从缓存中获取即可。由于服务是集群的，所以需要使用分布式缓存且本地缓存容量有限。

这里最终采用懒加载的方式缓存其他表的数据或者配置，在预警检查第一条数据时，各个检查器将其他表的数据或者配置加载到缓存中，同时采用pipelining模式缓存到Redis中。

这样下条预警数据的遍历检查器时，每个检查器从缓存中获取其他表的数据或者配置即可。大幅度减少DB带来的I/O，突破性能瓶颈。

转载于:https://www.cnblogs.com/lxyit/p/9829091.html