redis专题03 消息队列系列问题

文章目录

1. 1. list结构模拟队列
2. 2. 总结

很多业务场景中多会用到消息队列来传递消息数据问题， 常用的消息队列如NSQ,NAS, Rabbitmq和Kafka等重量级消息队列中间件，功能很强大 使用起来自然也复杂，其实在大部分场景只是需要一个消息队列来传递数据，数据量，数据之间的顺序等也没有特殊的要求， 这样的场景使用redis非常轻松就可以搞定，而且在使用和维护上相对而言要简单方便些,当然redis的消息队列不是专业的消息队列，它没有非常多的高级特性，没有ack保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用；

新秀NQS集群搭建相对简单，文档也很简介易懂，但其维护性和代码嵌入性上来讲要比用redis消息队列复杂的多， 此外使用过Rabbitmq的同学知道它使用起来有多复杂，发消息之前要创建Exchange，再创建Queue，还要将 Queue和Exchange通过某种规则绑定起来，发消息的时候要指定routing-key，还要控制头部信息。消费者在消费消息之前也要进行上面一系列的繁琐过程。

list结构模拟队列

redis中可以用list(列表）结构来模拟队列和栈，而且非常简单，也常用来作为异步消息队列使用，使用rpush/lpush操作入队列，使用lpop/rpop来出队列。

客户端是通过队列的pop操作来获取消息，然后进行处理。处理完了再接着获取消息，再进行处理。显然客户端不停的pop操作，当队列空后，客户端就会陷入pop的死循环，此时空轮询不但拉高了客户端的CPU占用率,redis的 QPS也会被拉高，如果这样空轮询的客户端有几十来个，redis的慢查询可能会显著增多。

上述问题通常可以通过sleep命令来解决这个问题，让线程休眠一下，如sleep (1s)，但是休眠会导致消息的延迟增大。如果只有1个消费者，那么这个延迟就是1s。如果有多个消费者，这个延迟会有所下降，因为每个消费者的休眠时间是岔开来的。

有没有什么办法能显著降低延迟呢？

当然可以，借助redis提供了一组blpop/brpop阻塞读命令就可以，阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒过来。消息的延迟几乎为零。用blpop/brpop替代前面的lpop/rpop，就完美解决了上面的问题。

但是在实际使用过程中,blpop/brpop 可能会产生假死现象，就是当没有数据的时候通过blpop/brpop操作进入阻塞休眠状态，当再次有数据进来后，blpop/brpop操作并没有被唤醒继续执行pop, 这是为什么呢？

什么问题？ —— 空闲连接的问题。

如果线程一直阻塞在哪里，Redis的客户端连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用。这个时候blpop/brpop会抛出异常来。所以编写客户端消费者的时候要小心，注意捕获异常，还要重试。

应用场景一 延时队列

当客户端在处理请求时加锁没加成功怎么办。一般有3种策略来处理加锁失败：

• 直接抛出异常，通知用户稍后重试；

  • 这种方式比较适合由用户直接发起的请求，用户看到错误对话框后，会先阅读对话框的内容，再点击重试，这样就可以起到人工延时的效果。如果考虑到用户体验，可以由前端的代码替代用户自己来进行延时重试控制。它本质上是对当前请求的放弃，由用户决定是否重新发起新的请求。

• sleep一会再重试；

  • sleep 会阻塞当前的消息处理线程，会导致队列的后续消息处理出现延迟。如果碰撞的比较频繁或者队列里消息比较多，
  • sleep 可能并不合适。如果因为个别死锁的 key 导致加锁不成功，线程会彻底堵死，导致后续消息永远得不到及时处理。

• 将请求转移至延时队列，过一会再试；

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

延时队列可以通过redis的zset(有序列表)来实现。我们将消息序列化成一个字符串作为zset的value，这个消息的到期处理时间作为score，然后用多个线程轮询zset获取到期的任务进行处理，多个线程是为了保障可用性，万一挂了一个线程还有其它线程可以继续处理。因为有多个线程，所以需要考虑并发争抢任务，确保任务不能被多次执行。在处理上可以将zrangebyscore和zrem一同挪到服务器端进行原子化操作;

总结

---

• 阐述了redis利用list结构模拟消息队列的使用原理，场景;
• 进一步分析了通过list结构模拟异步消息队列出现队列延迟的问题，引入blpop/brpop阻塞读命令操作；
• 进一步在blpop/brpop阻塞读命令休眠过久时无法再次唤醒pop操作，是因为当前连接休眠过久被会redis认为是空闲连接而强行断开连接， 导致后继的blpop/brpop在数据再次到达后无法再次唤醒pop操作， 此情况需要在程序实现时注意捕获blpop/brpop阻塞读异常并进行重试reload操作;
• 进一步分析了分布式锁加锁失败后的使用方法， 进而引入分析延时队列策略解决分布式锁加锁失败重试问题；