1

The requirement is as follows:

  • There are N producers, that generate messages or jobs or whatever you want to call it.
  • Messages from each procuder must be processed in order and each message must be processed exactly once.
  • There's one more restriction: at any time for any given producer there must be not more than one message that is being processed.
  • The consuming side consists of a number of threads (they are identical in their functionality) that are spread across a number of processes - it is a WSGI application run via mod_wsgi.

At the moment, the queueing on the consuming side is implemented as a custom queue, that subclasses Queue, but it has its own problems that I won't get into, the main one being that upon process restart its queue is lost.

Is there a product, that will make it possible to fulfill the requirements I've outlined above? Support for persistency would've been great, though that is not so important (since the queue will not reside in the worker process' memory any more).

4

1 回答 1

2

有许多产品可以满足您的需求。有 Django 经验的人可能会告诉你“芹菜”，但这不是一个完整的答案。Celery 是实际排队系统的（有用的）包装器，使用包装器并不意味着您不必考虑底层技术。

ZeroMQ、Redis 和 RabbitMQ 是我想到的几种不同的解决方案。当然还有更多的选择。我相当肯定，没有排队解决方案将支持您的“在任何时候对于任何给定的生产者，必须处理的消息不得超过一条”作为配置参数的要求；您可能应该在生产者处实施此要求（即，在您收到作业#1 已完成的确认之前不要提交作业#2）。

Redis 不是真正的排队系统，而是一个非常快的数据库，具有 pub/sub 特性；尽管您可以使用 Redis pub/sub 将作业发布到单个订阅者，然后将它们作为列表（穷人的队列）。然后，您的消费者会自动从列表中拉出一份工作。如果你想走这条路，它会起作用。

RabbitMQ 是一个“企业”排队系统，绝对可以满足您的要求，但是您必须将 RabbitMQ 服务器部署在某个地方，这可能有点矫枉过正。作为记录，我在许多项目中使用 RabbitMQ，它完成了工作。设置“直接”类型的交换，将其绑定到单个队列，并将所有消费者订阅到该队列。你也可以从 RabbitMQ 获得很好的持久性。

ZeroMQ 有一个非常灵活的队列模型，ZeroMQ 绝对可以做你想做的事。然而，ZeroMQ 基本上只是一种传输机制，所以当涉及到让你的发布者和订阅者以及一个代理来分发它们时，你最终可能会自己滚动。

于 2012-02-23T18:47:27.077 回答