管道技术在Redis里用起来，数据处理速度竟然能这么快，真是意想不到的提升效果

综合自多位Redis开发者的实践经验分享和技术博客讨论）

“我以前处理数据，就是一个一个来，像个老老实实的搬运工，比如要从Redis里读出十万个用户ID，然后根据每个ID去数据库查详细信息，再做一些计算，最后把结果存回去，程序呢，就傻乎乎地循环十万次，每次都是：发一个命令给Redis，然后等着Redis返回结果，程序卡住等，拿到结果后再干下一件事，这十万次下来，光是花在‘等’的时间上，就多得吓人，网络来回一次就算只要1毫秒，十万次那也是100秒了，这还没算程序自己处理的时间，效率实在太低,搞得人很着急。

后来我知道了Redis的管道技术，用了一下，那感觉，就像是给这个搬运工配上了一辆超级传送带，甚至是好几辆并行的传送带！速度的提升根本不是一点点，而是几倍、十几倍甚至几十倍地往上翻,真的是意想不到。

那这个管道技术到底是个啥呢？其实道理特别简单，一点都不复杂，你可以把它想象成去超市买东西，不用管道的时候，就像是你每次只从货架上拿一件商品，然后立刻跑到收银台排队、结账，再跑回去拿第二件商品，再排队结账，这样来来回回,大部分时间都浪费在路上了。

而用了管道呢，就聪明多了，你会推一个购物车，一次性把要买的十件、二十件商品全都放进车里，然后只排一次队，把这整整一车商品一次性结账，管道技术干的就是这个事儿！它允许我的程序一次性把一大堆命令，比如那一万个读请求或者写请求，打包成一个‘包裹’，通过一次网络连接发送给Redis服务器，Redis服务器收到这个‘大包裹’后，也特别给力，它会在内部以极快的速度，按顺序一个一个地执行这些命令，等所有命令都执行完了，它再把所有的结果打包成一个‘结果包裹’,一次性发回给我的程序。

这样一来，最大的好处就是极大地减少了网络开销，以前十万次操作，就要有十万次网络来回的延迟等待，现在可能只需要几十次或者几百次（取决于我每次打包多少命令），网络延迟在很多时候都是最大的性能瓶颈，把这个瓶颈几乎打掉，速度自然就飞起来了，我记得特别清楚，有一次我处理一个用户画像更新的任务，没用管道之前，跑完大概要十来分钟，用了管道之后，调整了一下每次打包的命令数量，一分多钟就搞定了，当时我和同事都惊了,没想到效果能这么明显。

这个传送带也不是无限宽的，你不能无脑地把一百万个命令塞进一个包裹里发过去，那样可能会把Redis服务器暂时‘撑’到，就好比你不能把整个超市的商品都塞进一个购物车，那样收银员也处理不过来，实际用的时候，我们需要做个平衡，根据网络情况和服务器能力，找一个合适的‘包裹大小’，比如一次发一千个命令或者五千个命令，这样既能最大化利用网络,又不会给服务器造成太大压力。

还有一点挺重要的是，管道里的命令执行，并不是同时进行的，而还是一个接一个地顺序执行，它只是把发送和接收的过程批量化了，管道里的每个命令之间依然是有关联的，后一个命令能读到前一个命令写入的结果，它不能保证这一大批命令执行的时候，没有其他客户端的命令插进来，如果你需要更严格的原子性，那可能得用Redis的事务功能，但事务的代价会高一些，不过对于绝大多数只是追求极致速度、对中间状态不敏感的场景来说,管道已经绰绰有余了。

Redis的管道技术是一个非常简单、几乎零成本（指学习成本和使用成本）就能换来巨大性能提升的利器，它没有改变Redis命令本身的任何语法，只是改变了客户端和服务器之间通信的方式，只要你有很多个命令要连续执行，并且这些命令之间不需要立刻获取上一条命令的结果才能决定下一条命令是什么，那么就非常适合用管道来优化，自从掌握了这个方法，我在处理大量数据时心里就踏实多了，再也不怕那种循环几万次的耗时操作了，这种‘小技巧，大提升’的体验，确实让人印象深刻。”