Постановка в очередь: от N производителей к N потребителям

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

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

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

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


python queue message-queue beanstalkd
person shylent    schedule 23.02.2012    source источник
comment
сельдерей   -  person jterrace    schedule 23.02.2012

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

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

person mattbornski    schedule 23.02.2012