Queuing: N производители N потребителей

Question

Требование выглядит следующим образом:

• Там являются N производителями, которые генерируют сообщения или задание или что вы хотите назвать это.
• Сообщения от каждого обработчика должны обрабатываться в порядке, и каждое сообщение должно обрабатываться ровно один раз.
• Существует еще одно ограничение: в любое время для любого данного производителя должно быть не более одного обрабатываемого сообщения.
• Потребляемая сторона состоит из ряда потоков (они идентичны по своей функциональности), которые распределены по нескольким процессам - это приложение WSGI, выполняемое через mod_wsgi.

На данный момент очереди на потребляющей стороне реализован в виде пользовательской очереди, чтобы подклассы Queue, но у него есть свои проблемы, я не буду вдаваться в, главным из которых является, что после процесса перезагрузки его очередь теряется.

Есть ли продукт, который позволит выполнить требования, изложенные выше? Поддержка настойчивости была бы замечательной, хотя это не так важно (так как очередь больше не будет находиться в памяти рабочего процесса).

Answer 1

Существует много продуктов, которые выполняют то, что вы ищете. Люди с опытом Django, вероятно, скажут вам «сельдерей», но это не полный ответ. Сельдерей - (полезная) обертка вокруг реальной системы очередей, а использование обертки не означает, что вам не нужно думать о своей базовой технологии.

ZeroMQ, Redis и RabbitMQ - это несколько разных решений, которые приходят на ум. Есть, конечно, больше вариантов. Я абсолютно уверен, что никакое решение для очередей не поддержит ваше «в любое время для любого заданного производителя должно быть не более одного сообщения, которое обрабатывается» как параметр конфигурации; вы должны, вероятно, выполнить это требование у производителя (т. е. не отправлять задание № 2, пока не получите подтверждение, что задание № 1 завершено).

Redis не является реальной системой массового обслуживания, но очень быстрой базой данных с функциями pub/sub; вы не сможете использовать Redis pub/sub, чтобы удовлетворить требование «работа, обработанное ровно один раз», хотя вы можете использовать Redis pub/sub для публикации заданий одному подписчику, который затем подталкивает их в базу данных как список (очередь бедного человека). Затем ваши потребители атомизируют работу из списка. Он будет работать, если вы хотите пройти этот маршрут.

RabbitMQ - это система управления «предприятием» и будет полностью соответствовать вашим требованиям, но вам придется развернуть сервер RabbitMQ где-нибудь, и это может быть излишним. Для записи я использую RabbitMQ для многочисленных проектов, и он выполняет свою работу. Настройте «прямой» -типный обмен, привяжите его к одной очереди и подпишитесь на всех своих потребителей в эту очередь. Вы получаете довольно хорошую настойчивость от RabbitMQ.

ZeroMQ имеет очень гибкую модель массового обслуживания, и ZeroMQ можно абсолютно сделать, чтобы делать то, что вы хотите. ZeroMQ - это всего лишь механизм транспорта, поэтому, когда речь заходит о том, чтобы ваши издатели, подписчики и брокер распространяли их, вы можете закончить свою работу.