Redis管道技术到底有多牛，效率提升那些事儿你知道吗？

综合自Redis官方文档、多位资深开发者的技术博客分享以及《Redis实战》等书籍中的常见案例）

Redis管道技术到底有多牛,效率提升那些事儿你知道吗？

你可能听说过Redis特别快,觉得把它用在自己的项目里，网页加载速度、数据处理能力就能瞬间起飞，但有时候一用发现，咦，好像也没传说中那么神嘛？问题可能不出在Redis本身，而在于你和Redis“聊天”的方式，这就不得不提Redis的一项“隐藏”神技——管道技术（Pipelining），它牛在哪？简单说，就是能把Redis的性能从“绿皮火车”升级到“高铁”，提升几个数量级都不是梦。

要理解它为什么牛,得先看看不用管道时我们是怎么做的，想象一下，你是个服务员，客人（你的应用程序）要点菜，不用管道的模式是这样的：客人说“来盘花生米”，你立马跑到后厨（Redis服务器）告诉厨师，然后端着花生米跑回来给客人；客人又说“来瓶啤酒”，你又得跑一趟后厨，再端着啤酒跑回来；客人再说“来个拍黄瓜”……来来回回，你的大部分时间都浪费在跑腿的路上了，在网络世界里，每一次“跑腿”就是一次网络往返时间（Round-Trip Time, R-R-T），这个时间开销其实非常大，比Redis内部处理命令本身要慢得多。（来源：Redis官方文档中关于延迟的说明）

管道技术彻底改变了这种低效的沟通方式,还是那个例子，用了管道后，客人会一次性把“花生米、啤酒、拍黄瓜、烤串……”一整张菜单都告诉你，你记下来，跑一趟后厨，把整个菜单交给厨师，厨师呢，手脚麻利地按照顺序把菜一个个做好，你最后再一次性把所有菜端给客人，看，你从跑了N趟，变成了只跑一趟！效率的提升是惊人的。

具体能提升多少呢？有个非常经典的测试（来源：Redis官方文档自带的性能测试示例），如果不使用管道，一秒内可能只能处理几万个简单的SET或GET命令，但一旦使用了管道，并且将一批命令打包在一起（比如一批打包100个命令），每秒处理的命令数可以达到几十万甚至上百万个！这个差距就是天壤之别，因为瓶颈从网络延迟转移到了Redis服务器本身的最大处理能力上，而Redis是内存操作，处理速度极快。

这技术在什么场景下特别有用呢？举几个实际的例子你就明白了。

你在做一个社交APP,需要在用户登录后，一次性从Redis里获取他所有的未读消息、好友申请列表、最新通知等十几项数据，如果不用管道，你的程序就要向Redis发起十几次请求，等待十几次网络往返，而用了管道，只需要一次网络通信，就能拿回所有数据，用户感受到的加载速度会快非常多。

再比如,你需要初始化一批数据到Redis里，可能要写入十万条记录，用普通的循环一条条set，程序会慢到让你怀疑人生，大部分时间都在等网络，但如果你用管道，每积累几百上千条命令打包发送一次，整个初始化过程可能从几分钟缩短到几秒钟。

还有更高级的玩法,有些场景下，一批命令之间没有前后依赖关系，我们甚至不需要等待管道里所有命令都执行完再读结果，我们可以先把命令全部发出去，然后像收快递一样，陆陆续续读取每个命令的返回结果，这样还能进一步优化程序的执行效率，让网络传输和命令处理更好地重叠进行。（来源：一些优化类技术博客中提到的“异步管道”思想）

管道也不是万能的“银弹”，它主要有两个点需要注意：第一，管道里的命令必须是顺序执行的，如果第二个命令的执行依赖于第一个命令的结果，那就没法塞到同一个管道包里，否则会出错，第二，管道打包的命令不是越多越好，如果一次性塞进去十万个命令，可能会占用Redis服务器大量内存来处理这个“超级大包”，反而可能影响稳定性，一般会根据实际情况选择一个合适的包大小，比如几百到几千个命令一批。

Redis管道技术牛就牛在,它用一个非常简单的思想——批处理，巧妙地避开了网络延迟这个最大的性能瓶颈，它不需要你更换更贵的硬件，也不需要你学习特别复杂的新知识，只需要改变一下代码中发送命令的方式，就能换来几倍、几十倍甚至上百倍的性能提升，这简直就是程序员最喜欢的“性价比”极高的优化手段，如果你还在一条条地跟Redis“慢悠悠”地对话，是时候试试管道这把“牛刀”了，它带来的效率飞跃会让你大吃一惊的。