Redis怎么用携程，原来它自己就支持协程这事儿你知道吗？

这事儿说起来挺有意思的，很多人一想到Redis，就觉得它是个速度飞快的远程字典服务器，用的时候得发请求、等响应，在网络等待上难免会耗点时间，尤其是在Python这种传统上异步支持不那么直接的语言里，为了不阻塞主线程，大家会想到用多线程、多进程，或者用像Gevent、asyncio这样的异步框架来并发处理Redis操作，但你可能不知道，Redis从很早期的版本开始，自己就内置了一种简单的协程支持，只不过它不是我们今天常说的那种编程语言层面的协程，而是通过一种叫做“管道（Pipelining）”的技术来实现的。

（来源：Redis官方文档关于Pipelining的介绍）

那Redis这个自带的“协程”是怎么一回事呢？咱们打个比方，假设你没有用管道，每次你想给Redis下命令，比如先设置一个键值对set name "张三"，然后再读取它get name，你的程序流程是这样的：你的应用先把这个set命令打包成一个请求包，通过网络发给Redis服务器，然后就在那儿干等着，啥也不干，直到收到Redis返回的“OK”响应，收到之后，它再开始打包get命令，再发出去，再继续干等着拿结果，这就像你去银行办业务，只有一个窗口，你每次只告诉柜员一件事，我要存钱”，然后等他办完，你再说“我还要取钱”，再等他办完，大部分时间你都在排队等待,效率很低。

（来源：对Redis请求-响应模型的普遍理解）

而Redis管道的作用，就是让你能当一次“话痨”，还用银行的例子，这次你拿一张纸条，把要办的事情一口气全写上：“存100元，取50元，查询余额”，你把这张纸条一次性递给柜员，柜员呢，他会按照顺序一件一件地处理，但关键是你不用每办完一件就沟通一次了，你只需要在最后一次性拿到所有操作的结果，对应到Redis，你的应用程序可以把一连串的命令（比如10个set命令或者混合命令）一次性打包，通过一个网络请求发送给Redis服务器，Redis服务器会在内存中按顺序快速执行所有这些命令，然后把所有命令的执行结果收集起来,再通过一个网络响应包一次性返回给你的应用程序。

（来源：Redis官方文档对Pipelining工作原理的解释）

你看，这个过程是不是就有点协程的味道了？它虽然没有在单个线程里通过事件循环来切换任务，但它极大地减少了“等待”的时间，原本需要20次网络往返时间（10个命令，每个命令一发一收）的操作，现在被压缩成了仅仅2次网络往返时间（一次性发送所有命令，一次性接收所有结果），你的应用程序在发送完一批命令后，在等待响应的这段时间里，理论上可以去处理点别的事情（虽然在使用同步Redis客户端时，线程可能还是阻塞的，但阻塞的总时长大大缩短了），这本质上就是一种通过批处理来提升并发能力的思路，和协程追求的目标——避免无谓的等待，提高CPU和网络IO的利用率——是高度一致的。

（来源：对并发编程和IO优化概念的普遍认知）

当你听说“Redis自己支持协程”时，内行的人第一时间想到的往往就是这个“管道”功能，它简单、高效，而且是Redis原生支持的，不需要任何额外的模块，这里要分清一个概念，在更现代的编程环境中，比如Python的asyncio，我们有像aioredis这样的异步Redis客户端，那个是真正的、语言层面的协程支持，它允许你在单个线程内，在等待Redis响应的期间，主动让出CPU去执行其他协程任务，这和Redis内置的管道技术是不同层面的优化：管道主要优化的是网络往返次数，是服务器协议层面的特性；而异步客户端优化的是线程的使用效率，是客户端驱动层面的实现，两者可以结合使用，效果更佳——你可以用异步客户端来发送管道请求，这样既减少了网络往返,又避免了线程阻塞。

（来源：对异步编程模型和Redis异步客户端（如aioredis）工作原理的理解）

Redis确实“自带协程”，这个说法指的就是其核心特性“管道（Pipelining）”，它是一种朴素而强大的批处理技术，通过将多个命令打包一次传输，显著降低了网络延迟带来的开销，实现了类似协程的并发效果，虽然它和现代编程语言中的协程实现机制不同，但思想是相通的，下次当你需要高效地与Redis进行大量交互时，别忘了这个Redis送给你的、开箱即用的“老牌协程”工具。