Redis阻塞弹出那事儿，解锁数据访问速度其实没你想的那么慢

（引用来源：Redis官方文档，以及多位技术博主如“程序员小灰”、“小林coding”的相关文章）

Redis阻塞弹出那事儿，解锁数据访问速度其实没你想的那么慢

咱们今天聊个Redis里挺实用的功能，叫“阻塞弹出”，听着名字好像有点复杂，但其实它的想法特别简单，就是为了解决一个常见的尴尬问题：队列空了怎么办？

想象一下，你用Redis的列表（List）做了一个消息队列，生产者往列表里塞消息，用的是LPUSH命令，从左边推进去；消费者从列表里取消息，用的是RPOP命令，从右边拿出来，这本来配合得挺好，但万一生产者那边速度跟不上，或者某一瞬间没消息了，消费者一执行RPOP，发现列表是空的，拿到的是一个null值，这时候消费者咋办？它不可能知道下一条消息啥时候来啊，最笨的办法就是不停地轮询，也就是写个死循环，隔一秒就RPOP一次,看看有没有新消息。

这种方法，我们通常叫它“忙等待”，缺点太明显了：浪费资源，消费者客户端（比如你的一个后台程序）啥也没干成，CPU时间片都花在不停地发请求和接收空结果上了，增加负担，每一次RPOP都是一次网络往返，就算没拿到数据，也对Redis服务器造成了不必要的压力，如果这样的消费者有很多个，那Redis可能光应付这些“空查询”就够忙活的了,真正处理数据的性能反而受影响。

这时候，Redis提供的阻塞弹出命令就派上用场了，它有两个，一个是BLPOP（Blocking Left Pop），一个是BRPOP（Blocking Right Pop），它们的用法和LPOP、RPOP差不多，但多了一个关键参数：超时时间（以秒为单位）。

一个消费者可以执行这样的命令：BRPOP myqueue 30，这句话的意思是：“请从myqueue这个列表的右边弹出一个元素给我，如果现在队列是空的，你别立刻返回空值给我，你在Redis服务器那边帮我‘挂起’等待，最多等30秒，在这30秒内，只要有其他客户端（生产者）往这个队列里推送了新消息，你立马就把这个消息弹出并返回给我，如果等了30秒还是没消息，那你再返回一个空值告诉我超时了。”

你看，这个机制一下子就解决了忙等待的问题，消费者发出一个BRPOP请求后，网络连接并不会立刻关闭，而是被Redis服务器挂起，在这个等待期间，消费者客户端这个线程可以被解放出来去处理其他任务，或者干脆休眠，不占用任何计算资源，对Redis服务器而言，它也只是维护了一个等待列表，记录下有哪些客户端在等哪个队列的消息,内部开销远比处理海量的无效RPOP请求要小得多。

最神奇的事情发生在生产者推送消息的那一刻，当生产者用LPUSH命令向myqueue推送一条新消息时，Redis服务器并不会简单地把消息存进列表就完事了，它会立刻检查有没有客户端正阻塞地等待这个队列的消息，如果发现有（比如我们那个等了29秒的消费者），Redis会马上把这条新鲜出炉的消息直接发送给那个在等待的消费者客户端，同时解除它的阻塞状态，这个响应速度是极快的，几乎是实时的，因为一切操作都在Redis单线程的内存模型中完成,没有额外的调度延迟。

你发现没有，阻塞弹出并没有让数据访问变“慢”，反而在整体上极大地提升了效率和响应速度，它用“等待”换来了“精准打击”，消费者不用再盲目地试探，而是像设置了闹钟一样，要么被新消息立刻唤醒，要么在合理的时间后得知无果而退，这对于实现高效的消息队列、作业队列系统至关重要。

有人可能会担心，设置阻塞时间会不会有风险？比如设得太长，万一消费者想退出怎么办？Redis设计得很周到，超时时间可以设置为0，意思是无限制等待，直到有消息到来，即使在阻塞等待中，客户端也可以主动关闭连接来取消等待，由于Redis是单线程处理命令，所以当多个客户端同时阻塞在同一个队列时，Redis会按照他们发起请求的先后顺序，公平地将新消息分发给最先等待的那个客户端，不会出现“插队”的情况。

阻塞弹出也不是银弹，它需要客户端能够处理长连接，并且要妥善处理超时的情况，在一些非常极端的高并发场景下，如果有成千上万的客户端同时阻塞，Redis维护这些连接信息也会有一定的内存开销,但这通常比处理成千上万的轮询请求要轻量得多。

Redis的阻塞弹出命令（BLPOP/BRPOP）是一个典型的“以空间换时间”和“以机制换效率”的优秀设计，它通过让客户端在服务器端智能等待的方式，完美地解决了消息队列中的“空轮询”难题，它非但没有拖慢数据访问的速度，反而通过消除不必要的网络往返和CPU空转，让整个系统的数据流更加平滑、高效和实时，下次当你设计需要等待数据的场景时，别忘了Redis这个贴心的“阻塞”功能，它可能比你想象的要快得多，也好用得多。 结束）