用redis实现支持优先级的消息队列.docVIP

用redis实现支持优先级的消息队列 ? 为什么需要消息队列 系统中引入消息队列机制是对系统一个非常大的改善。例如一个web系统中，用户做了某项操作后需要发送邮件通知到用户邮箱中。你可以使用同步方式让用户等待邮件发送完成后反馈给用户，但是这样可能会因为网络的不确定性造成用户长时间的等待从而影响用户体验。 ? 有些场景下是不可能使用同步方式等待完成的，那些需要后台花费大量时间的操作。例如极端例子，一个在线编译系统任务，后台编译完成需要30分钟。这种场景的设计不可能同步等待后在回馈，必须是先反馈用户随后异步处理完成，再等待处理完成后根据情况再此反馈用户与否。 ? 另外适用消息队列的情况是那些系统处理能力有限的情况下，先使用队列机制把任务暂时存放起来，系统再一个个轮流处理掉排队的任务。这样在系统吞吐量不足的情况下也能稳定的处理掉高并发的任务。 ? 消息队列可以用来做排队机制，只要系统需要用到排队机制的地方就可以使用消息队列来作。 ? 目前成熟的消息队列产品有很多，著名的例如rabbitmq。它使用起来相对还是比较简单的，功能也相对比较丰富，一般场合下是完全够用的。但是有个很烦人的就是它不支持优先级。 例如一个发邮件的任务，某些特权用户希望它的邮件能够更加及时的发送出去，至少比普通用户要优先对待。默认情况下rabbitmq是无法处理掉的，扔给rabbitmq的任务都是FIFO先进先出。但是我们可以使用一些变通的技巧来支持这些优先级。创建多个队列，并为rabbitmq的消费者设置相应的路由规则。 ? 例如默认情况下有这样一个队列，我们拿list来模拟 [task1, task2, task3]，消费者轮流按照FIFO的原则一个个拿出task来处理掉。如果有高优先级的任务进来，它也只能跟在最后被处理[task1, task2, task3, higitask1].?但是如果使用两个队列，一个高优先级队列，一个普通优先级队列。 普通优先级[task1, task2, task3], 高优先级[hightask1 ] 然后我们设置消费者的路由让消费者随机从任意队列中取数据即可。 ? 并且我们可以定义一个专门处理高优先级队列的消费者，它空闲的时候也不处理低优先级队列的数据。这类似银行的VIP柜台，普通客户在银行取号排队，一个VIP来了他虽然没有从取号机里拿出一个排在普通会员前面的票，但是他还是可以更快地直接走VIP通道。 ? 使用rabbitmq来做支持优先级的消息队列的话，就像是上面所述同银行VIP会员一样，走不同的通道。但是这种方式只是相对的优先级，做不到绝对的优先级控制，例如我希望某一个优先级高的任务在绝对意义上要比其他普通任务优先处理掉，这样上面的方案是行不通的。因为rabbitmq的消费者只知道再自己空闲的情况下从自己关心的队列中“随机”取某一个队列里面的第一个数据来处理，它没法控制优先取找哪一个队列。或者更加细粒度的优先级控制。或者你系统里面设置的优先级有10多种。这样使用rabbitmq也是很难实现的。 ? 但是如果使用redis来做队列的话上面的需求都可以实现。 ? 首先redis它的设计是用来做缓存的，但是由于它自身的某种特性使得他可以用来做消息队列。它有几个阻塞式的API可以使用，正是这些阻塞式的API让他有做消息队列的能力。 ? 试想一下在”数据库解决所有问题“的思路下，不使用消息队列也是可以完成你的需求的。我们把任务全部存放在数据库然后通过不断的轮询方式来取任务处理。这种做法虽然可以完成你的任务但是做法很粗劣。但是如果你的数据库接口提供一个阻塞的方法那么就可以避免轮询操作了，你的数据库也可以用来做消息队列，只不过目前的数据库还没有这样的接口。 另外做消息队列的其他特性例如FIFO也很容易实现，只需要一个List对象从头取数据，从尾部塞数据即可实现。 redis能做消息队列得益于他list对象blpop brpop接口以及Pub/Sub(发布/订阅)的某些接口。他们都是阻塞版的，所以可以用来做消息队列。 ? ? ? 一些基础redis基础知识的说明 这个例子使用blpop命令会阻塞方式地从tasklist列表中取头一个数据，最后一个参数就是等待超时的时间。如果设置为0则表示无限等待。另外redis存放的数据都只能是string类型，所以在任务传递的时候只能是传递字符串。我们只需要简单的将负责数据序列化成json格式的字符串，然后消费者那边再转换一下即可。 ? 这里我们的示例语言使用python，链接redis的库使用redis-py. 如果你有些编程基础把它切换成自己喜欢的语言应该是没问题的。 ? import redis, timedef handle(task): print task time.sl