【第三章 小功能大用处】3.3、Pipeline

in with 0 comment

Pipeline

  1. Pipeline

    Redis客户端执行一条命令分为如下四个过程:

    1)发送命令 2)命令排序 3)命令执行 4)返回结果

    其中1)+4)称为Round Trip Time(RTT,往返时间)。

    Redis提供了批量操作命令(例如mget、mset等),有效地节约RTT。但大部分 命令是不支持批量操作的,例如要执行n次hgetall命令,并没有mhgetall命令 存在,需要消耗n次RTT。Redis的客户端和服务端可能部署在不同的机器上。例 如客户端在北京,Redis服务端在上海,两地直线距离约为1300公里,那么1次 RTT时间=13002/(3000002/3)=13毫秒(光在真空中传输速度为每秒30秒公 里,这里假设光纤为光速的2/3),那么客户端在1秒内大约只能执行80次左右 的命令,这个和Redis的高并发高吞吐特性背道而驰。

    Pipeline(流水线)机制能改善上面这类问题,它能将一组Redis命令进行组 装,通过一次RTT传输给Redis,再将这组Redis命令的执行结果按顺序返回给客 户端。

    Pipeline并不是什么新的技术活机制,很多技术上都使用过。而且RTT在不同网 络环境下会有不同,例如同机房和同机器会比较快,跨机房跨地区会比较慢。 Redis命令真正执行的时间通常在微秒级别,所以才会有Redis性能瓶颈是网络 这样的说法。

    redis-cli的--pipe选项实际上就是使用Pipeline机制,例如下面操作将set hello world和incr counter两条命令组装:

    echo -en '*3\r\n$3\r\nSET\r\n5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\n$7\r\ncounter\r\n' | redis-cli --pipe
    

    但大部分开发人员更倾向于使用高级语言客户端中的Pipeline,目前大部分 Redis客户端都支持Pipeline

  2. 性能测试

    网络延迟非PipelinePipeline
    本机0.17ms573ms134ms
    内网服务器0.41ms1610ms240ms
    异地机房7ms78499ms1104ms

    上表给出了在不同网络环境下非Pipeline和Pipeline执行10000次set操作的 效果,可以得到如下两个结论:

    • Pipeline执行速度一般比逐条执行要快。
    • 客户端和服务端的网络延时越大,Pipeline的效果越明显。
  3. 原生批量命令与Pipeline对比

    可以使用Pipeline模拟出批量操作的效果,但是在使用时要注意它与原生批量 命令的区别,具体包含以下几点:

    • 原生批量命令是原子的,Pipeline是非原子的。
    • 原生批量命令是一个命令对应多个key,Pipeline支持多个命令。
    • 原生批量命令是Redis服务端支持实现的,而Pipeline需要服务端和客户端 的共同实现。
  4. 最佳实践

    Pipeline虽然好用,但是每次Pipeline组装的命令个数不能没有节制,否则一 次组装Pipeline数据量过大,一方面会增加客户端的等待时间,另一方面会造 成一定的网络阻塞,可以将一次包含大量命令的Pipeline拆分成多次较小的 Pipeline来完成。

    Pipeline只能操作一个Redis实例,但是即使在分布式Redis场景中,也可以作 为批量操作的重要优化手段。