要求如下：
-
有N个 生产环境 者，可以生成消息或工作或任何你想要的东西 .
-
必须按顺序处理来自每个procuder的消息，并且每条消息必须只处理一次 .
-
还有一个限制：对于任何给定的 生产环境 者，任何时候都必须有不超过一条正在处理的消息 .
-
消费方包含许多线程（它们的功能相同），它们分布在许多进程中 - 它是通过mod_wsgi运行的WSGI应用程序 .
目前，消费方的排队实现为自定义队列，即子类Queue，但它有自己的问题，我不会进入，主要的是在进程重启时它的队列丢失 .
是否有产品可以满足我的要求，虽然这不是那么重要（因为队列不再存在于工作进程的内存中） .
1 回答
有许多产品可以满足您的需求 . 有Django经验的人可能会告诉你“芹菜”，但这不是一个完整的答案 . Celery是实际排队系统的一个（有用的）包装器，使用包装器并不意味着你不必考虑你的底层技术 .
ZeroMQ，Redis和RabbitMQ是我想到的一些不同的解决方案 . 当然有更多的选择 . 我相当确定没有排队解决方案会支持您“在任何时候对于任何给定的 生产环境 者必须有不超过一条正在处理的消息”要求作为配置参数;您应该在 生产环境 者处实施此要求（即，在您收到作业＃1已完成的确认之前，不要提交作业＃2） .
Redis不是一个真正的排队系统，而是一个非常快速的数据库，具有pub / sub功能;尽管您可以使用Redis pub / sub将作业发布到单个订户，然后将其作为一个订阅者推送到数据库中，您将无法使用Redis pub / sub来满足开箱即用的“一次处理的作业”要求 . 列表（一个穷人的队列） . 然后，您的消费者将从列表中原子地提取作业 . 如果你想走这条路，它会奏效 .
RabbitMQ是一个“企业”排队系统，绝对可以满足您的要求，但您必须在某处部署RabbitMQ服务器，这可能有点过分 . 为了记录，我在许多项目中使用RabbitMQ，它完成了工作 . 设置“直接”类型的交换，将其绑定到单个队列，并将所有使用者订阅到此队列 . 你也可以从RabbitMQ获得相当好的持久性 .
ZeroMQ具有非常灵活的排队模型，ZeroMQ绝对可以做到你想要的 . ZeroMQ基本上只是传输机制，所以当你让你的发布者和订阅者以及经纪人分发它们时，你最终可能会自己推出 .