redis是一个cs模式的tcp server，使用和http类似的请求响应协议。一个client可以通过一个socket连接发起多个请求命令。每个请求命令发出后client通常会阻塞并等待redis服务处理，redis处理完后请求命令后会将结果通过响应报文返回给client。基本的通信过程如下：
|
Client: INCR X |
基本上四个命令需要8个tcp报文才能完成。由于通信会有网络延迟,假如从client和server之间的包传输时间需要0.125秒。那么上面的四个命令8个报文至少会需要1秒才能完成。这样即使redis每秒能处理100个命令，而我们的client也只能一秒钟发出四个命令。这显示没有充分利用
redis的处理能力。除了可以利用mget,mset
之类的单条命令处理多个key的命令外我们还可以利用pipeline的方式从client打包多条命令一起发出，不需要等待单条命令的响应返回，而redis服务端会处理完多条命令后会将多条命令的处理结果打包到一起返回给客户端。通信过程如下：
|
Client: INCR X |
假设不会因为tcp报文过长而被拆分。可能两个tcp报文就能完成四条命令，client可以将四个incr命令放到一个tcp报文一起发送，server则可以将四条命令的处理结果放到一个tcp报文返回。通过pipeline方式当有大批量的操作时候。我们可以节省很多原来浪费在网络延迟的时间。需要注意到是用
pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并是不是打包的命令越多越好。具体多少合适需要根据具体情况测试。下面是个jedis客户端使用pipeline的测试：
|
package com.jd.redis.client; import redis.clients.jedis.Jedis; import redis.clients.jedis.Pipeline; publicclass PipelineTest { /** * @param args */ publicstaticvoid main(String[] args) { int count = 1000; long start = System.currentTimeMillis(); withoutPipeline(count); long end = System.currentTimeMillis(); System.out.println("withoutPipeline: " + (end-start)); start = System.currentTimeMillis(); usePipeline(count); end = System.currentTimeMillis(); System.out.println("usePipeline: " + (end-start)); } privatestaticvoid withoutPipeline(int Jedis jr = null; try { jr = new Jedis("10.10.224.44", for(int i =0; i<count; i++){ jr.incr("testKey1"); } } catch (Exception e) { e.printStackTrace(); } finally{ if(jr!=null){ jr.disconnect(); } } } privatestaticvoid usePipeline(int Jedis jr = null; try { jr = new Jedis("10.10.224.44", Pipeline pl = jr.pipelined(); for(int i =0; i<count; i++){ pl.incr("testKey2"); } pl.sync(); } catch (Exception e) { e.printStackTrace(); } finally{ if(jr!=null){ jr.disconnect(); } } } } |
输出：
|
withoutPipeline: 11341 usePipeline: 344 |
测试结果还是很明显有较大的差距，所以多次操作用pipeline还是有明显的优势。我用的是Win7中的Jedis Java客户端程序连接局域网的Linux虚拟机上的Redis
Server。