另一方面，pipeline出现的背景： redis客户端执行一个指令可以分为四个过程：
发送命令- )命令队列- )命令执行- )返回结果的过程称为Roundtriptime(RTT，缩写为往返时间)，mget mset有效地节省了RTT，但大多数命令(例如hgetall ) 这种情况下需要pitt
二、pepeline的性能1、不使用pipeline执行n条指令
2、使用pipeline执行了n条指令
3、两者性能比较
三、本机批处理命令(mset，mget )与Pipeline的对比1、本机批处理命令是原子性的，Pipeline是非原子性的
原子性概念：的一个事务是不可分割的最小工作岗位，要么成功要么失败。 原子操作意味着你的商业逻辑必须是不可分割的。 处理一件事要么成功，要么失败，原子是不可分割的)
2、本机批处理命令命令多个密钥，pipeline支持多个命令，是非原子的
3、本地批处理命令由服务端实现，但pipeline需要服务端和客户端共同完成
四、Pipeline的正确使用方法使用Pipeline组装的指令数量不能太多。 否则，数据量太大，客户端等待时间增加，网络也可能被阻止。 可以分割完成大量指令的多个小Pipeline指令。
五、虽然命令行上没有介绍Redis的pipeline (管道)功能，但Redis支持pipeline，每个语言版本的客户端都有相应的实现。 如果网络开销延迟client使用pipelining发送命令，则redis server必须对某些请求进行排队，如果执行完成后有很多已发送的命令同时发送结果，则返回的结果当然，使用的内存也会增加。
Pipeline在一些场合非常方便。 例如，如果多个command需要提交到“及时的”，而且他们不相互依赖于相应的结果，也不需要立即得到对结果的响应，则Pipeline将该“http://www.com /”
但是，如果批处理Pipeline指令集庞大，则http://www.Sina.com/但pipeline实际上允许的操作数量是套接字输出缓冲区大小它还意味着每个redis-server同时支持的pipeline链路的数量有限，这仅限于服务器物理内存或网络接口的缓冲能力。
Redis使用的是主要是 TCP 连接中减少了“交互往返”的时间和pipeline 期间将“独占”链接，此期间将不能进行非“管道”类型的其他操作，直到 pipeline 关闭；。 也就是说，下一个请求通常遵循以下步骤：
客户端向服务端发送查询请求并接收套接字的响应。 通常在阻塞模式下等待服务端的响应。 服务端处理命令，并将结果返回给客户端。 Redis客户端和Redis服务器之间使用TCP协议连接，一个客户端可以在一个套接字连接上启动多个请求命令。 发出每个请求命令后，客户端通常会阻止并等待redis服务器的处理，并在redis处理请求命令后通过响应消息将结果返回给客户端。如果要运行多个命令，则客户端必须等待上一个命令的执行完成例如：
执行步骤如下图所示。
由于通信存在网络延迟，客户端和服务器之间的分组传输时间需要0.125秒。 那么，上面的三个命令六条消息至少需要0.75秒。 这样，redis一秒钟可以处理100个命令，而我们的客户端一秒钟只能发出4个命令。 这显然没有充分利用redis的处理能力。
另一方面，“管线”(pipeline )可以一次发送多个命令，并在执行后一次返回结果。为了不干扰链接中的其他操作，你可以为 pipeline 操作新建 Client 链接，让 pipeline 和其他正常操作分离在2个 client 中Pipeline的默认同步数为53个。 也就是说，在arges中累积53个数据时提交数据。 该过程如下图所示。 客户端可以将三个命令组合成一条tcp消息发送，服务器可以将三条命令组合成
令的处理结果放到一个 tcp 报文返回。需要注意到是用 pipeline 方式打包命令发送，redis 必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。具体多少合适需要根据具体情况测试。
六、适用场景
有些系统可能对可靠性要求很高，每次操作都需要立马知道这次操作是否成功，是否数据已经写进 redis 了，那这种场景就不适合。
还有的系统，可能是批量的将数据写入 redis，允许一定比例的写入失败，那么这种场景就可以使用了，比如10000条一下进入 redis，可能失败了2条无所谓，后期有补偿机制就行了，比如短信群发这种场景，如果一下群发10000条，按照第一种模式去实现，那这个请求过来，要很久才能给客户端响应，这个延迟就太长了，如果客户端请求设置了超时时间5秒，那肯定就抛出异常了，而且本身群发短信要求实时性也没那么高，这时候用 pipeline 最好了。
七、管道（Pipelining） VS 脚本（Scripting）大量 pipeline 应用场景可通过 Redis 脚本（Redis 版本 >= 2.6）得到更高效的处理，后者在服务器端执行大量工作。脚本的一大优势是可通过最小的延迟读写数据，让读、计算、写等操作变得非常快（pipeline 在这种情况下不能使用，因为客户端在写命令前需要读命令返回的结果）。
应用程序有时可能在 pipeline 中发送 EVAL 或 EVALSHA 命令。Redis 通过 SCRIPT LOAD 命令（保证 EVALSHA 成功被调用）明确支持这种情况。