Redis异步消息

database

关于异步消息,大家都知道,如下:

 

  这些用起来都是比较复杂的,RabbitMQ先要创建Exchange,在创建Queue,还要将Queue和Exchange通过某种规则绑定起来。发消息之前要指定routing-Key,还要控制头部信息。

  即使你只需要一组消息者。那么你就要经历上面繁琐的过程。

  但是Redis对于那些轻量级和只有一组消息者的消息队列;

  Redis的list数据结构常用来作为异步消息队列来使用。使用rpush/lpush操作入队列,用lpop/rpop来出队列。我们都知道list是一个链表,所以操作方式如下

 

 

 当然我们会遇到一些问题,比如队列空了会怎么样?客户端是通过队列的 pop 操作来获取消息,然后进行处理。处理完了再接着获取消息,再进行处理。如此循环往复,这便是作为队列消费者的客户端的生命周期。 可是如果队列空了,客户端就会陷入 pop 的死循环,不停地 pop,没有数据,接着再 pop,又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPU,redis 的 QPS 也会被拉高,如果这样空轮询的客户端有几十来个,Redis 的慢查询可能会显著增多。 通常我们使用 sleep 来解决这个问题,让线程睡一会,睡个 1s 钟就可以了。不但客户端的 CPU 能降下来,Redis 的 QPS 也降下来了。(摘自Redis深度历险) 

 睡眠会导致消息的延迟增大·,多个消费者情况下,延迟会有所下降,因为每个消费者都是的睡眠时间是岔开来的。通过阻塞读:blocking,也就是这两个命令:blpop,brpop。

当然还有会空闲连接自动断开,顾名思义,一直阻塞,Redis客户端就成了闲置的,时间长了,服务器会断开连接,减少闲置资源,这时候就会抛出异常,所以编写消费者的时候,注意捕获异常,重试。

延时队列:

这种方式比较适合异步消息处理,将当前冲突的请求扔到另一个队列延后处理以避开冲突

我们将消息序列化成一个字符串作为 zset 的 value,这个消息的到期处理时间作为 score,然后用多个线程轮询 zset 获取到期的任务进行处理,多个线程是为了保障可用性,万一挂了一个线程还有其它线程可以继续处理。因为有多个线程,所以需要考虑并发争抢任务,确保任务不能被多次执行。

以上是 Redis异步消息 的全部内容, 来源链接: utcz.com/z/532059.html

回到顶部