前置条件:需要了解 redis list 的定义和使用,然后在考虑在当成消息队列的时候,会遇到的问题及解决方案。
Redis的消息队列缺少一些高级特性,没有 ack 保证,如果对消息的可靠性有着极致的追求,那么它就不适合使用。
常规实现:Redis 的 list(列表) 数据结构常用来作为异步消息队列使用,使用rpush/lpush
操作入队列,使用 lpop\rpop
来出队列。网上能搜到很多简单实现,但是欠缺很多的考虑。
队列空了
客户端是通过队列的 pop
操作来获取消息,然后进行处理。处理完了再接着获取消息,再进行处理。如此循环往复,这便是作为队列消费者的客户端的生命周期。
如果队列空了,客户端就会陷入 pop
的死循环,不停地 pop
,没有数据,接着再 pop
,又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPU,redis 的 QPS 也会被拉高,如果这样空轮询的客户端有几十来个,Redis 的慢查询可能会显著增多。
解决方案: 让代码 sleep(1)
一秒钟,或者根据实际需求来暂停一下,来让CPU 降下来,也让 QPS 下降。
队列延迟
睡眠会导致消息的延迟增大。如果只有 1 个消费者,那么这个延迟就是 1s。如果有多个消费者,这个延迟会有所下降,因为每个消费者的睡觉时间是岔开来的。
解决方案: 那就是 blpop/brpop
两个命令,这两个指令的前缀字符 b
代表的是 blocking
,也就是阻塞读。阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。消息的延迟几乎为零。用 blpop/brpop
替代前面的lpop/rpop
,就完美解决了上面的问题。
参考命令解释:redis brpop
空闲链接
如果线程一直阻塞在哪里,Redis 的客户端连接就成了闲置连接,闲置过久,服务器一般会主动断开连接,减少闲置资源占用。这个时候 blpop/brpop
会抛出异常来。
解决方案: 需要注意捕获异常,加上判断
锁冲突处理
常见于以下情况:如果在加锁和释放锁之间的逻辑执行的太长,以至于超出了锁的超时限制,就会出现问题。因为这时候锁过期了,第二个线程重新持有了这把锁,但是紧接着第一个线程执行完了业务逻辑,就把锁给释放了,第三个线程就会在第二个线程逻辑执行完之间拿到了锁。
一般有以下几种方案处理:
1.直接抛出异常,通知用户稍后重试;这个可以在用户端利用代码进行监测,代替用户自己去手动重试。
2.sleep
一会再继续,sleep
是一种方案,但不推荐使用,会阻塞当前的消息处理线程,会导致队列的后续消息处理出现延迟。甚至可能堵死线程。
3.将请求转移至延时队列,过一会再重试,这种方式比较适合异步消息处理,将当前冲突的请求扔到另一个队列延后处理以避开冲突。延迟队列的操作有个美妙的命令 rpoplpush,具体可以参见文档。
进一步优化:
上面的算法中同一个任务可能会被多个进程取到之后再使用 zrem
进行争抢,那些没抢到的进程都是白取了一次任务,这是浪费。可以考虑使用lua scripting
来优化一下这个逻辑,将 zrangebyscore
和 zrem
一同挪到服务器端进行原子化操作,这样多个进程之间争抢任务时就不会出现这种浪费了。
参考链接为 掘金小册 - Redis 深度历险,推荐购买,本文当作笔记