按照这个例子写就可以啊： https://github.com/mranney/node_redis/issues/539#issuecomment-32203325

@yorkie 这个issue我看了，我的例子也是这么写的，但是就如我上面所说的，并不是只发送一次包的，是有几次请求就发送几个包的。用抓包软件就能看出来的。

@mrFranklin >.<

难道没人用过这个库吗？ 那都用的什么连接redis啊~

刚刚也碰到了，我改用redis-stream了，lz也可以试试

@chemdemo 恩，感谢回复。我打算自己改一下源代码了~ 不太想一个项目里用俩同样功能的库。

我觉得pipeling的性能提升来自发送多个指令，但是只接收一次回复，而不是将多个指令合并成一个只发送一次请求。 虽然我没做过对比测试，但从理论上发送单个指令可以让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.

好吧，根据官方说法，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。