Redis基础之管道

客户端和Redis使用TCP协议连接。不论是客户端享Redis发送命令还是Redis向客户端返回命令的执行结果，都需要经过网络传输，这两个部分好事称为往返延迟。根据网络性能的不同，往返延迟也不同。大致来说，本地回环地址（loop backaddress）的往返延迟在数量级上相当于Redis处理一条简单的命令的时间。如果执行较多的命令，每个命令的往返延时累加起来对性能还是有一定的影响。

在执行多个命令时每条命令都需要等待上一条命令执行完（即收到Redis返回结果）才能执行，即使命令不需要上一条命令的执行结果。如要获取post:1、post:2、post:3这三个键中的title字段，需要执行三个命令，如：

上图展示了不使用管道时命令执行的示意图。Redis的底层通信协议对管道（pipelining）提供了支持。通过管道可以磁性发送多个命令并在执行后一次性将结果返回，当一组命令中每条命令都不依赖与之前的命令执行结果时，就可以讲这组命令一起通过管道发出。管道通过减少客户端与Redis的通信次数来实现降低往返时延累计值得目的，如下图所示：

假设不会因为tcp报文过长而被拆分。可能一个tcp报文就能完成发送三条命令,client可以将三个HGET命令放到一个tcp报文一起发送，server则可以将三条命令 的处理结果放到一个tcp报文返回。通过pipeline方式当有大批量的操作时候。我们可以节省很多原来浪费在网络延迟的时间。需要注意到是用 pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并是不是打 包的命令越多越好。具体多少合适需要根据具体情况测试。

Redis的pipeline(管道)功能在命令行中没有，但redis是支持pipeline的，而且在各个语言版的client中都有相应的实现。 由于网络开销延迟，即算redis server端有很强的处理能力，也由于收到的client消息少，而造成吞吐量小。当client 使用pipelining 发送命令时，redis server必须部分请求放到队列中（使用内存）执行完毕后一次性发送结果；如果发送的命名很多的话，建议对返回的结果加标签，当然这也会增加使用的内存。

Pipeline在某些场景下非常有用，比如有多个command需要被“及时的”提交，而且他们对相应结果没有互相依赖，而且对结果响应也无需立即获得，那么pipeline就可以充当这种“批处理”的工具；而且在一定程度上，可以较大的提升性能,性能提升的原因主要是TCP链接中较少了“交互往返”的时间。不过在编码时请注意，pipeline期间将“独占”链接，此期间将不能进行非“管道”类型的其他操作，直到pipeline关闭；如果你的pipeline的指令集很庞大，为了不干扰链接中的其他操作，你可以为pipeline操作新建Client链接，让pipeline和其他正常操作分离在2个client中。不过pipeline事实上所能容忍的操作个数，和socket-output缓冲区大小/返回结果的数据尺寸都有很大的关系；同时也意味着每个redis-server同时所能支撑的pipeline链接的个数，也是有限的，这将受限于server的物理内存或网络接口的缓冲能力。

下面是python的测试代码：

#!/usr/bin/python2.7
import redis
import time
def without_pipeline():
    r=redis.StrictRedis()
    for i in range(10000):
        r.ping()
    return
def with_pipeline():
    r=redis.StrictRedis()
    pipeline=r.pipeline()
    for i in range(10000):
        pipeline.ping()
    pipeline.execute()
    return
def bench(desc):
    start=time.clock()
    desc()
    stop=time.clock()
    diff=stop-start
    print "%s has token %s" % (desc.func_name,str(diff))
if __name__=='__main__':
    bench(without_pipeline)
    bench(with_pipeline)

运行结果为：

without_pipeline has token 0.84
with_pipeline has token 0.26