我所说的‘redis pipeline’，是指多个redis命令的请求只产生一次网络IO（底层只发送一个包），这样减少了网络io的次数，因此就提高了性能。 经过抓包分析发现，目前的node-redis版本并不支持此功能。我去翻了一下issues，作者所指的pipeline，多个命令仍然是发送多次请求，只不过从server端的回复可能是一次而已。 后来我又试了一下python版本的redis客户端，发现它就是只发送一次请求的。 请问大家有没有遇到过类似问题？ 如何解决的呢？是改了源代码，还是使用了别的库呢？ 谢谢！
好吧，根据官方说法，pipelining确实指的是指令合并。
This time is called RTT (Round Trip Time). It is very easy to see how this can affect the performances when a client needs to perform many requests in a row (for instance adding many elements to the same list, or populating a database with many keys). For instance if the RTT time is 250 milliseconds (in the case of a very slow link over the Internet), even if the server is able to process 100k requests per second, we'll be able to process at max four requests per second. If the interface used is a loopback interface, the RTT is much shorter (for instance my host reports 0,044 milliseconds pinging 127.0.0.1), but it is still a lot if you need to perform many writes in a row.
但是在RTT很低，比如使用loopback interface时，没有进行指令合并的影响可以降到最小。
without pipelining 1.185238 seconds with pipelining 0.250783 seconds
node_redis的“自动pipelining"其实并不是真正的pipelining，而是利用node的异步特性尽可能多地发送指令给redis。
这里有一篇讨论 http://informatikr.com/2012/redis-pipelining.html 作者的结论是（我觉得这个有待测试验证）
However, contrary to the synchronous approach, the pipelining is not optimal in the number of packets sent over the network. The reason is, that it's not possible to follow the optimal algorithm and defer flushing the output buffer, since the library user never calls a blocking receive function. The drop in performance, measuring requests per second, will be about a factor of two for heavily pipelined command sequences.
我觉得pipeling的性能提升来自发送多个指令，但是只接收一次回复，而不是将多个指令合并成一个只发送一次请求。 虽然我没做过对比测试，但从理论上发送单个指令可以让redis服务器更早相应请求，所以性能比延迟一段时间再发送合并的指令性能要更好。
刚刚也碰到了，我改用redis-stream了，lz也可以试试
难道没人用过这个库吗？ 那都用的什么连接redis啊~
@yorkie 这个issue我看了，我的例子也是这么写的，但是就如我上面所说的，并不是只发送一次包的，是有几次请求就发送几个包的。用抓包软件就能看出来的。
