Redis实现任务队列

   实现任务队列之前，我们先了解一下使用任务队列有哪些好处:

   1. 松耦合。生产者和消费者无需知道彼此的实现细节，只需要约定好任务的描述格式。这使得生产者和消费者可以由不同的团队使用不同的编程语言编写。

   2. 易于扩展。消费者可以由多个，而且可以分布在不同的服务器中，借此可以轻易地降低单台服务器的负载。

 

    要实现队列很自然就想到Redis的列表类型，以及LPUSH和RPOP命令。如果要实现任务队列，只需要让生产者将任务使用LPUSH命令加入到某个键中，另一边让消费者不断的使用RPOP命令从该键中取出任务即可。Redis的伪代码实现如下：

# 无限循环读取任务队列中的内容
loop
    $task = RPOP queue
    if $task
        # 如果任务队列中有任务，则执行它
        execute($task)    
    else
         # 如果没有任务，则等待1秒，以免过于频繁的请求数据
         wait 1 second

     至此，一个使用Redis实现的简单任务队列就写好了，不过还有一点问题：当任务队列中没有任务时，消费者每秒都会调用一次RPOP命令查看是否有新任务。

    优化：借助BRPOP命令，可以实现一旦有新任务加入队列就通知消费者

    BRPOP命令接收两个参数，第一个是键名，第二个是超时时间，单位是秒。当超过了此时间仍然没有获得新元素的话就会返回nil。 如果超时时间设为“0”，表示不限制等待的时间，如果没有新元素加入列表就会永远阻塞下去。

    BRPOP 和 RPOP命令相似，唯一区别是：任务列表中没有元素时BRPOP命令会一直阻塞住连接，直到有新元素加入。上面的伪代码可以优化为：

loop
    # 如果任务队列中没有新任务，BRPOP命令会一直阻塞，不会执行execute()
    $task = BRPOP queue, 0
    # 返回值是一个数组，数组的第二个元素是我们需要的任务
    execute($task[1])

 

   

     队列有的时候需要优先级。比如：系统需要发送确认邮件和通知邮件两种任务同时存在时，应该优先执行确认邮件。具体场景如下，订阅一个名人的博客的用户有10万人，当该博客发布一篇新文章后，博客就会向任务队列中添加10万个发送通知邮件的任务。如果每一封邮件需要10ms，那么全部完成这10万个任务就需要：100 000 * 10 / 1000=1000秒（将近20分钟）。加入这期间有新用户想订阅该博客，当提交完自己的邮箱并看到网页提示查收确认邮件时，该用户并不知道向自己发送的确认邮件的任务被加入到已经有10万个任务的队列中，需要为此等待近20分钟。

    分析具体场景，发布新文章后通知订阅用户的任务并不很紧急，延迟20分钟完全可以接受。所以可以得出如下结论：当发送确认邮件和发送通知邮件两种任务同时存在时，应该优先执行前者。为了实现这一目的，我们需要实现一个优先级队列。

    BRPOP命令可以同时接受多个键，其完整的命令格式为：BRPOP key [key ...] timeout, 如：BRPOP queue1 queue2 0.着意味着同时检测多个键，如果其中有一个键有元素，则从该键中弹出元素；如果多个键都有元素，则按照从左到右的顺序取第一个键中的第一个元素。

    借此特性可以实现区分优先级的任务队列。我们分别使用queue:confirmation.email 和 queue.notification.email 两个键存储发送确认邮件和发送通知邮件两种任务，然后将消费者的伪代码修改为：

loop
    $task = 
    BRPOP  queue:confirmationl.email,
                queue:notification.email,
                0
    execute($task[1])

     这时，一旦发送确认邮件的任务被加入到queue.confirmation.email队列中，无论queue：notification.email还有多少任务，消费者都会优先完成发送确认邮件的通知任务。