Redis实现消息队列与延时消息队列

lpop (left pop)

由队列的左边取出来

rpop (right pop)

由队列的右边取出来

以上的四个命令，可以让 list 帮我们实现队列 或者 栈，队列的特性是先进先出，栈的特性是先进后出，

所以队列的实现可以使用 lpush + rpop 或者 rpush + lpop，

栈的实现则是lpush + lpop 或者 rpush + rpop。

使用命令演示队列

========

生产者发布消息

---

首先我们使用 rpush 对一个叫做notify-queue的队列，增加五个元素，即 1 2 3 4 5，也就是作为生产者发布消息啦

消费者消费消息

---

既然生产者使用的是rpush，那么消费者就要用lpop，可以看下下图，我们不停对notify-queue进行消息消费，并且是按照顺序的，从1一直到5，按顺序读出，最终队列中没有消息了，弹出的则一直是空

空轮询问题

=====

在上面使用lpop消费消息时，可以看到，消息消费完后，我们每次再去pop时，读到的都是一个空的信息，

上面是手动执行命令，但是如果是写好的代码程序不停的去pop数据(拉取数据)的话，会造成空轮询(无用的读取)，

既拉高了客户端的CPU消耗，又拉高了redis的QPS，并且还是无用操作，这些无用操作可能会造成其他客户端对redis的访问变得响应缓慢。

解决方案A (休眠)

---

既然空轮询会让客户端和redis的资源消耗都会变得较高，那么我们可以让客户端在收到空数据的时候，进行1s的休眠，1s后再进行数据拉取，这样可以降低消耗

Thread.sleep(1000)

这个方案也是存在瑕疵的，即消息消费延迟性增大了，如果只有一个消费者的话，延迟就是1s，即空轮询后，正好休眠了，但是这时候刚好有消息过来了，还是要等到1s醒来后才能消费，

如果有多个消费者的话，由于每个消费者的睡眠时间是岔开的，会降低一些延迟性，但是有没有办法更好的方法，可以做到几乎 0 延迟？

解决方案B (阻塞读)

---

redis中关于队列取数据其实还有两个命令，即阻塞读取，

blpop (blocking left pop)

brpop (blocking right pop)

阻塞读在队列没有数据的时候，会进入休眠状态，一旦有消息来了以后，则立刻做出反应，读取数据，因此使用 blpop/brpop 替换 lpop/rpop 则可以解决消息延迟性的问题，

继续入队3个属性，6、7、8

使用 blpop 进行队列的读取，最后一个参数是阻塞读的等待时间，如果超过这个时间还没有消息，将会返回nil，此时可以继续重复blpop操作,

阻塞读的空闲连接自动断开问题

客户端使用阻塞读时，如果阻塞的时间过长，服务一般会当成空闲连接，从而对其进行主动断开，减少无用的连接占用资源，这个时候客户端会抛出异常，

所以请注意，在客户端使用阻塞读的时候，要进行异常的捕获，从而做出相应的处理，例如重试。

java客户端实现消息队列

---

思路和上述一样，只是由命令行客户端redis-cli变成了java语言，一个线程或多个线程进行 rpush 的发布，

另外一个或多个线程进行 blpop 消费，完成的代码在：github.com/qiaomengnan…

发布者

订阅者

延时队列的实现思路

=========

延时队列指的是，消息发送的一段时间后，再由消费者进行消费，而不是发送过去后，消费者就能立即读取到，

zset的可以帮我们做到这个事情，首先zset可以通过score进行排序，score可以存一个时间戳，所以我们每次发布消息的时候，用当前时间戳加上延时的时间戳，

随后消费者取消息的时候，通过截取zset的数据，取到已经满足当前时间的消息（即取score小于等于当前时间戳的数据，score小于等于当前时间戳代表消息已经到时间了，如果大于的话，说明还得等一会才能消费）。