redis 消息队列

redis 异步队列实现

• 一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。

 

如果生产者速度大于消费者消费速度，消息队列长度会一直增大，时间久了会占用大量内存空间。

如果睡眠时间过长，这样不能处理一些时效性的消息，睡眠时间过短，也会在连接上造成比较大的开销。

• blpop，brpop可以代替sleep，在没有消息的时候，它会阻塞住直到消息到来。

 

redis pub/sub发布订阅模式

生产者和消费者通过相同的一个信道(Channel)进行交互。信道其实也就是队列。

通常会有多个消费者。多个消费者订阅同一个信道，当生产者向信道发布消息时，该信道会立即将消息逐一发布给每个消费者。可见，该信道对于消费者是发散的信道，每个消费者都可以得到相同的消息。典型的对多的关系。

优点：

1.典型的广播模式，一个消息可以发布到多个消费者

2.多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息

3.消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息

缺点：

1.消息一旦发布，不能接收。换句话就是发布时若客户端不在线，则消息丢失，不能寻回。

2.不能保证每个消费者接收的时间是一致的

3.若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外丢失。通常发生在消息的生产远大于消费速度时。

 

由此可见，Pub/Sub 模式不适合做消息存储，消息积压类的业务，而是擅长处理广播，即时通讯，即时反馈的业务。

 

redis如何实现延时队列

(1) 拿时间戳作为score，消息内容作为key调用zadd来生产消息，存放在zset中；

(2) 用一个进程定时查询zset的score分数最小的元素，可以用ZRANGEBYSCORE key -inf +inf limit 0 1 withscores命令来实现;

(3) 如果最小的score时间戳小于等于当前时间戳，就将该任务取出来执行，否则休眠sleep一段时间后再查询