redis的多命令执行方法之一-pipeling

管道传输(pipelining)：用于一次性处理多条redis命令

     redis的执行流程为客户端发送命令到服务端，客服端阻塞等待服务端程序返回，如果中间由于网络通信问题导致速度比较慢，另外由于客户端和服务端的数据传输需要一定的时间。这个

     时间叫做RTT，Round Trip Time 。如果有很多条命令要一次性传输，相对来说就会比较慢，redis提供了pipelining命令来处理。

     pipeling在传统的命令传输方式上，允许客户端发送多条命令以减少传输过程中消耗的时间，redis在很早的时候就考虑到了这个问题，所以不用担心版本的兼容性问题。

     最简单的版本如下：

          

• Client: INCR X
• Client: INCR X
• Client: INCR X
• Client: INCR X
• Server: 1
• Server: 2
• Server: 3
• Server: 4

它类似于一个这样的指令：

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG

注意事项：

     当客户端使用pipelining发送多条指令的时候，服务器端会强制对处理后的结果进行排序。因此如果你一次性需要传输大量的命令，而服务端的内存有一定限制的时候，最好对他们进行一个合理的编号，比如你要传输20K数量的指令，你可以先传输10K的指令

到redis的服务端，等待返回，获取返回的数据后再次发送10K的指令到服务器，这样操作的结果是，处理效率其实是相近的，但是可以省下一半的内存。

  下面使用了一个python脚本来测试当使用传统的方法和使用pipelining在处理过程中的时间差异     

require 'rubygems'
require 'redis'

def bench(descr)
    start = Time.now
    yield
    puts "#{descr} #{Time.now-start} seconds"
end

def without_pipelining
    r = Redis.new
    10000.times {
        r.ping
    }
end

def with_pipelining
    r = Redis.new
    r.pipelined {
        10000.times {
            r.ping
        }
    }
end

bench("without pipelining") {
    without_pipelining
}
bench("with pipelining") {
    with_pipelining

}

通过上面这个脚本，我们在同一台mac笔记本上的测试结果如下：

without pipelining 1.185238 seconds
with pipelining 0.250783 seconds

可以看出使用pipeling可以节省大量的时间。

redis pipling和 redis script脚本对比

     场景一、在redis2.6以后你可以使用redis script，当你 需要在服务器的redis-cli端执行大量的命令的时候可以使用redis script，而不是pipelining，

     原因分析： 但是redis script一个非常优秀的特点就是他可以同时进行read write compute， 举个例子，你可以在redis脚本当中先把库存读出来然后减掉1，然后跟其他商品的库存进行对比等操作，这样的场景下redis script是非                                 常快速的，但是在这个场景下是用pipeling就不太合适了

     场景二、 在某些情况下我们希望是用 pipeling发送eval或者evalsha命令到 服务端，因为pipeling完美支持这个功能，并且明确指定了必须是用script load方法来加载脚本内容，

这样可以防止evalsha 的sha验证不存在，找不到脚本的情况发生