请将上一学习教程中的所有示例代码写在github:https://github.com/selfconzrr/redis _ learning中
虽然命令行中没有Redis的pipeline功能，但Redis支持pipeline，并且支持每种语言版本的客户端。 如果网络开销延迟client使用pipelining发送命令，则redis server必须对某些请求进行排队，如果执行完成后有很多已发送的命令同时发送结果，则返回的结果当然，使用的内存也会增加。
Pipeline在一些场合非常方便。 例如，如果多个command需要提交到“及时的”，而且他们不相互依赖于相应的结果，也不需要立即得到对结果的响应，则Pipeline将该“http://www.com /”
但是，请注意，pipeline之间链接为“独占”，在pipeline退出之前不能进行“管道”以外的操作。 如果你的pipeline指令集很大，那么批处理但是pipeline事实上允许的操作数量与返回套接字输出缓冲区大小/结果的数据大小有很大关系； 它还意味着每个redis-server同时支持的pipeline链路的数量有限，这仅限于服务器物理内存或网络接口的缓冲能力。
(一)个人资料Redis使用主要是 TCP 连接中减少了“交互往返”的时间和为了不干扰链接中的其他操作，你可以为 pipeline 操作新建 Client 链接，让 pipeline 和其他正常操作分离在2个 client 中。 也就是说，下一个请求通常遵循以下步骤：
客户端向服务端发送查询请求并接收套接字的响应。 通常在阻塞模式下等待服务端的响应。 服务端处理命令，并将结果返回给客户端。 Redis客户端和Redis服务器之间使用TCP协议连接，一个客户端可以在一个套接字连接上启动多个请求命令。 发出每个请求命令后，客户端通常会阻止并等待redis服务器的处理，并在redis处理请求命令后通过响应消息将结果返回给客户端。如果要运行多个命令，则客户端必须等待上一个命令的执行完成例如：
执行步骤如下图所示。
由于通信存在网络延迟，客户端和服务器之间的分组传输时间需要0.125秒。 那么，上面的三个命令六条消息至少需要0.75秒。 这样，redis一秒钟可以处理100个命令，而我们的客户端一秒钟只能发出4个命令。 这显然没有充分利用redis的处理能力。
另一方面，“管线”(pipeline )可以一次发送多个命令，并在执行后一次返回结果。客户端-服务器（CS）模型Pipeline的默认同步数为53个。 也就是说，在arges中累积53个数据时提交数据。 流程如下图所示。 客户端可以将三个命令组合成一条tcp消息发送，服务器可以将三个命令的处理结果组合成一条tcp消息返回。
请注意，在pipeline中打包并发送命令。 redis必须缓存所有命令的处理结果，然后才能处理所有命令。请求/响应协议的 TCP 服务器所以打包的命令不是越多越好。 具体有多合适需要根据情况进行测试。
(二)比较正常模式和PipeLine模式测试环境：
windows:eclipse jedis2.9.0JDK 1.7
Ubuntu :部署在虚拟机中的服务器Redis 3.0.7
/* *测试正常和PipeLine模式的效率： *测试方法：在redis中插入10000对数据*/publicstaticvoidtestpipelineandnormal (jedis jedis ) throdis for(intI=0； i 10000； I ) Jedis.set(String.valueof ) I )，str
ing.valueOf(i));}long end = System.currentTimeMillis();logger.info("the jedis total time is:" + (end - start));Pipeline pipe = jedis.pipelined(); // 先创建一个 pipeline 的链接对象long start_pipe = System.currentTimeMillis();for (int i = 0; i < 10000; i++) {pipe.set(String.valueOf(i), String.valueOf(i));}pipe.sync(); // 获取所有的 responselong end_pipe = System.currentTimeMillis();logger.info("the pipe total time is:" + (end_pipe - start_pipe));BlockingQueue<String> logQueue = new LinkedBlockingQueue<String>();long begin = System.currentTimeMillis();for (int i = 0; i < 10000; i++) {logQueue.put("i=" + i);}long stop = System.currentTimeMillis();logger.info("the BlockingQueue total time is:" + (stop - begin));}
从上述代码以及结果中可以明显的看到 PipeLine 在 “批量处理” 时的优势。
（三）适用场景有些系统可能对可靠性要求很高，每次操作都需要立马知道这次操作是否成功，是否数据已经写进 redis 了，那这种场景就不适合。
还有的系统，可能是批量的将数据写入 redis，允许一定比例的写入失败，那么这种场景就可以使用了，比如10000条一下进入 redis，可能失败了2条无所谓，后期有补偿机制就行了，比如短信群发这种场景，如果一下群发10000条，按照第一种模式去实现，那这个请求过来，要很久才能给客户端响应，这个延迟就太长了，如果客户端请求设置了超时时间5秒，那肯定就抛出异常了，而且本身群发短信要求实时性也没那么高，这时候用 pipeline 最好了。
（四）管道（Pipelining） VS 脚本（Scripting）大量 pipeline 应用场景可通过 Redis 脚本（Redis 版本 >= 2.6）得到更高效的处理，后者在服务器端执行大量工作。脚本的一大优势是可通过最小的延迟读写数据，让读、计算、写等操作变得非常快（pipeline 在这种情况下不能使用，因为客户端在写命令前需要读命令返回的结果）。
应用程序有时可能在 pipeline 中发送 EVAL 或 EVALSHA 命令。Redis 通过 SCRIPT LOAD 命令（保证 EVALSHA 成功被调用）明确支持这种情况。
（五）源码分析关于Pipeline 的源码分析 请看后续文章分析。
------至所有正在努力奋斗的程序猿们！加油！！
有码走遍天下 无码寸步难行
1024 - 梦想，永不止步!
爱编程 不爱Bug
爱加班 不爱黑眼圈
固执 但不偏执
疯狂 但不疯癫
生活里的菜鸟
工作中的大神
身怀宝藏，一心憧憬星辰大海
追求极致，目标始于高山之巅
一群怀揣好奇，梦想改变世界的孩子
一群追日逐浪，正在改变世界的极客
你们用最美的语言，诠释着科技的力量
你们用极速的创新，引领着时代的变迁
——乐于分享，共同进步，欢迎补充
——Treat Warnings As Errors
——Any comments greatly appreciated
——Talking is cheap, show me the code
——诚心欢迎各位交流讨论！QQ:1138517609
——CSDN：https://blog.csdn.net/u011489043
——简书：https://www.jianshu.com/u/4968682d58d1
——GitHub：https://github.com/selfconzrr